Alcance del URS y la solicitud de presupuesto (RFQ) para equipos de alta contención: requisitos, documentación del proveedor y límites de validación

Los equipos de compras que emiten una solicitud de presupuesto basándose en una especificación de requisitos de usuario (URS) incompleta rara vez detectan la laguna en la fase de presupuestación. El problema sale a la luz durante la puesta en servicio, cuando un ingeniero de cualificación intenta redactar una prueba de aceptación para una función de contención que se describió en la URS con un lenguaje de rendimiento demasiado vago como para poder probarla, y el proveedor puede demostrar, correctamente, que el equipo suministrado cumple al pie de la letra con todo lo solicitado. La consecuencia es una reescritura del protocolo bajo presión de tiempo, un retraso en la aceptación in situ y una renegociación sobre quién es responsable de las pruebas presenciadas —ninguna de estas cuestiones era visible cuando se envió el expediente de licitación—. Entender dónde trazar la línea divisoria entre lo que debe figurar en las URS, lo que debe aparecer en la respuesta a la solicitud de presupuesto y a quién se asigna formalmente la responsabilidad de la validación antes de la adjudicación es el criterio que distingue una contratación bien controlada de otra que acumula disputas en la segunda mitad del proyecto.

Requisitos del comprador que deben figurar en los URS

El URS no es una lista de deseos ni una especificación simplificada. Es el documento al que se remitirán todas las actividades de validación posteriores —FAT, SAT, IQ, OQ, PQ— para determinar si el sistema entregado cumple con los objetivos del usuario. Si el URS presenta lagunas estructurales o utiliza un lenguaje ambiguo que no puede traducirse en una condición de prueba cuantificable, el departamento de control de calidad no tendrá una base justificable para su aceptación, y ningún documento posterior podrá subsanarlo de forma retroactiva.

Los componentes estructurales de un URS bien estructurado para equipos de alta contención siguen un patrón coherente en la práctica profesional de los proyectos: una introducción y una descripción general que establecen el contexto operativo y el marco normativo; requisitos funcionales que definen el rendimiento de la contención, las exigencias de los procesos asépticos y el comportamiento de los enclavamientos de seguridad; requisitos no funcionales que abordan la fiabilidad, la facilidad de mantenimiento y las restricciones medioambientales; definiciones de interfaces que abarcan las conexiones físicas, las conexiones a redes de servicios y los puntos de integración del sistema de control; restricciones y supuestos que documentan los límites de espacio, la disponibilidad de servicios y las condiciones previstas del emplazamiento; y una sección de documentación y entregables que enumera los resultados requeridos con sus criterios de aceptación. Este último componente es donde el URS suele fallar con mayor frecuencia. Cuando se omite la sección de entregables o se deja en términos genéricos, el proyecto llega a la fase de entrega sin criterios acordados, y ambas partes descubren que partían de supuestos diferentes sobre lo que constituye un paquete completo.

El riesgo no es que el URS sea erróneo de forma evidente, sino que sea lo suficientemente preciso como para generar una propuesta coherente, pero a la vez demasiado impreciso como para respaldar un protocolo de cualificación. Expresiones como “rendimiento de contención adecuado” o “filtración HEPA apropiada” son suficientes para obtener una respuesta del proveedor; sin embargo, no lo son para redactar una prueba que un responsable de control de calidad pueda defender ante un inspector regulador. El anexo 15 del volumen 4 de EudraLex considera que los requisitos documentados y definidos constituyen la base de toda actividad de cualificación y validación, no porque prescriba el formato del URS, sino porque da por sentado que ya existe algo con criterios de aceptación comprobables antes de que comience la cualificación. Si el URS no lo proporciona, el anexo 15 no ayuda a recuperarlo.

