News Banner Illustration

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones

04
2026.08

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones

09:28

A drone-detection RFI or RFP should translate the approved threat model, site basis and operating workflow into measurable supplier responses. It should not ask vendors to interpret an undefined mission or rely on brochure terms such as “360-degree detection,” “AI classification” or “camera linkage.” Every mandatory claim needs a response field, evidence source, responsible party and acceptance method. Use the parent Guía de Adquisición de Radar para Detección de Drones y Vigilancia a Baja Altitud to approve the threat model, sensor architecture and site basis before issuing this document.

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones

1. Congele la base de adquisiciones antes de emitir el RFP

  • Activos protegidos, zonas de vigilancia y corredores de aproximación prohibidos.
  • Clases de objetivo, dimensiones o suposiciones RCS, velocidad, altitud y rutas representativas.
  • Tiempo de advertencia requerido, decisión del operador y flujo de trabajo de respuesta.
  • Roles de sensores aprobados, interfaces externas de la plataforma y límite de ciberseguridad.
  • Base de la encuesta del sitio, ubicaciones propuestas, supuestos de zona ciega y responsabilidad de la infraestructura.
  • Etapas de aceptación en fábrica, en el campo y en el sitio, y los datos que deben conservarse.

Si estos elementos no se aprueban, la RFP recopilará soluciones incompatibles en lugar de respuestas comparables. Resuelva primero la línea base, luego permita que los proveedores propongan alternativas conformes con las desviaciones claramente identificadas.

2. Definir Evidencia Obligatoria y Entregables

La RFP debe indicar qué evidencia y documentos de entrega debe presentar cada respondedor. El propósito no es clasificar a los proveedores dentro de esta guía; es evitar que afirmaciones vagas se conviertan en suposiciones contractuales no comprobadas.

Categoría de evidencia requerida Envío obligatorio RFP
Evidencia de implementación comparable Proyectos de referencia con objetivos, entorno, arquitectura y escala similares; datos de contacto solo donde se permita su divulgación.
Evidencia de desempeño Informes de prueba que indiquen el método de medición, la configuración, la definición del objetivo, las condiciones de operación, la disponibilidad de los datos en bruto y las limitaciones.
Entregables de ingeniería Modelo de cobertura, diseño de interfaz, planos de instalación, método de puesta en marcha, plan de calibración y responsabilidad de solución de problemas.
Paquete de interfaz Documentos controlados, mensajes de muestra, definiciones de campo, herramientas de prueba, versiones soportadas, proceso de control de cambios y propietario de integración nombrado.
Documentos de calidad y cumplimiento Solo documentos de calidad, ambientales, EMC, radio, seguridad y acceso al mercado aplicables al destino para la configuración ofrecida.
Entregables de ciberseguridad Límite de arquitectura, modelo de control de acceso, política de parches, informe de vulnerabilidades, registro, reglas de acceso remoto y gobernanza de actualizaciones.
Entregables de soporte Tiempos de respuesta, diagnóstico remoto, condiciones en el sitio, plan de repuestos, plan de capacitación, ruta de escalamiento y política de aviso de fin de vida útil.
Declaración de soporte del ciclo de vida Período de soporte del software, política de compatibilidad, licencias obligatorias, ruta de actualización, necesidades de calibración y período de disponibilidad de piezas.
Declaración de divulgación comercial Elementos incluidos, exclusiones, supuestos, dependencias, cargos recurrentes, responsabilidades del comprador, reglas de cambio y hitos vinculados a la aceptación.

No acepte declaraciones genéricas como “desplegado en todo el mundo”, “precisión de IA superior al 95%” o “casi cero falsas alarmas” como respuestas suficientes. Exija las clases objetivo, el conjunto de datos o la base de prueba de campo, el entorno, la configuración del sistema, el umbral de confianza, las limitaciones y el propietario del documento nombrado. Los requisitos de evidencia deben ser idénticos para todos los encuestados y deben convertirse en parte del contrato técnico cuando sea relevante.

3. Exigir un cronograma de cumplimiento requisito por requisito

Cada requisito debe tener un identificador único y campos para el estado de cumplimiento, valor ofrecido, condición o limitación, documento de evidencia, revisión del documento, organización responsable y método de aceptación propuesto. No combine varios requisitos técnicos en una sola línea de sí/no, porque una respuesta parcial se vuelve imposible de evaluar.

Campo Entrada de proveedor requerida
ID de requisito Referencia controlada por el comprador, sin cambios en todas las respuestas
Cumplimiento Cumplir / Desviación / Alternativa opcional / No ofrecido
Valor ofrecido Respuesta numérica o medible; evitar lenguaje de marketing
Condiciones Objetivo, entorno, configuración, suposiciones sobre la licencia o la infraestructura
Evidencia Ficha técnica, dibujo, documento de interfaz, informe de prueba o demostración controlada
Responsabilidad Proveedor, comprador, tercero o responsabilidad compartida
Método de aceptación Revisión de documentos, FAT, prueba de campo, SAT u observación operativa

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones

4. Separar la Capacidad del Producto de la Entrega del Proyecto

Una hoja de datos del producto puede respaldar una respuesta, pero no define el proyecto completo. La RFP debería solicitar por separado la radar sensor, servidor y software, licencias, EO/IR integration, interfaces externas, ingeniería del sitio, mástiles y obras civiles, cableado, puesta en marcha, capacitación, documentación, repuestos, garantía y soporte. Esto evita que un precio bajo del equipo se confunda con un sistema operativo completo.

5. Definir el Programa de Divulgación Comercial

La RFP debe requerir un cronograma de divulgación completo para que las cotizaciones posteriores puedan normalizarse sin adivinar lo que se incluye. El cronograma debe identificar equipos, infraestructura, ingeniería, integración, despliegue, servicios recurrentes, mantenimiento, supuestos, exclusiones y responsabilidades del comprador.

Grupo de Divulgación Información que todo proveedor debe declarar
Equipo Radar, RF, EO/IR, servidores, almacenamiento, dispositivos de red, estaciones de trabajo de operador, accesorios y repuestos; identificar cantidad y configuración.
Infraestructura Mástiles, cimientos, refugios, energía, UPS, puesta a tierra, protección contra rayos, fibra, enlaces inalámbricos y límites de obra civil.
Ingeniería Responsabilidades de levantamiento topográfico, diseño, modelado de cobertura, dibujos, revisión de ciberseguridad, gestión de proyectos y revisión de documentos.
Integración Controladores, trabajo API, interfaces VMS/PSIM/C2, conversión de coordenadas, entorno de prueba, pruebas, documentación y dependencias de terceros.
Despliegue Flete, seguro, aduanas, instalación, puesta en marcha, calibración, apoyo en la aceptación y responsabilidades en el país de destino.
Servicios recurrentes Licencias, conectividad, servicios en la nube o de monitoreo, retención de datos, soporte de software obligatorio y condiciones de renovación.
Mantenimiento y soporte Servicio preventivo, calibración, repuestos, logística de reparación, actualizaciones de software, soporte remoto y condiciones de servicio en sitio.
Supuestos y exclusiones Equipos suministrados por el comprador, condiciones del sitio, sensores adicionales, mástiles más altos, reubicación, modificaciones de terceros, retesting y reglas de control de cambios.

Esta guía no calcula ni clasifica el costo del ciclo de vida. Solo define la información que cada proveedor debe divulgar. El mantenimiento específico de la arquitectura, la redundancia, las piezas de repuesto, la región de soporte, la consecuencia de tiempo de inactividad y las obligaciones de software deben indicarse con supuestos y evidencia; el guía de comparación de citas separadas debería entonces evaluar esas divulgaciones en una base comparable.

6. Programa mínimo de respuesta RFI/RFP

Exija que cada respondedor complete el mismo cronograma. Una respuesta en blanco, “TBD” o “soportado” sigue siendo un requisito no resuelto hasta que se suministre una declaración medible, fuente de evidencia y parte responsable. El cronograma completado crea la línea base común que luego se utiliza para la comparación de cotizaciones.

Grupo de requisitos Respuesta Obligatoria del Proveedor
Alcance operativo Solo detección, DTI o límite integrado C-UAS; funciones incluidas y excluidas
Objetivos Objetivos de referencia, perfiles de vuelo, velocidades, altitudes y condiciones de rendimiento
Rendimiento del radar Detección, inicio de seguimiento, seguimiento estable, cobertura, actualización, precisión, capacidad y clasificación
Arquitectura del sensor Radar, RF, EO/IR, datos cooperativos y roles de fusión
Diseño de cobertura Cantidad de sensores, posiciones, alturas, zonas ciegas, superposición y suposiciones
Integración Interfaces, formatos, sistemas de coordenadas, sincronización de tiempo, camera cueing, health and logs
Ciberseguridad Control de acceso, cifrado, segmentación, aplicación de parches, auditoría y soporte remoto
Infraestructura Mástiles, obras civiles, energía, red, puesta a tierra, refugios y protección ambiental
Pruebas Métodos, objetivos, datos, umbrales y reglas de reexamen para la aceptación en fábrica, en campo y en sitio
Soporte Capacitación, garantía, SLA, diagnósticos, repuestos, soporte de software y política de fin de vida
Comercial Cronograma de precios desglosado, artículos incluidos, cargos recurrentes, supuestos, exclusiones, responsabilidades del comprador, cronograma de entrega, hitos de pago y reglas de control de cambios; sin puntuación ponderada en esta guía.
Cumplimiento Responsabilidades específicas del destino en radio, EMC, seguridad, aviación, importación/exportación y documentación

