Aprenda a estructurar una requisición técnica en Ingeniería con alcance, especificaciones, interfaces, vendor data, calidad, pruebas y criterios de aceptación.
¡Descúbrelo!
La requisición técnica en Ingeniería es el paquete documental que libera una adquisición o contratación al proceso de Procurement con una baseline técnica suficientemente definida. Consolida qué será suministrado, qué requisitos deben cumplirse, qué documentos componen la solicitud, cómo se compararán las propuestas y qué evidencias se exigirán durante fabricación, instalación, pruebas y aceptación.
En proyectos industriales, de infraestructura, energía, Data Centers, telecomunicaciones y sistemas críticos, la requisición técnica funciona como puente entre Ingeniería y Procurement. Si se emite incompleta, la competencia comienza con vacíos que después aparecen como dudas de proveedores, propuestas heterogéneas, exclusiones, aditivos, retrasos, conflictos de interfaz o dificultades de comisionamiento.
La requisición no debe confundirse con una simple lista de materiales ni con la RFP o RFQ. Es la baseline técnica de entrada utilizada para montar el documento de solicitud al mercado. Según el objeto, puede reunir especificaciones, datasheets, planos, listas, memorias, criterios de aceptación, requisitos de calidad, matriz de responsabilidades y documentación de vendor data.
Para qué sirve una requisición técnica
La requisición técnica es el gate de madurez entre Ingeniería y Procurement. Su función es impedir que una contratación formal se inicie con requisitos, interfaces y criterios de aceptación todavía indefinidos.
La requisición técnica transforma una necesidad de proyecto en un paquete que puede adquirirse de forma comparable. Su función es garantizar que Procurement no tenga que interpretar por sí solo el alcance de Ingeniería y que los proveedores reciban la misma referencia técnica.
El Banco Mundial destaca, en sus recursos de Procurement, que los Terms of Reference y las especificaciones técnicas deben prepararse de forma capaz de orientar al mercado y a la evaluación. PMBOK, a su vez, conecta Statement of Work, estimaciones, documentos de solicitud y evaluación de proveedores dentro del flujo de Procurement.
En organizaciones EPC/EPCM, el término Technical Requisition se utiliza frecuentemente para el documento que agrupa especificación técnica, hojas de datos, listas y requisitos documentales de un paquete de compra.
Qué no es la requisición técnica
La frontera del documento debe ser clara.
| Documento | Función principal |
| lista de materiales | cuantifica ítems, componentes o equipos |
| especificación técnica | define requisitos técnicos y de desempeño |
| datasheet | registra parámetros aplicables a un equipo o ítem |
| requisición técnica | consolida la baseline técnica del paquete para Procurement |
| RFP | solicita propuesta estructurada para un objeto complejo |
| RFQ | solicita cotización para un objeto suficientemente definido |
| contrato/orden | formaliza obligaciones comerciales y jurídicas |
La requisición puede incorporar o referenciar todos estos documentos técnicos, pero no sustituye el instrumento comercial y contractual.
Cuándo la requisición está madura para emisión
El criterio no debe ser “el documento está escrito”, sino “¿el mercado puede formar una oferta comparable y ejecutable a partir de esta baseline?”.
Antes de la liberación, Ingeniería debe verificar si:
- el alcance está delimitado;
- los battery limits están claros;
- las interfaces con terceros están identificadas;
- los requisitos obligatorios están diferenciados de preferencias;
- los datos de proyecto necesarios están disponibles;
- las alternativas permitidas están definidas;
- las pruebas y criterios de aceptación poseen lógica verificable;
- los documentos de proveedor necesarios fueron especificados;
- las cantidades y unidades son consistentes;
- los planos y listas utilizan las revisiones correctas;
- las premisas y exclusiones del propietario son explícitas.
Cuando uno de estos vacíos es material, emitir la requisición solamente para “ganar tiempo” puede desplazar el retraso hacia una fase más costosa.
Estructura recomendada de la requisición técnica
No existe un único template válido para todos los sectores. La estructura debe reflejar el objeto, pero un paquete de Ingeniería puede contener los siguientes bloques.
Identificación del paquete
Código, título, disciplina, sistema, proyecto, lugar de instalación, revisión, responsable técnico y referencia al plan de suministros.
Alcance de suministro
Describe lo que el proveedor deberá entregar, incluyendo equipos, materiales, servicios, Ingeniería de aplicación, instalación cuando corresponda, pruebas, documentación, capacitación, repuestos y soporte.
Límites e interfaces
Define los puntos donde comienza y termina la responsabilidad del proveedor. En sistemas integrados, esta sección es tan relevante como la especificación del propio equipo.
Documentos técnicos aplicables
Puede incluir:
- especificaciones;
- memorias;
- planos;
- diagramas;
- datasheets;
- listas de materiales;
- lista de I/O;
- arquitectura de sistemas;
- estudios de Ingeniería;
- normas y estándares;
- documentos de referencia del proyecto.
Requisitos de desempeño
Parámetros medibles que la solución debe alcanzar. Siempre que sea posible, deben definirse de forma verificable y asociarse con la evidencia que demostrará su cumplimiento.
Requisitos de calidad e inspección
Incluyen plan de calidad, ITP, certificados, trazabilidad, inspecciones, witness points, hold points, FAT, pruebas especiales y tratamiento de no conformidades cuando corresponda.
Vendor data requirements
Define qué documentos debe entregar el proveedor, en qué revisión, formato y plazo. Esta lista debe existir antes de la contratación porque parte de los documentos puede ser necesaria para continuar el propio proyecto.
Criterios de aceptación
Explican cómo el contratante confirmará la conformidad: aprobación documental, pruebas, inspecciones, SAT, comisionamiento, documentación final u otros mecanismos.
El alcance de suministro debe incluir servicios invisibles
Muchas diferencias entre propuestas no están en el equipo principal, sino en los servicios y accesorios necesarios para ponerlo en operación.
La requisición debe verificar, según el paquete:
- Ingeniería de aplicación;
- planos de fabricante;
- accesorios y kits de montaje;
- conectores e interfaces;
- licencias de software;
- configuración;
- integración;
- herramientas especiales;
- supervisión de montaje;
- start-up;
- FAT y SAT;
- capacitación;
- documentación;
- repuestos;
- garantía y soporte.
Cuando estos elementos quedan implícitos, cada proponente crea su propia interpretación y la comparación pierde validez.
Battery limits e interfaces
Battery limits definen límites físicos o funcionales del suministro. En Ingeniería multidisciplinaria, la requisición debe registrar puntos de conexión, alimentación, comunicación, infraestructura, responsabilidad por cables, soportes, software, obras civiles, integración y pruebas.
Una matriz de interfaces puede ser más eficiente que párrafos extensos.
| Interfaz | Proveedor | Contratante/tercero | Evidencia |
| alimentación eléctrica | borne del equipo | circuito y protección aguas arriba | diagrama y carga eléctrica |
| red de datos | interfaz Ethernet | switch e infraestructura | requisitos de puerto y protocolo |
| base civil | cargas y anclajes | proyecto y ejecución de la base | plano de cargas |
| software | licencia y configuración | infraestructura de servidor | matriz de requisitos |
| comisionamiento | pruebas del equipo | integración del sistema | protocolo SAT |
Esta definición reduce disputas posteriores sobre “alcance por terceros”.
Requisitos prescriptivos y requisitos de desempeño
La requisición debe equilibrar dos formas de especificar.
Requisitos prescriptivos definen materiales, modelos, dimensiones, arquitectura o método. Son adecuados cuando interoperabilidad, estandarización o experiencia consolidada exigen una solución específica.
Requisitos de desempeño definen el resultado que debe alcanzarse y permiten que el proveedor proponga cómo lograrlo. Son útiles cuando existe espacio legítimo para innovación o soluciones equivalentes.
Una especificación excesivamente prescriptiva puede restringir el mercado sin ganancia técnica. Una especificación excesivamente funcional puede transferir al proveedor decisiones que deberían permanecer bajo control de Ingeniería.
Cómo tratar normas y documentos aplicables
La requisición debe listar normas solamente cuando sean realmente pertinentes al objeto y a la edición aplicable al proyecto. Copiar una lista extensa de normas de otro paquete crea conflictos y exigencias irrelevantes.
También es necesario definir precedencia documental. Si plano, datasheet y especificación divergen, el proveedor necesita saber qué documento gobierna o cómo emitir una consulta técnica.
Una jerarquía explícita reduce ambigüedades durante propuesta y ejecución.
Matriz de requisitos para propuestas comparables
En paquetes complejos, una matriz de conformidad puede acompañar la requisición. Cada requisito recibe un identificador y el proveedor indica cumplimiento, evidencia, desvío o alternativa.
Esta matriz facilita la futura TBE, porque la evaluación deja de comenzar por la lectura desestructurada de cientos de páginas.
Una clasificación típica puede utilizar:
- conforme;
- aclaración necesaria;
- desvío;
- alternativa técnica;
- no conforme.
El significado de cada estado debe definirse en el proceso.
Cómo preparar requisitos para la TBE
El equipo que elabora la requisición debería pensar en la evaluación futura. Para cada requisito relevante, debe ser posible responder:
- cómo el proveedor demostrará cumplimiento en la propuesta;
- qué evidencia será aceptada;
- si el requisito es eliminatorio o diferenciador;
- si se permiten alternativas;
- cómo se verificará el requisito después de la contratación.
Esta trazabilidad conecta especificación, TBE y aceptación.
Requisición técnica y RFI
Cuando Ingeniería todavía no puede completar la requisición porque existen dudas sobre tecnología, mercado, capacidad o interfaces, una RFI puede emitirse antes.
La consulta sirve para madurar la baseline, no para sustituir el trabajo de Ingeniería. Después de consolidar las respuestas, el equipo revisa especificaciones y libera la requisición en un nivel adecuado para RFP o RFQ.
Requisición técnica y RFP
En una RFP, la requisición técnica define la referencia contra la cual se evaluarán soluciones diferenciadas. Debe indicar qué requisitos son fijos y dónde existe libertad de solución.
Si esta frontera no está clara, los proveedores pueden interpretar cualquier requisito como negociable o, en el extremo opuesto, asumir que ninguna alternativa está permitida.
Requisición técnica y RFQ
La RFQ presupone mayor estabilidad del objeto. Por eso, la requisición que soporta una RFQ debe eliminar diferencias relevantes de alcance, cantidad, desempeño y documentación.
Cuando los proveedores todavía necesitan diseñar partes sustanciales de la solución para responder, el proceso probablemente se acerca más a una RFP que a una RFQ.
Vendor data debe definirse antes del award
El Vendor Data Requirement List, Vendor Document Register o estructura equivalente especifica lo que el proveedor deberá emitir durante el contrato.
Los documentos típicos pueden incluir:
- datasheets certificados;
- planos dimensionales;
- cargas e interfaces;
- diagramas;
- listas de materiales;
- manuales;
- procedimientos de prueba;
- certificados;
- informes de inspección;
- documentación de software;
- documentación final y As-Built del fabricante.
Si estos documentos solo se negocian después del award, el contratante pierde poder para establecer plazos y formatos sin impacto comercial.
Submittals y ciclos de aprobación
La requisición debe indicar qué documentos se someten para información, revisión, aprobación o registro. También debe definir el efecto de la aprobación: revisar un plano de fabricante no transfiere al contratante la responsabilidad por el proyecto del proveedor, salvo disposición contractual específica.
Los ciclos deben considerar el plazo de revisión y la posibilidad de reenvío. Vendor data atrasado puede bloquear fabricación o Ingeniería de otras disciplinas.
Requisitos de calidad, inspección y FAT
Para paquetes críticos, la requisición debe crear la base para el control de calidad desde el inicio. No es suficiente pedir “FAT incluido” sin definir alcance, referencia, procedimientos, testimonio y criterios de aprobación.
Lo mismo vale para inspecciones. El contratante debe establecer cuándo habrá hold points, witness points, certificados obligatorios y tratamiento de no conformidades.
Esta lógica se conecta con la Gestión de la Calidad en Procurement, que acompaña el suministro hasta la aceptación.
Condiciones de entrega y logística técnica
Algunos aspectos de logística poseen naturaleza técnica y deben estar en la requisición: embalaje especial, preservación, restricciones ambientales, orientación de almacenamiento, piezas sueltas, izaje, protección contra vibración, humedad o corrosión.
Estas condiciones pueden influir en el diseño del embalaje e incluso en la configuración del equipo.
Revisiones y congelamiento de la baseline
La requisición técnica debe tener revisión controlada. Si Ingeniería cambia después de que los proveedores comenzaron a cotizar, el proceso debe registrar el impacto y emitir una revisión o aclaración formal para todos los participantes según las reglas de la competencia.
Después del award, los cambios deben seguir el proceso de Engineering Change Management o change control contractual. Cambiar silenciosamente la especificación destruye la trazabilidad entre propuesta, contrato y suministro.
Checklist de liberación de la requisición
Antes de la emisión para Procurement, una verificación independiente puede confirmar:
- alcance completo;
- documentos listados y en revisión correcta;
- cantidades reconciliadas;
- interfaces definidas;
- criterios de desempeño medibles;
- requisitos obligatorios identificados;
- normas pertinentes;
- vendor data definido;
- calidad y pruebas coherentes;
- criterios de aceptación establecidos;
- estrategia RFI/RFP/RFQ compatible;
- responsables de evaluación definidos.
Para paquetes críticos, este checklist puede funcionar como gate formal.
Indicadores de calidad de la requisición
La calidad del documento puede observarse mediante señales del proceso posterior:
| Indicador | Posible problema de origen |
| gran volumen de dudas de proveedores | alcance o requisitos ambiguos |
| muchas revisiones durante la competencia | baseline liberada demasiado pronto |
| propuestas con exclusiones muy diferentes | límites de suministro incompletos |
| TBE larga y con muchas diligencias | matriz de requisitos insuficiente |
| cambios inmediatamente después del award | interfaces o datos de proyecto inmaduros |
| vendor data negociado posteriormente | requisitos documentales no definidos |
Estos datos pueden alimentar lecciones aprendidas y mejorar templates futuros.
Requisición técnica en servicios de Ingeniería
El concepto también puede aplicarse a servicios, aunque el nombre utilizado sea Términos de Referencia, Statement of Work o Scope of Services. La lógica permanece: definir alcance, entregables, premisas, metodología esperada, interfaces, criterios de evaluación, medición y aceptación de modo que las propuestas puedan compararse.
En servicios intelectuales, evitar prescribir anticipadamente el propio producto final es especialmente importante. El documento debe exigir metodología y evidencias suficientes para evaluar capacidad sin transferir al proponente la ejecución gratuita del alcance durante la competencia.
Integración con el plan de suministros
La fecha de liberación de la requisición es un hito del plan de suministros. Si se atrasa, todas las actividades posteriores del paquete se desplazan: emisión, propuestas, TBE, award, vendor data, fabricación, pruebas y entrega.
Por eso, Project Controls debe monitorear no solamente compras emitidas, sino también requisiciones todavía en preparación por Ingeniería.
Consideraciones finales
La requisición técnica es una de las barreras más eficaces contra problemas de Procurement que parecen comerciales, pero nacen de una Ingeniería insuficientemente definida. Transforma requisitos, planos, interfaces, calidad, documentación y aceptación en una baseline común para el mercado.
Cuando se elabora con trazabilidad y se integra al plan de suministros, a la TBE y al control de vendor data, reduce ambigüedades antes de que se conviertan en precio, retraso, change order o disputa de responsabilidad.
Vendor data debe contratarse antes de ser necesario. Si planos y datasheets críticos solo se negocian después del award, Ingeniería pierde previsibilidad precisamente en los documentos que alimentan proyecto, fabricación y construcción.
Referencias técnicas
[1] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8.ª ed. Newtown Square: PMI, 2025. Disponible en: [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok)
[2] WORLD BANK. Procurement learning resources: Terms of Reference and Technical Specifications. Disponible en: [https://www.worldbank.org/en/scci/topic/procurement](https://www.worldbank.org/en/scci/topic/procurement)
[3] WORLD BANK. Procurement Regulations for IPF Borrowers. 7th ed. Washington, DC, 2025. Disponible en: [https://thedocs.worldbank.org/en/doc/c84273d1b230aeb2b0b8134de5dc8cd7-0290012025/original/Procurement-Regulations-7th-Edition-Sep-2025.pdf](https://thedocs.worldbank.org/en/doc/c84273d1b230aeb2b0b8134de5dc8cd7-0290012025/original/Procurement-Regulations-7th-Edition-Sep-2025.pdf)
[4] ISO; IAF. ISO 9001 Auditing Practices Group: Guidance on External Providers. Disponible en: [https://committee.iso.org/files/live/sites/tc176/files/PDF%20APG%20New%20Disclaimer%2012-2023/ISO-TC%20176-TF_APG-ExternalProviders.pdf](https://committee.iso.org/files/live/sites/tc176/files/PDF%20APG%20New%20Disclaimer%2012-2023/ISO-TC%20176-TF_APG-ExternalProviders.pdf)
Preguntas frecuentes
Es el paquete documental que consolida la baseline técnica necesaria para que Procurement solicite y compare ofertas, incluyendo alcance, especificaciones, interfaces, documentos, requisitos de calidad y criterios de aceptación.
No. La requisición es la entrada técnica preparada por Ingeniería. La RFP es el documento de solicitud al mercado que utiliza esta baseline junto con reglas comerciales, contractuales y de evaluación.
Alcance, límites, especificaciones, datasheets, planos aplicables, requisitos de desempeño, calidad, inspección, pruebas, vendor data, documentación y criterios de aceptación, según la complejidad del paquete.
Cuando la baseline permite al mercado formar ofertas comparables y ejecutables sin vacíos materiales de alcance, interfaz, desempeño o aceptación.
Son requisitos documentales que definen qué planos, datasheets, informes, manuales, certificados y otros documentos debe entregar el proveedor, con plazos y estados de revisión.
Sí, cuando sea necesario, pero la revisión debe controlarse y comunicarse formalmente a los participantes para preservar igualdad de trato, trazabilidad y comparabilidad.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Contratos, Alcance y Entregables
Servicios relacionados
- Procurement Técnico: especificación, equalización, proveedores y apoyo a la contratación
- Apoyo Técnico a Licitación y Análisis de Propuestas de Ingeniería: conformidad, técnica y precio
Contenidos principales sobre el tema
- RFP en Ingeniería: cómo estructurar alcance, requisitos y criterios de selección
- RFQ en Ingeniería: cómo solicitar propuestas comercialmente comparables