Componente URSLo que debe definirRiesgo si la información es imprecisa o falta
Introducción y descripción generalContexto operativo, uso previsto y marco de cumplimiento normativoEl proveedor podría interpretar erróneamente la clasificación de contención, lo que daría lugar a equipos que no cumplen con la normativa.
Requisitos funcionalesRendimiento de contención, requisitos de los procesos asépticos, enclavamientos de seguridadEl equipo cumple con los requisitos del pliego de condiciones, pero no supera las pruebas de contención de control de calidad.
Requisitos no funcionalesFiabilidad, facilidad de mantenimiento, restricciones medioambientales, normas de limpiezaLas deficiencias en la explotación y el mantenimiento se convierten en problemas tras la entrega
InterfacesConexiones físicas, acoplamientos a la red de servicios públicos, puntos de integración del sistema de controlLa falta de claridad sobre la propiedad de las interfaces provoca desviaciones del alcance y fallos de integración
Restricciones y supuestosLimitaciones de espacio, disponibilidad de servicios, restricciones de acceso, condiciones previstas del emplazamientoLas hipótesis de la propuesta difieren de la realidad in situ, lo que da lugar a órdenes de modificación
Documentación y entregablesLista de documentos necesarios con criterios de aceptaciónLos registros de traspaso carecen de criterios definidos, lo que retrasa la aceptación definitiva

La sección de requisitos funcionales merece una atención especial en el caso de los aisladores OEB4/OEB5 y los sistemas de contención BSL-3/4, en los que el rendimiento de la contención debe expresarse en términos que generen límites de aceptación específicos —tasas de fuga, diferenciales de presión, tiempos de respuesta de los enclavamientos— en lugar de categorías. Un URS que diga “el aislador debe mantener una presión negativa” es incompleto. Una que especifique el rango de diferencia de presión operativa, la desviación admisible antes de que se active la alarma y el tiempo de respuesta para la activación automática del enclavamiento proporciona a la Especificación de Diseño Funcional del proveedor una base de referencia y ofrece al departamento de control de calidad elementos que comprobar.

Documentación del proveedor que debe incluirse en la respuesta a la solicitud de presupuesto

La solicitud de presupuesto (RFQ) no es una simple solicitud de precios. Se trata del mecanismo que permite traducir los requisitos del documento de requisitos de usuario (URS) en compromisos por parte de los proveedores que puedan evaluarse antes de la adjudicación. Cuando la RFQ no especifica qué documentación debe aportar el proveedor, el comprador recibe propuestas que, aunque son comparables desde el punto de vista comercial, resultan incomparables desde el punto de vista técnico: diferentes supuestos sobre el alcance, diferentes entregables de validación y diferentes interpretaciones sobre la titularidad de las interfaces, todo ello con precios fijados como si fueran equivalentes.

El elemento que más falta se echa en la mayoría de las respuestas a las solicitudes de presupuesto (RFQ) de alta contención es la Especificación Funcional de Diseño (FDS). Exigir la FDS en la fase de presupuesto —o, como mínimo, una versión preliminar que asocie cada requisito del URS a una solución de diseño concreta— es el único mecanismo que mantiene intacta la cadena de trazabilidad entre el URS y el diseño antes de la adjudicación. Sin ella, el URS existe como un documento independiente y la propuesta del proveedor como otro documento aparte, y la brecha entre ambos es donde surgen las disputas sobre el alcance. Solicitar la FDS durante la solicitud de presupuesto aumenta la carga de ingeniería inicial para el proveedor y, en la práctica, puede reducir el número de proveedores que responden. Se trata de una verdadera disyuntiva. El equipo de compras que acepta propuestas vagas con el fin de mantener una cartera más amplia de proveedores está trasladando el coste de ingeniería a la fase posterior a la adjudicación, donde se materializa en forma de órdenes de modificación.