7. Desviaciones del control, supuestos y alternativas opcionales

Se requiere que cada desviación identifique el requisito afectado, la consecuencia operativa, la alternativa propuesta, el efecto en el precio y la implicación de aceptación. Las suposiciones deben consolidarse en un solo registro en lugar de estar dispersas a lo largo de la propuesta. Las alternativas opcionales deben valorarse por separado y no deben utilizarse para encubrir el incumplimiento de un requisito obligatorio.

8. Adjunte los documentos que regirán la entrega

  • Especificación técnica aprobada y documento base del sitio.
  • Dibujo de cobertura y declaración de riesgo residual.
  • Documento de control de interfaz y matriz de responsabilidades.
  • Evidencia y cronograma de presentación.
  • Factory, planes de prueba de campo y de aceptación en el sitio.
  • Inclusiones comerciales, exclusiones, cargos recurrentes y hitos de entrega.
  • Garantía, soporte, actualización de software y obligaciones de fin de vida.

Cómo Escribir un RFI/RFP para un Sistema de Radar de Detección de Drones

9. Definir el flujo de trabajo de evaluación y aclaración

Después de la recepción, revise cada respuesta en tres fases. Primero, identifique el incumplimiento obligatorio y la evidencia faltante. Segundo, emita un registro de aclaración controlado que preserve el ID del requisito original y registre la respuesta del proveedor, el impacto y el estado de cierre. Tercero, separe el alcance base conforme de las ventajas opcionales antes de la evaluación de precios. Esto evita que una oferta técnicamente incompleta aparezca competitiva porque es más barata o tiene mayor promoción.

Las aclaraciones que cambien el alcance ofrecido, la condición de desempeño, la responsabilidad o el precio deben incorporarse en la propuesta final y en el anexo del contrato. Las explicaciones por correo electrónico que no se transfieran a la oferta controlada no deben considerarse compromisos de entrega vinculantes.

Modos de fallo comunes de RFP

  • Usando un rango máximo de detección sin un objetivo y condición de operación.
  • Tratando la disponibilidad de API como integración completada.
  • Aceptar un porcentaje de precisión de IA sin conjunto de datos, umbral y limitaciones.
  • Dejar mástiles, obras civiles, servidores, licencias o puesta en marcha fuera del calendario de respuesta.
  • Definiendo la aceptación solo después de la adjudicación del contrato.
  • Permitir que los proveedores respondan en diferentes formatos que no se pueden normalizar.

10. Gobernar la Línea Base Controlada RFP

Asigne un propietario a cada requisito, interfaz y calendario de evidencia. Emita una línea base controlada a todos los encuestados, registre cada aclaración e identifique si cada respuesta cambia el cumplimiento, el precio, la entrega o la aceptación. Antes de la adjudicación, incorpore las aclaraciones y desviaciones aceptadas en el calendario técnico final, de modo que la oferta evaluada y el contrato describan el mismo sistema.

Conclusión

Un RFP de detección de drones defendible es un sistema de respuesta controlado. Da a cada proveedor los mismos ID de requisitos, expectativas de evidencia, campos de responsabilidad, divulgaciones comerciales y métodos de aceptación. Una vez recibidas las respuestas conformes, el comprador puede pasar a la etapa de comparación de cotizaciones por separado sin reconstruir lo que cada propuesta incluye realmente.

Preguntas frecuentes

¿Debería la RFP especificar un modelo de radar preferido?

Por lo general, no. Especifique primero el resultado operativo requerido, el objetivo establecido, las interfaces y los criterios de aceptación. Un modelo solo puede nombrarse cuando la compatibilidad, la estandarización o un diseño aprobado lo requieren.

¿Qué evidencia es más sólida que una afirmación de un folleto?

Un informe de prueba controlado, un documento de interfaz, un dibujo de cobertura, un extracto de datos en bruto o una demostración en vivo vinculado a la configuración propuesta y las condiciones de operación indicadas.

¿Cuándo se deben divulgar las exclusiones comerciales?

En la respuesta controlada inicial. Las exclusiones descubiertas durante la negociación o la instalación crean riesgo de orden de cambio y de calendario evitables.

¿Debería la respuesta del proveedor convertirse en parte del contrato?

Las respuestas técnicas de material, los dibujos, supuestos, desviaciones, entregables y compromisos de aceptación deben incorporarse al contrato o a sus anexos controlados.

Solicitar presupuesto

    Le responderemos dentro de 24 horas. Si es un caso urgente, por favor agregue WhatsApp/WeChat: 86 86 13361376820, o llame directamente al 86 86 13361376820.

    *Respetamos su confidencialidad y toda la información está protegida.

    Solo utilizaremos su información para responder a su consulta y nunca enviaremos correos no solicitados ni mensajes promocionales.