Vea cómo estructurar una contratación EPC en Ingeniería: requisitos, ingeniería de referencia, RFP, calificación, TBE, riesgos, negociación y criterios de aceptación.
¡Descúbrelo!
Una contratación EPC en Ingeniería debe transformar una necesidad de negocio en un paquete técnico y comercial suficientemente claro para que empresas capaces de asumir Engineering, Procurement and Construction compitan por el mismo objeto sobre bases comparables. El proceso no comienza enviando una planilla a algunos proveedores. Comienza con la decisión de que EPC es realmente el modelo adecuado, con la maduración de los requisitos y con la definición de qué responsabilidades, riesgos, interfaces, desempeños y evidencias serán transferidos al contratista.
Contratar EPC exige equilibrio. Si el Owner define poco, cada proponente interpreta el objeto de forma diferente e incorpora contingencias, exclusiones o calificaciones; si define en exceso, puede limitar soluciones, interferir en la responsabilidad del contratista EPC y reducir los beneficios de la contratación integrada. La ingeniería de referencia debe proporcionar base suficiente para precio, plazo, interfaces y aceptación, preservando la libertad técnica que el modelo pretende conceder.
Un proceso robusto normalmente pasa por readiness, requisitos, ingeniería de referencia, estrategia de contratación, market sounding, precalificación, RFP, aclaraciones, TBE, igualación comercial, análisis de riesgos residuales, negociación, consolidación de anexos y award. La calidad de la contratación se mide menos por la cantidad de documentos emitidos y más por la capacidad de producir propuestas técnicamente equivalentes y un contrato ejecutable sin zonas grises relevantes.
Primero: confirmar si EPC es el modelo correcto
Antes de preparar la RFP, el Owner debe verificar si la concentración de responsabilidad agrega valor. EPC tiende a ser adecuado cuando los requisitos son suficientemente estables, las interfaces internas pueden transferirse a un integrador, existe mercado capaz de asumir el paquete y el desempeño puede especificarse y probarse.
Si el proyecto todavía está en fuerte evolución, si el Owner desea contratar directamente a muchos proveedores o si las condiciones existentes presentan grandes incertidumbres, EPCM, múltiples paquetes o una fase adicional de definición pueden ser mejores alternativas.
El comparativo EPC vs. EPCM debe analizarse antes de la RFP cuando la estrategia de entrega aún no está decidida. La Estrategia de Contratación en Ingeniería amplía el análisis hacia paquetes, riesgos y modelos contractuales.
Criterios de decisión
Una decisión estructurada debe considerar:
- madurez de los requisitos;
- cantidad y naturaleza de las interfaces;
- capacidad interna del Owner;
- necesidad de flexibilidad durante la implantación;
- disponibilidad de contratistas EPC calificados;
- criticidad de precio y plazo;
- condiciones del sitio y riesgos brownfield;
- estrategia de financiación y flujo de caja;
- necesidad de transparencia sobre costes de proveedores;
- capacidad para definir pruebas y desempeño.
La elección debería registrarse antes de iniciar la competencia para evitar modificar las reglas después de que el mercado ya haya formado precio.
Project Readiness: ¿el proyecto está listo para ser contratado?
Readiness verifica si el Owner dispone de información y decisiones suficientes para transferir responsabilidad de forma racional. La Project Readiness en Ingeniería evalúa alcance, interfaces, riesgos, documentación, decisiones y recursos antes de avanzar.
Para una contratación EPC, algunas preguntas relevantes son: ¿los requisitos están aprobados? ¿Los datos del sitio fueron validados? ¿Las interfaces externas están identificadas? ¿El Owner sabe qué suministrará? ¿El desempeño y la aceptación pueden medirse? ¿Los principales riesgos fueron discutidos? ¿El mercado conoce el tipo de solución?
El PDRI — Project Definition Rating Index también puede apoyar la evaluación de madurez de definición. El objetivo no es alcanzar la perfección antes de la contratación, sino conocer explícitamente qué continúa abierto y decidir si el riesgo de avanzar es aceptable.
Readiness no es solo documentación
Un proyecto puede tener muchos documentos y aun así estar inmaduro. Si existen decisiones críticas pendientes, interfaces sin responsables o premisas que contradicen levantamientos de campo, la cantidad de archivos no reduce el riesgo.
La evaluación debe observar calidad, coherencia y gobernanza de la información. Un paquete menor y consistente puede ser más contratable que un gran volumen documental con versiones conflictivas.
Antes de lanzar una RFP EPC, el Owner necesita saber si el proyecto está suficientemente definido para recibir precio, plazo y riesgo. Readiness evalúa no solo documentos disponibles, sino también decisiones pendientes, interfaces, datos del sitio, premisas, riesgos y condiciones que pueden alterar materialmente las propuestas.
Definir los requisitos del Owner
Los requisitos del Owner son la referencia del resultado requerido. Deben indicar qué debe hacer el proyecto, en qué condiciones, con qué desempeño y bajo qué restricciones.
La Gestión de Requisitos en Ingeniería permite organizar requisitos funcionales, técnicos, de seguridad, mantenimiento, integración, documentación y operación. Cada requisito relevante debe contar con un método de verificación compatible.
Especificar resultados, no adjetivos
Expresiones como “alta calidad”, “sistema robusto” o “mejor tecnología” no orientan una competencia técnica. Los requisitos deben transformarse en parámetros, arquitecturas mínimas, comportamientos, normas aplicables, tolerancias y criterios de prueba.
Al mismo tiempo, especificar un único modelo o solución sin necesidad puede limitar la competencia y retirar al contratista EPC parte de la autonomía que justifica el modelo. El equilibrio depende del riesgo y de la estrategia del Owner.
Requisitos de operación y mantenimiento
La contratación EPC debe considerar el período posterior al handover. Accesibilidad, repuestos, documentación, licencias, capacitación, herramientas, backups, estrategia de mantenimiento y estandarización pueden afectar el coste del ciclo de vida y deben entrar en la definición.
Desarrollar una ingeniería de referencia compatible
La ingeniería de referencia crea el puente entre requisitos y propuesta EPC. Puede incluir estudios, bases de diseño, levantamientos, memorias, diagramas, layouts, especificaciones, anteproyecto, Proyecto Básico o FEED.
El FEED en Ingeniería es especialmente útil en proyectos industriales y multidisciplinares porque madura bases, alternativas, equipos principales, interfaces, cronograma y estimaciones.
La ingeniería de referencia debe dejar claro qué es mandatorio, qué es referencial y dónde el contratista EPC tiene libertad para optimizar. Si esta distinción no existe, los proponentes pueden interpretar un dibujo conceptual como requisito obligatorio o, en el extremo opuesto, ignorar decisiones que el Owner pretendía preservar.
Datos del sitio
Topografía, interferencias, capacidad de infraestructura, redes existentes, accesos, características ambientales, ventanas de parada y demás condiciones relevantes deben verificarse en la medida necesaria.
En brownfield, la diligencia de campo es especialmente importante. Transferir indiscriminadamente al contratista EPC el riesgo por toda condición desconocida puede encarecer las propuestas o generar una disputa futura.
Delimitar el Scope of Work y los battery limits
El Scope of Work en Ingeniería debe describir actividades y entregables. Los battery limits y la matriz de interfaces definen las fronteras.
Para cada punto de interfaz, la RFP debe indicar quién suministra información, equipo, energía, acceso, conexión, pruebas y aceptación. Esto reduce la clásica laguna de “no está en mi alcance”.
Las inclusiones, exclusiones y premisas también deben tratarse. El Alcance Contractual en Ingeniería profundiza en cómo estas categorías afectan el precio y los cambios.
Regla de completitud
Cuando sea técnicamente aplicable, el paquete puede establecer que accesorios y servicios normalmente necesarios para la función final forman parte del alcance aunque no estén listados individualmente. Esta regla debe equilibrarse con límites claros para no convertir el contrato en una obligación indefinida.
Construir la matriz de responsabilidades
La matriz organiza al Owner, contratista EPC, terceros, utilities y proveedores nominados. Puede utilizar RACI o un modelo equivalente.
Además de “quién hace”, debe indicar quién suministra datos, quién aprueba, quién presencia pruebas y quién acepta. Las responsabilidades del Owner necesitan plazos, ya que una aprobación o liberación tardía puede entrar en el camino crítico.
La matriz también ayuda a separar aprobación de responsabilidad técnica. El hecho de que el Owner revise un documento no significa automáticamente que pase a responder por el diseño del contratista EPC.
Identificar y asignar riesgos antes de la RFP
Los riesgos deben discutirse antes de que el mercado los valorice. La matriz puede incluir condiciones existentes, interfaces externas, productividad, logística, licenciamiento, tipo de cambio, cambios regulatorios, utilities, datos suministrados y eventos de terceros.
El principio es asignar el riesgo a la parte que posee mejor capacidad para controlar o mitigar el evento. La transferencia arbitraria aumenta contingencias y puede reducir la competencia.
La matriz también debe indicar qué riesgos generan cambio, extensión de plazo o mecanismo específico. Sin este puente hacia el contrato, la discusión de riesgos permanece únicamente en el plano gerencial.
Definir desempeño, pruebas y aceptación antes de la competencia
El Owner debe definir qué se medirá para aceptar el resultado. Las garantías de capacidad, disponibilidad, eficiencia u otro desempeño deben contar con método de verificación.
El plan de pruebas puede prever FAT, SAT, pruebas funcionales, integradas y de desempeño. La estrategia de Puesta en Marcha debe influir en la RFP para que los proponentes incluyan recursos, instrumentos, software, consumibles y soporte necesarios.
La documentación también integra la aceptación: As-Built, manuales, informes, certificados, capacitación, backups, licencias y data books deben aparecer en el paquete.
Realizar market sounding y mapear contratistas EPC
Antes de la RFP formal, el Owner puede evaluar la capacidad del mercado. El objetivo no es negociar el contrato anticipadamente, sino verificar si existen empresas capaces de asumir el paquete, qué riesgos considera críticos el mercado y si la estrategia propuesta es competitiva.
El market sounding puede revelar que el alcance es demasiado grande para un único integrador, que determinado equipo exige un proveedor especializado o que una interfaz debe retirarse del paquete. Estas informaciones ayudan a ajustar la estrategia antes de congelar la contratación.
El proceso debe preservar la igualdad de trato cuando corresponda. Las informaciones relevantes obtenidas e incorporadas al objeto deben ponerse a disposición de los participantes de forma coherente.
Precalificación: quién puede realmente asumir el EPC
La precalificación reduce el riesgo de recibir propuestas de empresas sin capacidad suficiente. El criterio debe reflejar la complejidad del proyecto, no solo la facturación o la existencia formal de la empresa.
Pueden evaluarse:
- experiencia en alcances comparables;
- capacidad de ingeniería multidisciplinaria;
- gestión de Procurement y proveedores;
- construcción y gestión de subcontratistas;
- Project Controls;
- QA/QC;
- puesta en marcha e integración;
- salud financiera;
- equipo clave;
- sistemas de gestión documental;
- historial de seguridad y calidad;
- capacidad de garantías y seguros.
La exigencia debe ser proporcional. Restricciones excesivas pueden reducir la competencia sin beneficio real; requisitos bajos pueden permitir que empresas incapaces lleguen a la etapa de propuesta.
Estructurar la RFP EPC
La RFP en Ingeniería organiza alcance, requisitos y criterios de selección. En EPC, debe formar un paquete consistente entre documentos técnicos y comerciales.
Una estructura típica puede incluir:
- instrucciones a los proponentes;
- requisitos del Owner;
- Scope of Work;
- ingeniería de referencia;
- battery limits e interfaces;
- matriz de responsabilidades;
- matriz de riesgos;
- cronograma e hitos;
- requisitos de Procurement;
- calidad e inspecciones;
- puesta en marcha y desempeño;
- documentación y handover;
- propuesta de precio y condiciones comerciales;
- minuta contractual;
- criterios de evaluación.
La RFP debe exigir que las desviaciones y excepciones se presenten en formato estructurado. Las propuestas que ocultan calificaciones en el cuerpo de cartas comerciales son difíciles de igualar.
Conducir aclaraciones sin perder el control de versión
Durante la competencia, los proveedores presentan preguntas, solicitudes de aclaración y alternativas. Las respuestas del Owner pueden modificar la interpretación del objeto y deben ser controladas.
Una aclaración relevante debe emitirse a todos los participantes conforme a las reglas de la competencia e incorporarse a la baseline de contratación. Cuando la respuesta modifica alcance, plazo o riesgo, puede ser necesario emitir una adenda y permitir la revisión de las propuestas.
Las reuniones técnicas también deben generar registros. Las decisiones verbales no deben sustituir el paquete formal que será incorporado al contrato.
Evaluación técnica: TBE e igualación
La Technical Bid Evaluation — TBE compara las propuestas con los requisitos y registra desviaciones. El objetivo es determinar si cada empresa está ofreciendo la misma obligación de resultado.
El análisis debe observar arquitectura, equipos, ingeniería, metodología, cronograma, proveedores críticos, calidad, puesta en marcha, documentación y calificaciones contractuales.
Una propuesta técnicamente “aceptable” puede contener todavía desviaciones con impacto económico. Por ello, la TBE debe alimentar la igualación comercial.
No comparar precio antes de igualar el alcance
Si un proponente excluye integración y otro la incluye; si uno prevé tres FAT y otro ninguno; si uno incluye capacitación y otro no, los precios no representan el mismo objeto.
La igualación puede atribuir costes estimados a las diferencias, exigir revisiones o solicitar una Best and Final Offer después del alineamiento técnico.
La comparación comercial solo adquiere significado después de la igualación técnica. Desviaciones, exclusiones, alternativas, proveedores considerados, documentación, pruebas e interfaces deben normalizarse para que el menor precio no represente simplemente un alcance menor o un riesgo transferido de regreso al Owner.
Evaluación comercial y coste total
Después de la igualación técnica entran precio, condiciones de pago, impuestos, reajuste, tipo de cambio, garantías, seguros, flujo de caja y exposición a cambios.
El menor precio nominal no siempre representa el menor coste esperado. Una propuesta con muchas calificaciones puede generar change orders durante la ejecución. Una propuesta más alta, pero completa y con riesgo bien definido, puede ofrecer mayor previsibilidad.
El análisis también debe observar las condiciones de pago. Adelantos elevados, hitos front-loaded o pagos no vinculados a evidencias pueden aumentar la exposición financiera del Owner.
Analizar el cronograma y la capacidad de ejecución
El cronograma de la propuesta debe ser técnicamente coherente. Las fechas agresivas no tienen valor si dependen de ingeniería, vendor data o entregas incompatibles con lead times reales.
El equipo de Project Controls puede verificar camino crítico, interfaces, long lead items, lógica de construcción, secuencia de puesta en marcha y disponibilidad de recursos.
Un cronograma creíble debe relacionar ingeniería, Procurement, fabricación, logística, construcción, completación y pruebas. La falta de integración entre estas redes es una señal de riesgo.
Evaluar los riesgos residuales de cada propuesta
Incluso después de la igualación, las propuestas pueden distribuir riesgos de forma diferente. Un contratista EPC puede aceptar determinada condición y otro solicitar una exclusión; uno puede asumir el plazo del proveedor y otro condicionarlo.
La decisión debe registrar los riesgos residuales y su impacto potencial. Una matriz de decisión puede considerar precio, técnica, plazo, riesgo y capacidad de ejecución con pesos definidos antes del resultado siempre que sea posible.
La Matriz de Decisión en Proyectos de Ingeniería puede apoyar procesos multicriterio cuando la elección no está determinada por un único factor.
Negociación: cerrar brechas, no reabrir todo el objeto
La negociación final debe consolidar desviaciones, premisas, garantías, cronograma, precio, responsabilidades y riesgos. El objetivo es cerrar las brechas identificadas durante la igualación.
Cualquier concesión técnica debe reflejarse en los documentos correspondientes. Modificar únicamente una cláusula comercial sin actualizar la especificación o la matriz de responsabilidades puede crear contradicciones.
También es necesario consolidar la lista de documentos que forman el contrato y el orden de prevalencia. La propuesta final, las aclaraciones y las adendas deben incorporarse de forma controlada.
Award y transición de la contratación a la ejecución
El award no termina el trabajo de Procurement; inicia la ejecución contractual. El equipo que negoció debe transferir al equipo de proyecto todas las premisas, desviaciones aceptadas, riesgos, compromisos y aclaraciones.
Un handover interno puede incluir contrato, anexos, TBE final, matriz de riesgos, cronograma, lista de interfaces, pendientes pre-NTP y obligaciones del Owner.
Sin esta transferencia, el equipo de ejecución puede administrar el contrato como si fuera el paquete original de la RFP e ignorar acuerdos de la negociación.
Qué exigir al contratista EPC inmediatamente después de la contratación
Los primeros entregables ayudan a transformar la propuesta en un plan ejecutable. Según el proyecto, pueden incluir:
- Project Execution Plan;
- cronograma detallado y baseline;
- lista maestra de documentos;
- plan de Procurement;
- vendor list;
- plan de calidad;
- matriz de interfaces;
- plan de riesgos;
- plan de construcción;
- plan de puesta en marcha;
- estrategia de documentación y handover;
- organización y matriz de responsabilidades.
Estos documentos deben ser coherentes con el contrato y establecer la gobernanza operativa.
Cómo debe gobernar el Owner después del award
La contratación integrada no elimina el seguimiento. El Owner necesita administrar sus propias obligaciones, controlar interfaces externas, revisar submittals, acompañar riesgos, verificar avance y preparar la aceptación.
La Owner’s Engineering puede apoyar desde la preparación de la RFP hasta la recepción final. Durante la ejecución, la actuación puede incluir Design Review, Procurement, fiscalización técnica, Project Controls, gestión de cambios, puesta en marcha y documentación.
El Contrato EPC en Ingeniería debe tratarse como baseline: las modificaciones deben seguir un proceso formal y mantener trazabilidad con requisitos y riesgos.
Después del award, el Owner deja de estar en una competencia y pasa a administrar una obligación de resultado. La gobernanza debe acompañar requisitos, submittals, interfaces, cambios, cronograma, calidad, Procurement, pruebas y evidencias sin asumir las responsabilidades que pertenecen al contratista EPC.
Cómo contratar prevención en lugar de corrección
Una contratación EPC de alta calidad invierte más esfuerzo antes del award para reducir el coste de resolver ambigüedades durante la ejecución. Esto no significa eliminar los cambios, sino disminuir cambios previsibles provocados por un alcance débil, interfaces no mapeadas y criterios de aceptación tardíos.
La combinación de FEED, requisitos, estrategia de contratación, TBE, Owner’s Engineering y puesta en marcha crea una jornada de prevención. Cada herramienta actúa en un punto diferente: definición, selección, gobernanza y verificación.
Cuando estos mecanismos se tratan como partes de un único proceso, el Owner deja de reaccionar a problemas de campo y pasa a controlar el proyecto desde el origen de las decisiones.
Checklist de contratación EPC
Antes del award, el Owner debería poder responder objetivamente:
- ¿Por qué EPC es el modelo elegido?
- ¿Qué requisitos son obligatorios?
- ¿Qué ingeniería es referencial y cuál es prescriptiva?
- ¿Dónde están los battery limits?
- ¿Quién responde por cada interfaz?
- ¿Qué riesgos fueron transferidos y cuáles permanecen con el Owner?
- ¿Cómo se formaron el precio y el plazo?
- ¿Qué long lead items afectan el camino crítico?
- ¿Qué vendors son críticos?
- ¿Cómo se verificarán la calidad y las inspecciones?
- ¿Qué pruebas demuestran el desempeño?
- ¿Qué significan mechanical completion y ready for commissioning?
- ¿Qué documentos son condición de handover?
- ¿Cómo se tratarán los cambios y claims?
- ¿Qué garantías permanecen después de la aceptación?
- ¿Qué obligaciones del Owner pueden afectar el cronograma?
- ¿Todas las calificaciones de la propuesta final fueron consolidadas en el contrato?
Si varias respuestas permanecen indefinidas, el proceso todavía no está listo para award, aunque exista una propuesta comercial aparentemente atractiva.
Consideraciones finales
La contratación EPC es un proceso de ingeniería, Procurement y gobernanza antes de ser una negociación de precio. El Owner necesita transformar la necesidad en requisitos, madurar interfaces y riesgos, definir desempeño y construir una RFP que produzca propuestas comparables.
La precalificación, la TBE y la igualación son esenciales porque el precio solo tiene significado cuando las empresas ofrecen obligaciones equivalentes. Las calificaciones, exclusiones y premisas deben consolidarse antes del award para que el contrato final represente aquello que fue efectivamente negociado.
Después de la firma, la gobernanza continúa. El contrato se convierte en baseline para ingeniería, Procurement, construcción, cambios, pruebas y aceptación. Cuando la preparación fue consistente, el contratista EPC posee libertad suficiente para integrar la solución y el Owner dispone de criterios suficientes para verificar el resultado sin asumir la ejecución.
Referencias técnicas
[1] INTERNATIONAL FEDERATION OF CONSULTING ENGINEERS — FIDIC. Conditions of Contract for EPC/Turnkey Projects — Silver Book. 2.ª ed. Geneva: FIDIC, 2017. Disponible en: https://fidic.org/books/epcturnkey-contract-2nd-ed-2017-silver-book
[2] WORLD BANK. Procurement Framework and Standard Procurement Documents. Washington, DC: World Bank. Disponible en: https://www.worldbank.org/en/projects-operations/products-and-services/brief/procurement-new-framework
[3] PROJECT MANAGEMENT INSTITUTE — PMI. Standards and PMBOK Guide. Newtown Square: PMI. Disponible en: https://www.pmi.org/pmbok-guide-standards
Preguntas frecuentes
Primero confirme que EPC es el modelo adecuado; después evalúe readiness y defina requisitos, ingeniería de referencia, alcance, interfaces, riesgos, desempeño y aceptación antes de estructurar la RFP.
No en todos los casos, pero se necesita una ingeniería de referencia compatible con la complejidad del proyecto. FEED es especialmente útil en proyectos industriales y multidisciplinarios.
Technical Bid Evaluation es la evaluación técnica estructurada de las propuestas frente a requisitos y criterios, registrando conformidades, desviaciones y excepciones antes de la comparación comercial.
Porque las propuestas pueden tener alcances, exclusiones, obligaciones de desempeño, pruebas y riesgos diferentes. El precio solo es comparable después de la igualación técnica y comercial.
Mediante una precalificación proporcional al objeto, evaluando experiencia, capacidad de ingeniería, Procurement, construcción, gestión, calidad, puesta en marcha, situación financiera y equipo.
Requisitos, alcance, interfaces, riesgos, precio, plazo, calificaciones, garantías, pruebas, documentación y todas las aclaraciones y adendas que modificaron la propuesta.
Cuando el Owner necesita apoyo independiente para requisitos, ingeniería de referencia, RFP, TBE, negociación, gobernanza de la ejecución, pruebas y recepción técnica.
Materiales técnicos complementarios
Soluciones relacionadas
- Gobernanza de Proyectos, Programas y Portafolios
- Gestión de Contratos, Alcance y Entregables
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
Servicios relacionados
- EPC — implantación turnkey
- Owner’s Engineering
- FEED — Front-End Engineering Design
- Procurement Técnico
- Gestión de Proyectos y Project Controls
- Recepción Técnica
Contenidos principales sobre el tema
- EPC en Ingeniería: qué es y cómo funciona
- Proyecto EPC: de la Ingeniería a la entrega
- EPC Turnkey en Ingeniería
- Contrato EPC en Ingeniería
- EPC vs. EPCM: diferencias y cuándo usar cada modelo