Una respuesta completa a la solicitud de presupuesto para esta clase de equipos también debe incluir un calendario de hitos que abarque las fechas de ingeniería, adquisición, pruebas de aceptación en fábrica (FAT), pruebas de aceptación en el sitio (SAT), calificación de instrumentos (IQ), calificación operativa (OQ) y calificación de rendimiento (PQ), así como la entrega; una estructura de informes que especifique la frecuencia y el formato de las revisiones de progreso; una evaluación de competencias que identifique al personal responsable del diseño, las pruebas y la entrega; y condiciones comerciales que definan los hitos de pago, las condiciones de las órdenes de modificación y los límites de la garantía. Cada elemento desempeña una función de control diferente durante la ejecución del proyecto, y omitir cualquiera de ellos genera un tipo específico de ambigüedad tras la adjudicación.

Elemento obligatorio de la respuesta a la solicitud de presupuestoLo que debe demostrarRiesgo en caso de no facilitarse
Lista de entregablesEquipos, documentación y servicios incluidos en la propuestaControversias posteriores a la adjudicación sobre qué entra o qué queda fuera del alcance
Calendario de hitosFechas de ingeniería, adquisición, FAT, SAT, IQ/OQ/PQ y entregaDesajuste del calendario con respecto a la preparación del centro y la planificación de la validación
Requisitos de informaciónFormatos, frecuencia y puntos de revisión de los informes de progresoSe desconoce el estado del proyecto; los retrasos se detectaron demasiado tarde
Evaluación de competenciasCualificaciones del personal encargado del diseño, las pruebas y la entregaEjecución deficiente, repetición de trabajos o incumplimientos normativos
Condiciones comercialesPlazos de pago, condiciones de las órdenes de modificación y límites de la garantíaSorpresas financieras y riesgos relacionados con la aprobación de la financiación
Especificación de diseño funcional (FDS)Cómo el diseño del proveedor traduce los requisitos de los URS en una solución concretaSe ha interrumpido la trazabilidad entre URS y el diseño; aumenta el riesgo de que los equipos no cumplan con los requisitos

En el caso de los equipos con funcionalidad de descontaminación integrada —como las cajas de paso de VHP que sirven como límites de contención—, los requisitos del FDS deben abordar explícitamente los parámetros de desarrollo del ciclo y los criterios en los que el proveedor se ha basado para dimensionar el sistema de descontaminación. Revisar qué documentación se espera que presenten los proveedores antes de la solicitud de presupuesto (RFQ) para equipos con VHP integrado ayuda a aclarar qué debe contener realmente un FDS completo para estos sistemas. La solicitud de presupuesto debe exigir dicha documentación, sin aceptar como sustituto una mera referencia a las especificaciones estándar del producto.

Límites de validación en FAT, SAT e IQ/OQ/PQ

La fuente más persistente de controversias tras la adjudicación en la contratación de equipos de alta contención es una cuestión sin resolver: quién es responsable de cada fase de prueba, según qué protocolo, con arreglo a qué criterio de aceptación y en qué instalaciones. Si esto no se aclara en la solicitud de presupuesto, se resuelve en la negociación posterior a la adjudicación, en un momento en el que el poder de negociación del comprador ya se ha transferido en gran medida al proveedor.

La definición de los límites de validación no es un problema de planificación de la validación, sino un problema de contratación que debe resolverse antes de que se publique el pliego de condiciones. La norma ASTM E2500-25 respalda el principio de que las actividades de verificación deben ajustarse a las especificaciones documentadas y basarse en una evaluación científica y basada en el riesgo; sin embargo, no resuelve la cuestión contractual de quién redacta el protocolo, quién actúa como testigo del ensayo y quién firma el acta de aceptación. Esa asignación debe figurar en la solicitud de presupuesto como un requisito de contratación, y no surgir en la reunión de lanzamiento del proyecto tras la adjudicación.

Las cuestiones relativas a los límites en cada fase abarcan todo el ciclo de vida del proyecto, y cada fase conlleva una consecuencia específica si no se resuelve la atribución de responsabilidades.

Fase del proyectoPregunta clave sobre el límite de validaciónConsecuencias en caso de ambigüedad
Diseño¿Se ajusta la documentación de diseño del proveedor a los criterios de aceptación de los requisitos de diseño (URS)?Desviaciones en el diseño, modificaciones en fases avanzadas y fallos en la homologación
Adquisiciones¿Quién verifica las especificaciones de los componentes y los entregables de los proveedores y subcontratistas?Piezas no conformes detectadas durante la puesta en servicio
Construcción¿Quién se encarga de garantizar que la instalación cumpla con las normas de contención?Costes de remediación y retrasos en la validación
Puesta en servicio¿Quién lleva a cabo las comprobaciones previas a la validación y según qué criterios?Diferencias entre la puesta en servicio y la aceptación de las pruebas de calificación de instrumentos (IQ) y de calificación operativa (OQ)
Validación (FAT, SAT, IQ/OQ/PQ)¿Qué parte es responsable de cada fase de prueba, de la asistencia de los testigos y de la firma de aprobación?El alcance se negocia tras la adjudicación; los límites de las pruebas se amplían
Start-up¿Quién se encarga de la asistencia in situ y de resolver los problemas operativos iniciales?Tiempo de inactividad y trabajos de corrección de la cualificación operativa
Traspaso¿Qué registros deben recopilarse y quién los considera definitivos?Documentación de entrega incompleta; retraso en la recepción definitiva

En la práctica, el límite entre la puesta en servicio y la IQ es el que más controversia suscita. Las comprobaciones de puesta en servicio previas a la validación las lleva a cabo el equipo de puesta en servicio del proveedor según sus propios criterios. La IQ comienza cuando el sistema de calidad del centro asume la responsabilidad del protocolo de cualificación. Si la solicitud de presupuesto (RFQ) no define dónde se produce ese traspaso —qué actividades corresponden a la puesta en servicio y cuáles a la IQ, y qué parte debe aprobar ambas—, el proveedor completará la puesta en servicio utilizando sus propios criterios y presentará el sistema como listo para la IQ sin las pruebas de precalificación que el protocolo del comprador da por hecho que ya se han generado. Esta laguna se describe con mayor detalle en el contexto de la puesta en marcha BIBO, donde habitualmente se omiten puntos específicos de IQ y OQ en el traspaso del proveedor a la planta. Este mismo patrón de fallos se aplica a cualquier sistema de alta contención que requiera una cualificación formal antes de su puesta en servicio.

Supuestos sobre la interfaz que modifican el alcance de la propuesta

Cada contratación de equipos de alta contención implica al menos a tres partes: el proveedor del equipo, la empresa de ingeniería o EPC responsable de los servicios públicos y la integración civil, y el equipo in situ del cliente. Por lo general, cada parte da por sentado que las demás han documentado la interfaz entre su ámbito de actuación y el ámbito adyacente. En la mayoría de los proyectos, ninguna de ellas lo ha hecho. El resultado no es un conflicto que surja en el momento de la adjudicación del contrato, sino un conflicto que aparece cuando el equipo llega a la obra y las conexiones de los servicios se encuentran en una ubicación incorrecta, a una presión inadecuada o bajo una responsabilidad que ningún contrato asigna explícitamente.

La ambigüedad en las interfaces modifica el alcance de la propuesta de una forma concreta: cada proveedor fija sus precios basándose en sus propias suposiciones sobre lo que aportará el cliente. Cuando esas suposiciones difieren entre las distintas propuestas, el comprador está comparando precios que reflejan diferentes costes totales del proyecto, y no diferentes niveles de eficiencia de los proveedores. Un proveedor que da por hecho que el cliente proporcionará los conductos y las conexiones a los servicios públicos fijará un precio más bajo que otro que los incluya, no porque sean más baratos, sino porque ha incluido menos trabajo en el alcance de su propuesta. La solicitud de presupuesto debe eliminar esta ambigüedad especificando, para cada área de interfaz, exactamente de qué es responsable el proveedor y dónde termina exactamente el alcance de su trabajo.

Área de interfazAspectos que deben aclararse en la solicitud de presupuestoConsecuencias de la ambigüedad
Ingeniería civil y estructuralPreparación de los cimientos, trazado de las canalizaciones, barreras de contenciónEl proveedor asume que las instalaciones están preparadas, cuando en realidad no es así; sobrecostes
Proceso/ServicioConexiones de gas, agua, residuos y vapor limpio, y límites de presiónLas responsabilidades relativas a la conexión de los servicios públicos cambian tras la adjudicación
Controles/AutomatizaciónIntegración BMS/SCADA, intercambio de señales, gestión de alarmasLas deficiencias en el alcance de los controles dan lugar a soluciones manuales o a una reingeniería de los procesos
Responsabilidades internas/del clientePermisos de centro, supervisión de la seguridad, responsabilidad sobre los protocolos de validaciónEl cliente cree que el proveedor se encarga de la validación, mientras que el proveedor da por hecho que los protocolos los establece el cliente.

La interfaz de control y automatización es donde las suposiciones provocan las correcciones más costosas a mitad del proyecto. La integración de BMS y SCADA para sistemas de contención BSL-3/4 suele implicar intercambios de señales, lógica de alarmas y secuencias de enclavamientos que abarcan tanto la arquitectura de control del proveedor del equipo como la infraestructura de gestión del edificio de la instalación. Si la solicitud de presupuesto no define los límites del alcance de la integración —qué parte suministra la lógica de integración, qué parte es responsable de las pruebas de integración y qué parte se encarga de la puesta en servicio del sistema combinado—, el proyecto dará lugar a dos subsistemas validados que no se comunican entre sí de forma fiable, y el coste de la corrección recaerá sobre aquella parte a la que se pueda atribuir la responsabilidad de dicha deficiencia.

Documentación de entrega necesaria antes de la aceptación definitiva

La aceptación definitiva no es una ceremonia, sino un trámite del sistema de calidad que requiere un conjunto definido de documentos que demuestren que el equipo se ha fabricado, instalado y verificado de acuerdo con los requisitos de diseño (URS). Si dichos documentos no se especifican en los requisitos de diseño (URS) ni se exigen en la solicitud de presupuesto (RFQ), el proyecto llega a la fase de entrega con una documentación incompleta y ambas partes discrepan sobre lo que se necesita para completarla.

Un paquete completo de traspaso para equipos de alta contención debe incluir, como mínimo: el expediente de seguridad recopilado con toda la documentación de diseño pertinente; los registros de construcción e instalación que recojan las certificaciones de los materiales, las verificaciones dimensionales y los registros de soldaduras o uniones relevantes para la integridad de la contención; los registros de puesta en servicio que demuestren el rendimiento funcional previo a la cualificación según criterios definidos; los registros de cualificación que abarquen la cualificación de instalación (IQ), la cualificación operativa (OQ) y, cuando proceda, la cualificación de rendimiento (PQ), con los registros de ensayo completados, los registros de desviaciones y las firmas de aceptación autorizadas; y cualquier punto pendiente de la lista de tareas pendientes con plazos de resolución acordados y asignación de responsabilidades. El expediente de seguridad y los registros de cualificación no son intercambiables: uno documenta cómo se construyó el sistema y qué riesgos se gestionaron durante la construcción, mientras que el otro documenta si el sistema instalado funciona según lo especificado. Ambos deben estar presentes antes de que un responsable de control de calidad pueda dar por concluido el proyecto de forma justificada.

El patrón de fallo en este caso es la compresión bajo la presión de los plazos. Cuando el calendario del proyecto es ajustado, la recopilación del paquete de entrega se trata como una tarea administrativa que puede realizarse en paralelo con la puesta en marcha final. En la práctica, la falta de registros de fases anteriores del proyecto —una certificación de soldadura que no se registró, una prueba de puesta en marcha previa a la IQ que nunca se documentó formalmente— sale a la luz durante la revisión final del paquete y genera retrasos desproporcionados en relación con el trabajo subyacente necesario. Exigir que la estructura del paquete de entrega, incluidos su contenido y los criterios de aceptación, figure en los requisitos de diseño (URS) y en la lista de entregables de los proveedores de la solicitud de presupuesto (RFQ) es el único mecanismo que evita que esas lagunas se acumulen de forma imperceptible a lo largo del ciclo de vida del proyecto.

En lo que respecta a la infraestructura de los laboratorios BSL-3, un enfoque estructurado de la documentación de puesta en servicio —con puntos de control definidos desde la construcción hasta la cualificación final— ofrece un modelo útil sobre cómo deben organizarse los requisitos de documentación de traspaso antes de que comiencen los trabajos. El proceso paso a paso de puesta en servicio descrito para las instalaciones BSL-3 ilustra cómo debe establecerse la estructura de mantenimiento de registros antes de la primera actividad de instalación, y no elaborarse a posteriori.

Punto de decisión antes de enviar el paquete de presupuesto

La publicación de la solicitud de presupuesto (RFQ) supone un punto de no retorno en un sentido concreto y a menudo subestimado. Una vez presentadas las propuestas, el alcance queda fijado a lo descrito en la RFQ. Los cambios en los requisitos del URS tras la recepción de las propuestas requieren o bien una nueva licitación —lo que retrasa el proyecto— o bien se negocian como aclaraciones del alcance, lo que transfiere el poder de negociación al proveedor. La implicación práctica es que la decisión de publicar la RFQ debería funcionar como un control interno formal, y no como un hito en el calendario.

Antes de que se pueda superar esa etapa de forma justificada, deben ultimarse tres documentos básicos. En primer lugar, el URS debe estar completo y aprobado —no en borrador, ni “sustancialmente completo”—. En segundo lugar, debe existir un calendario general que abarque las fases de puesta en servicio, cualificación y entrega, con hitos clave asociados a cada una de ellas. Sin él, el calendario propuesto por el proveedor no tiene ningún punto de referencia con el que alinearse, y la falta de sincronización entre los plazos y la disponibilidad de la obra, así como los plazos de validación, solo se hace evidente tras la adjudicación. En tercer lugar, un documento de ejecución del proyecto debe definir la estrategia para el diseño, la adquisición, la construcción, la puesta en servicio, la validación, la puesta en marcha y la entrega, con las fases y los límites de validación explícitamente establecidos. Este es el documento que permite resolver las disputas sobre los límites de validación por referencia, en lugar de mediante negociación. Un cuarto elemento —una estimación de costes de referencia vinculada a los requisitos de diseño (URS), al calendario y al plan de ejecución— proporciona al director del proyecto el único punto de referencia defendible para gestionar los cambios en el alcance tras la adjudicación y respalda las decisiones de aprobación de la financiación, que no pueden revisarse una vez formalizado el contrato.

Documento de referenciaQué estableceRiesgo si no se formaliza antes de la solicitud de presupuesto
URS (Ámbito de aplicación)Todos los requisitos funcionales, no funcionales, de interfaz y de documentaciónLos proveedores presentan propuestas que no se ajustan al alcance del proyecto o que entran en conflicto con él
Calendario generalFases de puesta en servicio, cualificación y entrega, con hitos claveLos plazos de los proveedores no se ajustan a la disponibilidad de las instalaciones ni a los plazos de validación
Documento de ejecución del proyectoEstrategia para el diseño, la adquisición, la construcción, la puesta en marcha, la validación, el inicio de operaciones y la entrega, con fases y límites definidosLos límites de validación se negociarán tras la adjudicación
Estimación del coste inicialReferencia de costes internos vinculada al URS, al calendario y al plan de ejecuciónEl director del proyecto no puede gestionar los cambios en el alcance; la aprobación de la financiación corre peligro

El riesgo de fracaso no radica en que los equipos desconozcan la existencia de estos documentos —la mayoría de los jefes de proyecto saben que deberían existir—. El riesgo es que la solicitud de presupuesto se publique mientras uno o varios de ellos siguen en fase de borrador, ya que la presión del calendario para disponer de las propuestas supera el riesgo de contar con bases de referencia incompletas. Cuando eso ocurre, el jefe de proyecto pierde la referencia de control del alcance justo en el momento en que el proyecto comienza a contraer compromisos. Los cambios en el alcance que se producen tras la adjudicación, sin un URS (Requisitos de Sistema) establecido como referencia para evaluarlos, carecen de un mecanismo de resolución objetivo y son resueltos por quien ocupe la posición comercial más fuerte en ese momento del proyecto.

La decisión más trascendental en este proceso de contratación se toma antes de contactar con ningún proveedor: si los requisitos de especificación del usuario (URS) son lo suficientemente específicos como para generar criterios de aceptación verificables, y si la solicitud de presupuesto (RFQ) exige al proveedor pruebas que mantengan intacta la cadena de trazabilidad entre los URS y el diseño a lo largo de las pruebas FAT, SAT e IQ/OQ/PQ. Esas dos condiciones no son requisitos administrativos previos, sino el mecanismo mediante el cual el comprador mantiene el control sobre el alcance, la responsabilidad de la validación y la calidad del traspaso a lo largo de todo el ciclo de vida del proyecto.

Antes de publicar el paquete de la solicitud de presupuesto, el equipo debe poder responder a tres preguntas con respuestas documentadas y aprobadas: ¿Qué criterio de rendimiento específico determina que cada función de contención apruebe o suspenda? ¿Qué parte es responsable de cada fase de la prueba de validación y elabora el acta de aceptación? ¿Y qué contiene un paquete de entrega completo y cuáles son los criterios para aceptarlo? Si alguna de estas preguntas queda sin resolver, la solicitud de presupuesto no está lista, y las disputas que surgirán tras la adjudicación ya están garantizadas.

Preguntas frecuentes

P: ¿Qué ocurre si el URS ya se ha redactado en forma de borrador antes de que se prepare la solicitud de presupuesto? ¿Debe el departamento de compras esperar a que se apruebe definitivamente o seguir adelante?
R: El departamento de compras debe esperar a que el URS esté totalmente aprobado antes de publicar la solicitud de presupuesto. Un borrador del URS deja abierta a revisión la descripción de las prestaciones de contención, lo que significa que las propuestas de los proveedores se valorarán en función de requisitos que pueden cambiar, lo que da lugar a disputas sobre el alcance del proyecto o a una nueva licitación. La autorización para publicar la solicitud de presupuesto no tiene ningún valor práctico si el documento al que se refiere sigue estando sujeto a revisión interna.

P: Si un proveedor se niega a facilitar una especificación de diseño funcional en la fase de presupuesto, ¿eso lo descarta de la selección?
R: No de forma automática, pero su propuesta debería considerarse técnicamente incompleta a efectos de evaluación. El FDS es el mecanismo que mantiene intacta la trazabilidad entre el URS y el diseño antes de la adjudicación. Un proveedor que no pueda o no quiera presentar ni siquiera un FDS preliminar en la fase de solicitud de presupuesto deja al comprador sin una base objetiva para evaluar si el diseño propuesto cumple realmente los requisitos de contención especificados —una laguna que surgirá como una controversia sobre el alcance tras la adjudicación, en lugar de como motivo de descalificación durante la evaluación—.

P: ¿En qué momento pasa la definición de la interfaz de ser responsabilidad del comprador en los URS a ser responsabilidad del contratista (EPC) o del equipo de ingeniería de obra?
R: El URS debe definir todos los límites de interfaz que afecten a la función de contención o al alcance de la validación, incluidas las condiciones de suministro de servicios públicos, los puntos de integración del sistema de control y las terminaciones de las conexiones físicas. Cualquier aspecto que el artículo describa como susceptible de aclaración en la solicitud de presupuesto (RFQ) en cuanto a funciones y responsabilidades entre las partes de ingeniería civil, de procesos y de controles implica que el URS ya ha establecido el límite técnico; la RFQ, a su vez, asigna la titularidad contractual de cada lado de dicho límite. Si el URS deja una interfaz sin definir, ninguna aclaración posterior en la RFQ podrá subsanarlo por completo: el proveedor simplemente fijará el precio basándose en sus propias suposiciones.

P: ¿Es necesaria una estimación de costes de referencia si el proyecto ya cuenta con un presupuesto financiado y aprobado a través de la planificación interna de inversiones?
R: Sí, porque un presupuesto aprobado no es lo mismo que una estimación de referencia vinculada al alcance. El objetivo de la estimación de costes de referencia no es justificar la financiación, sino proporcionar al director del proyecto un punto de referencia para evaluar las solicitudes de cambio en el alcance tras la adjudicación. Sin una estimación de costes que se remonte al URS firmado, al calendario y al plan de ejecución, no existe un punto de referencia objetivo para determinar si una orden de cambio posterior a la adjudicación refleja un aumento real del alcance o si se trata de un proveedor que se recupera de una oferta a la baja. La financiación aprobada sin una referencia de alcance hace que el control del alcance dependa por completo de la negociación comercial.

P: ¿Son igualmente aplicables los consejos de este artículo tanto a la adquisición de sistemas de contención a medida a un único proveedor como a los procesos competitivos de solicitud de presupuesto con varios proveedores?
R: Los requisitos de trazabilidad —URS completo, FDS en la oferta, responsabilidad de validación definida, registros de traspaso especificados— se aplican en ambos casos, pero las consecuencias de omitirlos difieren. En un proceso competitivo, unos requisitos vagos en la solicitud de presupuesto dan lugar a propuestas con alcances incomparables, lo que hace que la evaluación basada en el precio resulte engañosa. En la contratación con un único proveedor, esas mismas omisiones transfieren todo el poder de negociación al proveedor antes de formalizar el contrato, ya que no existe presión competitiva para mantener conservadoras las hipótesis sobre el alcance. La disciplina en la preparación es la misma; el perfil de riesgo de omitirla varía en función de la estructura comercial.

Imagen de Barry Liu

Barry Liu

Hola, soy Barry Liu. He pasado los últimos 15 años ayudando a los laboratorios a trabajar de forma más segura mediante mejores prácticas de equipos de bioseguridad. Como especialista certificado en cabinas de bioseguridad, he realizado más de 200 certificaciones in situ en instalaciones farmacéuticas, de investigación y sanitarias de toda la región Asia-Pacífico.

Noticias relacionadas

Desbloquear la innovación: Soluciones biotecnológicas integrales de QUALIA

En el dinámico panorama de la biotecnología, QUALIA destaca como líder en innovación, colaboración y compromiso con el avance de la asistencia sanitaria. A continuación, se ofrece una descripción detallada de las características y capacidades clave de los productos y servicios de QUALIA. Características de los productos (PF) Proyectos llave en mano: QUALIA se especializa en proyectos llave en mano, ofreciendo soluciones completas y listas para su uso en los sectores farmacéutico, de medicamentos veterinarios y de tecnología de bioseguridad. Sus servicios incluyen: Diseño conceptual: desarrollo de la visión inicial y las especificaciones. Diseño básico: creación de un marco para esbozar la disposición de los sistemas y garantizar su viabilidad. Diseño detallado: elaboración de planos y especificaciones exhaustivos para la construcción o la fabricación. Equipos de bioseguridad QUALIA ofrece una amplia gama de productos, tales como: dispositivos de purificación, sistemas de bioseguridad, sistemas de climatización, sistemas de automatización, servicios de validación, aparatos de proceso y tuberías estériles. Tecnologías de contención QUALIA cuenta con una sólida trayectoria

Scroll al inicio
Caja de transferencia de bioseguridad: Tipos y guía de selección para aplicaciones BSL | Logotipo de qualia 1

Póngase en contacto con nosotros

Póngase directamente en contacto con nosotros: [email protected]