Inteligencia de BTW Media

Resumen

La Red de Iniciativa de Frontera Segura, o SBInet, fue el componente tecnológico de un programa fronterizo más amplio del Departamento de Seguridad Nacional anunciado en 2005. Aduanas y Protección Fronteriza (CBP) pretendía integrar torres, radares, cámaras, sensores terrestres no tripulados, comunicaciones y software de comando en una imagen operativa común para el personal de la Patrulla Fronteriza.
En septiembre de 2006, la CBP seleccionó a Boeing como integrador principal de sistemas. La adquisición dependía de una oficina de programa gubernamental que pudiera definir necesidades operativas, controlar requisitos, verificar el progreso del contratista y decidir cuándo un sistema integrado estaba listo para su uso y expansión en el campo.
El Proyecto 28, un prototipo de aproximadamente $20.6 millones que cubría 28 millas en el sector de Tucson, Arizona, expuso la diferencia entre el equipo entregado y la capacidad probada. El gobierno lo aceptó en febrero de 2008, ocho meses después, tras problemas de integración y acciones correctivas. Funcionarios y agentes reportaron beneficios limitados, así como soluciones operativas continuas.
La GAO y la Oficina del Inspector General del DHS encontraron repetidamente debilidades en los requisitos, las pruebas, las líneas base de costos y cronograma, la gestión de riesgos, la supervisión de contratistas y la dotación de personal gubernamental. No eran defectos administrativos separados. Juntos, debilitaron la evidencia necesaria para conectar la actividad de adquisición con el valor operativo.
Para 2010, el primer bloque propuesto de SBInet se había reducido en alcance geográfico y expectativas de rendimiento, mientras que su cronograma y valor del ciclo de vida seguían siendo inciertos. La GAO informó que el programa carecía de un cronograma maestro integrado confiable, una estimación confiable del costo del ciclo de vida y una relación demostrada entre los beneficios y costos esperados.
En enero de 2011, el DHS puso fin a SBInet tal como se concibió originalmente y se dirigió hacia un plan tecnológico adaptado al terreno y las necesidades operativas. La decisión no significó que toda la tecnología de vigilancia fronteriza fuera inútil, ni borró la capacidad limitada ya desplegada a lo largo de 53 millas en Arizona.
La lección de rendición de cuentas de SBInet es que un muro de sensores no es capacidad pública hasta que la detección, clasificación, comunicaciones, respuesta del operador, mantenimiento y costo puedan demostrarse juntos. El control práctico pertenece a las instituciones que pueden exigir esa prueba, detener la expansión cuando está ausente y preservar la evidencia detrás de ambas decisiones.

Una pantalla de vigilancia puede ocultar la parte más difícil

La imagen en el centro de una valla virtual es engañosamente simple. Un radar detecta movimiento. Una cámara se gira hacia un objetivo. El software coloca un icono en un mapa. Un operador ve el evento y envía un agente. En comparación con construir una barrera física a través de terreno difícil, la pantalla puede parecer una respuesta flexible y casi automática.

Pero la pantalla es la última capa visible de un sistema mucho más grande. Un radar debe distinguir el movimiento relevante de animales, clima y desorden. Una cámara debe proporcionar imágenes utilizables a la distancia y en las condiciones de iluminación prometidas. Las torres necesitan energía, comunicaciones y mantenimiento. El software debe combinar observaciones sin crear demora o confusión intolerable. El mapa debe reflejar las posiciones con precisión. Los agentes necesitan acceso a la información, confianza en ella y procedimientos para decidir qué respuesta es apropiada.

SBInet intentó convertir esas dependencias en una plataforma de vigilancia fronteriza. El programa no solo compraba cámaras o instalaba torres. Estaba adquiriendo una afirmación operativa integrada: que los sensores, las comunicaciones, el software y los flujos de trabajo de la Patrulla Fronteriza crearían una mejor conciencia situacional en grandes áreas.

Esa afirmación solo podría ser cierta a través de evidencia. La entrega de hardware era evidencia de entrega de hardware. Una compilación de software completa era evidencia de que existía código. Un hito del contratista mostraba que había ocurrido un evento contractual. Ninguno de esos hechos por sí solo probaba que el sistema podía detectar, identificar y clasificar un elemento de interés en terreno real, comunicar la observación, ayudar a un operador a tomar una decisión y permanecer disponible el tiempo suficiente para ser útil.

Esta distinción explica por qué SBInet pertenece a una serie de riesgo y rendición de cuentas. El fracaso central no fue que todos los dispositivos fallaran o que ningún agente recibiera beneficio alguno. Fue que la ambición del programa superó repetidamente la capacidad del gobierno para producir evidencia confiable y lista para la toma de decisiones sobre el rendimiento integrado, el costo, el cronograma y la preparación para escalar.

SBInet comenzó como una promesa de integración de sistemas

El DHS estableció la Iniciativa de Frontera Segura más amplia en noviembre de 2005. SBInet fue el esfuerzo tecnológico dentro de esa iniciativa, gestionado a través de Aduanas y Protección Fronteriza. Según la GAO, la solución prevista incluía sensores, comunicaciones, tecnología de la información, infraestructura táctica y capacidades de comando y control. También estaba destinada a desarrollar una imagen operativa común que pudiera proporcionar datos uniformes en los centros de comando y apoyar la interoperabilidad con organizaciones fuera del DHS.

Esa descripción importa porque define la unidad de rendición de cuentas. Si la necesidad pública fuera solo un radar, el gobierno podría juzgar si el radar cumplía con su especificación. La unidad de SBInet era el sistema: una combinación de personal, respuesta rápida, infraestructura y tecnología destinada a apoyar el control operativo.

En septiembre de 2006, la CBP otorgó a Boeing un contrato de integración principal de sistemas de entrega indefinida y cantidad indefinida. El contrato tenía un período base de tres años y tres opciones de un año. Las órdenes de tarea financiarían trabajos específicos, incluida la gestión del programa, el despliegue de prototipos, el software de imagen operativa común, el mantenimiento y la actividad de despliegue posterior.

El uso de un integrador principal puede ser razonable para un sistema complejo. Un contratista puede coordinar interfaces entre muchos proveedores y componentes. El acuerdo no transfiere la rendición de cuentas pública. El gobierno aún tiene que definir los resultados de la misión, retener el conocimiento técnico, controlar los requisitos, evaluar la información de costos y cronograma, supervisar el trabajo de los subcontratistas y decidir si el sistema entregado es aceptable.

Los registros de supervisión temprana muestran cuán exigente era ese papel. En febrero de 2007, la GAO dijo que el plan de gastos del año fiscal 2007 cumplía con cuatro condiciones legislativas, cumplía parcialmente con cuatro y no cumplía con una. El plan contenía información amplia de costos e hitos, pero carecía de suficiente detalle para respaldar la medición y la rendición de cuentas. No conectaba adecuadamente las actividades individuales con los objetivos estratégicos, y los procesos clave de gestión de adquisiciones no estaban completamente definidos ni implementados.

Por lo tanto, el problema era visible antes del despliegue nacional. SBInet estaba intentando una adquisición concurrente y de múltiples partes mientras la maquinaria de planificación, requisitos, riesgo y control de rendimiento del gobierno aún se estaba construyendo.

Un estimado de $7.6 mil millones aún no era un mapa creíble

El registro de gastos de 2007 ilustra la diferencia entre un número grande y una línea base confiable. El DHS estimó que completar la fase de adquisición para la frontera suroeste costaría $7.6 mil millones para los años fiscales 2007 a 2011. Discutió aproximadamente $790 millones para el sector de Tucson y $260 millones para el sector de Yuma.

La GAO no trató esas cifras como autovalidantes. El plan carecía de suficiente detalle sobre actividades, hitos y costos. No especificaba cómo se dividiría la asignación de Tucson entre cercas, sensores terrestres, radares, cámaras, torres fijas y torres móviles. No proporcionaba fechas de implementación específicas para esos elementos, y omitía las actividades y costos correspondientes de la frontera norte.

Una línea base debe permitir que alguien fuera del equipo del proyecto pregunte si la realidad se está moviendo según lo prometido. ¿Qué capacidad está financiada? ¿Cuándo vence? ¿Qué dependencia podría mover la fecha? ¿Cuál es el costo de la fuerza laboral gubernamental además del contratista? ¿Qué resultado demostrará que el gasto mejoró la misión?

Sin esos vínculos, un programa puede informar que el dinero se obligó y las tareas estaban activas, mientras deja al tomador de decisiones incapaz de juzgar si la capacidad útil se está acercando. El plan se convierte en un relato de actividad, no en un instrumento de control.

La GAO también cuestionó el máximo declarado del contrato. El DHS consideró que «6,000 millas de frontera estadounidense segura» era una cantidad máxima adecuada para el vehículo de cantidad indefinida. La GAO argumentó que esto era un resultado, no un límite calculable en suministros, servicios o dólares. El desacuerdo expuso un problema de rendición de cuentas más amplio: una aspiración no es un techo de adquisición mensurable.

El informe recomendó compromisos explícitos y mensurables para capacidades, cronogramas, costos y beneficios; un límite contractual expresado en unidades o dólares; y la reconsideración de la concurrencia. El DHS estuvo de acuerdo con la primera y tercera recomendaciones, pero discrepó sobre el máximo del contrato. Cualquiera que sea la interpretación legal, el punto operativo permaneció: el gobierno necesitaba una descripción acotada y comprobable de lo que estaba comprando.

El Proyecto 28 hizo visible el fracaso de la integración

El Proyecto 28 fue la primera prueba vívida del concepto de valla virtual. La orden de tarea cubría 28 millas en el sector de Tucson y estaba valorada en aproximadamente $20.6 millones. Su propósito era proporcionar capacidades de detección, identificación y clasificación utilizando radares, cámaras, sensores, computadoras, comunicaciones y software de imagen operativa común.

Los componentes se desplegaron, pero el sistema no se volvió operativo según el cronograma original. La GAO informó problemas de integración de software, incluidos retrasos en la visualización de información de radar en los centros de comando. Los requisitos no se habían definido adecuadamente y los usuarios no habían participado lo suficiente en su desarrollo. El hardware podía estar presente en el desierto mientras la cadena operativa permanecía incompleta.

En agosto de 2007, la CBP informó a Boeing que no aceptaría el proyecto hasta que se corrigieran los problemas especificados. Boeing presentó planes de acciones correctivas. El DHS aceptó condicionalmente el Proyecto 28 en diciembre de 2007 y requirió un análisis adicional de la calidad del video, los datos del radar y la sincronización de los componentes. La aceptación final se produjo el 22 de febrero de 2008, ocho meses después de la fecha prevista.

La aceptación final no significó que el sistema cumpliera con todas las expectativas operativas. La GAO registró que los funcionarios del programa consideraron cumplidos los requisitos contractuales, aunque también dijeron que el Proyecto 28 no había cumplido plenamente con sus expectativas. La Patrulla Fronteriza informó limitaciones continuas, incluida la resolución de la imagen de la cámara a distancias más largas. Se esperaba que las pruebas operativas futuras informaran el desarrollo posterior en lugar de rehacer sustancialmente el prototipo aceptado.

Esos hechos no deben colapsarse en la afirmación de que el Proyecto 28 no entregó nada. Operó a lo largo del área de 28 millas. Los agentes dijeron más tarde a la GAO que mejoró algunas capacidades operativas. La evidencia también mostró soluciones alternativas relacionadas con la intensidad de la señal inalámbrica, el control remoto de la cámara y la sensibilidad del radar.

La pregunta de rendición de cuentas es más aguda que el éxito o el fracaso como eslogan. ¿Qué certificó la aceptación? Si la aceptación contractual significaba que se había proporcionado un conjunto definido de entregables, los tomadores de decisiones aún necesitaban evidencia separada sobre la idoneidad operativa, las necesidades del usuario, la mantenibilidad y la preparación para la replicación. Un evento de aceptación firmado podría cerrar una obligación mientras deja sin resolver la decisión de escalar.

La aceptación y el valor operativo son puertas diferentes

Las adquisiciones públicas a menudo usan la palabra aceptación como si fuera un veredicto universal. En la práctica, varias puertas pueden llevar esa etiqueta. Un gobierno puede aceptar la entrega porque un contratista cumplió con criterios negociados. Una organización de pruebas puede encontrar que un sistema completó un evento planificado. Una unidad operativa puede decidir que el sistema es útil bajo condiciones especificadas. Un departamento puede determinar que la capacidad es lo suficientemente rentable como para expandirla.

SBInet necesitaba que esos juicios permanecieran distintos. El Proyecto 28 mostró por qué. Su aceptación final reflejó una relación contractual después de una acción correctiva. No estableció que el prototipo fuera el diseño correcto para toda la frontera suroeste, que cada preocupación de campo se hubiera resuelto o que la misma arquitectura fuera económica en diferentes terrenos.

El programa también planeó generaciones posteriores de tecnología que reemplazarían gran parte del equipo del Proyecto 28. Eso hizo que el prototipo fuera una fuente de lecciones y capacidad limitada. Pero las lecciones aprendidas son valiosas solo cuando se capturan en requisitos, planes de prueba, controles de interfaz, estimaciones de costos y decisiones de despliegue.

Una adquisición débil trata un prototipo como una demostración de que el impulso debe continuar. Una adquisición controlada pregunta qué suposiciones refutó el prototipo. ¿Eran lo suficientemente maduros los componentes comerciales? ¿Podía el software procesar datos de sensores a velocidad operativa? ¿La cobertura de comunicaciones coincidía con el concepto? ¿Eran utilizables las interfaces del operador? ¿Cuántos defectos aparecieron bajo cargas de trabajo realistas? ¿Qué carga de mantenimiento reveló la experiencia de campo?

El gobierno también debe protegerse contra criterios cambiantes. Si las pruebas de aceptación se revisan principalmente para ajustarse al rendimiento actual del sistema, la prueba deja de representar la necesidad original de la misión. Por el contrario, negarse a cualquier cambio sería igualmente insostenible si los requisitos originales fueran inasequibles, no verificables o no relacionados con las operaciones de campo.

El control es la trazabilidad. Cada criterio cambiado debe mostrar la justificación de la misión, la evidencia técnica, el efecto en el costo y el cronograma, la autoridad de aprobación y el efecto en los resultados del usuario. Sin ese registro, los líderes del programa no pueden distinguir la adaptación disciplinada de la redefinición gradual del éxito.

Los requisitos eran la arquitectura de la rendición de cuentas

Los requisitos pueden parecer papeleo técnico, pero en SBInet asignaban responsabilidad. Los requisitos operativos describían lo que la Patrulla Fronteriza necesitaba lograr. Los requisitos del sistema traducían esas necesidades en características de rendimiento y funcionales. Los requisitos de los componentes abordaban cámaras, radares, comunicaciones y otros elementos. Los requisitos de software y diseño gobernaban cómo interactuarían esos elementos.

La GAO encontró que el programa había definido un proceso de desarrollo y gestión de requisitos, pero no lo implementó de manera consistente. Una revisión independiente del DHS encontró que algunos requisitos operativos eran inasequibles y no verificables. Debido a que los requisitos de nivel inferior se derivaban de esas declaraciones operativas, la incertidumbre en la parte superior podía propagarse a través del diseño del sistema, los casos de prueba y el trabajo del contratista.

La GAO recomendó establecer una línea base de requisitos antes del diseño y desarrollo, analizarlos para determinar su integridad, viabilidad y verificabilidad, y rastrearlos hacia arriba hasta las necesidades de la misión y hacia abajo hasta los componentes y las pruebas. Estos no son pasos ceremoniales. Crean una cadena de custodia para la afirmación de capacidad.

Considere un requisito de cámara. Una especificación de alcance óptico es incompleta sin suposiciones sobre el terreno, la atmósfera, el tamaño del objetivo, la iluminación, la estabilización y cómo un operador usará la imagen. Una probabilidad de detección es incompleta sin definir el conjunto de objetivos relevantes, las condiciones de prueba y la carga de falsas alarmas. Un requisito de comunicación es incompleto si ignora dónde viajan los vehículos y cuánto tiempo lleva el inicio de sesión o la reconexión.

Los usuarios de campo son esenciales porque saben dónde el rendimiento abstracto se encuentra con la fricción operativa. No se les debe preguntar simplemente si una pantalla terminada parece útil. Necesitan influencia estructurada antes de que las decisiones de diseño se endurezcan: escenarios, misiones prioritarias, demoras aceptables, carga de trabajo, condiciones ambientales y qué información respalda una decisión de respuesta.

Por lo tanto, los requisitos forman una arquitectura de rendición de cuentas pública. Establecen lo que la agencia considera necesario, lo que el contratista debe entregar, lo que los evaluadores deben probar y lo que los líderes están autorizando cuando aprueban un cambio. Cuando esa arquitectura es inestable, cada medida posterior (cronograma, costo, cierre de defectos y aceptación) se vuelve más difícil de interpretar.

Las pruebas debían demostrar toda la cadena

El enfoque de pruebas de SBInet contemplaba varias capas. La calificación de componentes podía mostrar si el equipo individual cumplía con las características especificadas. Las pruebas de integración podían demostrar interfaces e interoperabilidad. La calificación del sistema podía probar el diseño ensamblado. Las pruebas de aceptación del sistema podían respaldar la decisión contractual del gobierno. Las pruebas y evaluación operativas podían examinar la eficacia y la idoneidad en el entorno donde la Patrulla Fronteriza usaría el sistema.

La GAO encontró que las pruebas no se gestionaban de manera efectiva. El programa había comenzado a integrar componentes antes de probar individualmente los componentes reales destinados a las ubicaciones de despliegue inicial. Se había redactado una estrategia de gestión de pruebas, pero no se había finalizado ni aprobado. Carecía de una definición clara de roles, un cronograma maestro de alto nivel y suficiente detalle sobre hitos y métricas para guiar las pruebas del proyecto.

El orden importa. Si un componente inestable ingresa a la integración, los ingenieros pueden pasar tiempo diagnosticando el comportamiento del sistema que se origina en una parte no calificada. Si las interfaces no están controladas, una prueba de componente exitosa dice poco sobre el sistema combinado. Si los usuarios operativos llegan solo después de que se fijan los criterios de aceptación, el programa puede probar el rendimiento equivocado.

La GAO informó más tarde aproximadamente 1,300 defectos encontrados entre marzo de 2008 y julio de 2009. Los nuevos defectos generalmente aparecían más rápido de lo que se resolvían, y muchos carecían de una prioridad de resolución. El recuento por sí solo no prueba que todos los defectos fueran graves. La tendencia y el triaje incompleto socavaron la confianza en que el sistema estaba madurando hacia el despliegue.

El registro oficial también describió preocupaciones de que algunos cambios en los casos y procedimientos de prueba parecían orientados a pasar la prueba en lugar de calificar el sistema. Ese es un límite de gobernanza crítico. Un programa debe actualizar una prueba cuando la evidencia muestra que la prueba es inválida, redundante o desconectada de las necesidades de la misión. No debe reducir la carga probatoria simplemente porque el diseño actual no puede pasar.

Las pruebas son donde las promesas públicas se vuelven falsables. El control más fuerte habría conectado cada requisito operativo con un caso de prueba, condición de prueba, resultado medido, registro de defectos, disposición y autoridad de aprobación. Ese libro mayor habría hecho posible ver no solo si un evento pasó, sino qué demostró realmente el pase.

El campo reportó beneficios y soluciones alternativas al mismo tiempo

La historia de SBInet se distorsiona si se borra el uso limitado. En 2008 y 2009, los agentes de la Patrulla Fronteriza en el sector de Tucson dijeron a la GAO que el Proyecto 28 había mejorado aspectos de su capacidad operativa. El sistema estaba en uso mientras el programa esperaba los despliegues posteriores de SBInet.

Los agentes también describieron soluciones alternativas persistentes. Tuvieron problemas para encontrar una intensidad de señal inalámbrica confiable, controlar las cámaras de forma remota y ajustar la sensibilidad del radar. La GAO observó un uso limitado de los terminales de datos móviles instalados en los vehículos. Dependiendo de la intensidad de la señal, el inicio de sesión podía llevar mucho tiempo y las conexiones podían perderse repetidamente durante un turno. Los operadores en la imagen operativa común a veces retransmitían información.

Esa evidencia mixta es más útil que un veredicto binario. Un sistema puede proporcionar valor local mientras sigue siendo inadecuado como plantilla para una expansión nacional. Puede ayudar a un flujo de trabajo y sobrecargar otro. Puede funcionar bajo algunas condiciones ambientales y degradarse bajo otras.

La retroalimentación operativa debe estructurarse en torno a esa variación. ¿Qué funciones se utilizaron? ¿Con qué frecuencia? ¿Bajo qué condiciones? ¿Qué hicieron los agentes cuando la tecnología no estaba disponible? ¿El sistema redujo o aumentó la carga de trabajo del operador? ¿Se confiaba en las alertas? ¿Con qué rapidez podían los mantenedores restaurar el equipo averiado? ¿Una solución alternativa preservó la misión, y a qué costo de personal?

La tentación en un programa problemático es usar cualquier declaración de campo positiva como prueba de que la expansión está justificada, o cualquier queja como prueba de que el sistema es inútil. Ninguna inferencia es responsable. La evidencia de campo debe vincularse a beneficios de misión definidos y compararse con el costo, las alternativas y el rendimiento del equipo existente.

La experiencia de SBInet sugiere un estándar escalonado. El despliegue limitado puede ser valioso como descubrimiento. La expansión debe requerir evidencia más sólida: rendimiento repetible en terreno representativo, tendencias de defectos controladas, comunicaciones utilizables, mantenibilidad, operadores capacitados y un beneficio cuantificado en relación con los sistemas que reemplazaría o complementaría.

La concurrencia convirtió las incógnitas en compromisos de cronograma

Los primeros planes de SBInet utilizaban órdenes de tarea concurrentes y actividades relacionadas. La concurrencia puede acelerar la entrega cuando las interfaces son estables y los riesgos se comprenden. También puede multiplicar el retrabajo cuando los requisitos, diseños y pruebas aún están cambiando.

La GAO advirtió en 2007 que el programa no había proporcionado evidencia que mostrara que había identificado dependencias entre actividades concurrentes y estaba gestionando proactivamente el riesgo asociado. Al mismo tiempo, la oficina del programa dijo que la implementación acelerada había tenido prioridad sobre la definición e implementación completa de algunos procesos de gestión de adquisiciones.

Esa compensación es común en programas públicos urgentes. Los líderes temen que el proceso retrase la capacidad. Sin embargo, un requisito, revisión de interfaz o plan de prueba no es valioso porque retrasa el trabajo. Es valioso si evita que la organización escale una suposición no probada.

El Proyecto 28 hizo concreta la cadena de dependencias. La integración de software retrasó el prototipo. Se suponía que las lecciones del prototipo informarían los bloques posteriores. Pero el trabajo en requisitos, diseños, torres y sistemas de comando posteriores no podía simplemente pausarse sin consecuencias en el cronograma. Cuanto más trabajo procedía antes de que la lección fuera estable, más costosa podía ser la corrección.

Un registro de concurrencia habría hecho visible el riesgo. Para cada actividad autorizada antes de que la evidencia predecesora estuviera completa, el programa podía registrar la evidencia faltante, la razón para proceder, la exposición máxima, un plan de reversión y la fecha de decisión. Los líderes sabrían entonces si la aceleración era un riesgo acotado o una acumulación de compromisos irreversibles.

El problema no era la urgencia en sí misma. La seguridad fronteriza era una prioridad declarada, y el equipo heredado tenía limitaciones. El problema era si la urgencia cambiaba el estándar de evidencia o simplemente la velocidad a la que se debía producir la evidencia. Si el estándar cae, el programa puede parecer más rápido hasta que la integración y el retrabajo consumen el tiempo ahorrado.

La escala se redujo mientras la afirmación del programa seguía siendo grande

SBInet se describió como una solución fronteriza integral, pero su despliegue planificado cambió repetidamente. Para 2009, la GAO documentó años de retraso y una reducción de la huella a corto plazo. El Proyecto 28 cubría 28 millas. Los despliegues planificados del Bloque 1 en Tucson-1 y Ajo-1 juntos cubrían aproximadamente 53 millas.

Los planes anteriores habían contemplado el despliegue inicial en los sectores de Tucson, Yuma y El Paso, aproximadamente 655 millas. Una línea base posterior redujo ese alcance inicial a Tucson y Yuma, aproximadamente 387 millas. Los planes para incrementos posteriores siguieron sin resolverse.

La reducción del alcance puede ser prudente. Un programa no debe mantener una huella poco realista simplemente para preservar una promesa anterior. Pero la rendición de cuentas requiere que el costo, el cronograma y la afirmación de beneficio cambien con el alcance.

Para 2010, la GAO describió el primer bloque con un costo de aproximadamente $1.3 mil millones. Encontró que las capacidades planificadas habían seguido reduciéndose. Los umbrales de rendimiento se relajaron. Los umbrales de detección e identificación que una vez se fijaron en 95% se redujeron al 70%, mientras que el umbral de disponibilidad operativa pasó del 95% al 85%.

La GAO señaló que la definición resultante podría permitir un rendimiento agregado aceptable incluso si categorías de identificación particulares tuvieran un rendimiento inferior al 50%. La importancia operativa exacta dependía de cómo se construyeran y aplicaran las medidas, pero el punto de gobernanza es claro: un umbral de rendimiento es una declaración sobre lo que la agencia está preparada para llamar aceptable.

Cambiar un umbral puede estar justificado por la realidad técnica, el costo o una mejor comprensión de la misión. El registro de decisión debe explicar qué necesidad del usuario sigue satisfecha, qué riesgo se acepta y si la estimación de beneficio sigue siendo válida. De lo contrario, el programa puede preservar la etiqueta «Bloque 1» mientras entrega una promesa materialmente diferente.

Los controles de costos y cronograma no produjeron una previsión confiable

Para 2010, tanto la GAO como la OIG del DHS cuestionaban los controles detrás de las afirmaciones de costos y cronograma de SBInet. La GAO evaluó el cronograma maestro integrado de agosto de 2009 según nueve prácticas reconocidas y encontró un cumplimiento sustancial solo con dos. El cronograma no capturaba adecuadamente todas las actividades, asignaba recursos, identificaba una ruta crítica, contabilizaba un margen razonable ni analizaba el riesgo del cronograma.

Un cronograma no es confiable porque contiene muchas fechas. Es confiable cuando las dependencias están conectadas lógicamente y los tomadores de decisiones pueden ver qué trabajo controla la fecha de finalización. Si un deslizamiento en la calificación del radar afecta la integración, la preparación de la prueba, el despliegue y la capacitación del operador, esa relación debe ser visible. Sin ella, una fecha de finalización reportada es una agregación de deseos.

La GAO también encontró que la estimación del costo del ciclo de vida del Bloque 1 no cumplía suficientemente con las características de una estimación confiable: integral, bien documentada, precisa y creíble. Exclusiones y suposiciones limitaron su utilidad. La estimación omitía o no trataba adecuadamente el esfuerzo gubernamental, algunas operaciones y mantenimiento, costos de sistemas heredados, software, apoyo al programa y evolución de bloques futuros. Los riesgos asociados con la madurez de los componentes comerciales no se reflejaron completamente.

La OIG del DHS encontró problemas de control relacionados. La información de línea base actual no siempre se ingresaba en el sistema de gestión del valor ganado, lo que reducía su capacidad para advertir sobre variaciones de costos y cronograma. La oficina del programa operó sin un cronograma maestro integrado aprobado durante parte de la revisión, y el personal de supervisión de costos y cronograma era escaso.

Estos hallazgos no eran predicciones de que cada dólar se desperdiciaría. Mostraban que los líderes carecían de una previsión confiable. Se supone que los controles de costos y cronograma revelan la divergencia lo suficientemente temprano como para cambiar el rumbo. Cuando las líneas base son tardías, incompletas o inestables, la gerencia se entera del problema después de que los compromisos ya han reducido las opciones.

La supervisión del contratista requería autoridad técnica del gobierno

SBInet dependía en gran medida de los contratistas, desde el integrador principal de sistemas hasta el personal de apoyo dentro de la organización del programa. Los contratistas aportaron habilidades de ingeniería, integración y gestión. También crearon un problema de control si el personal gubernamental carecía de la capacidad para desafiar suposiciones, evaluar entregables o distinguir el apoyo del contratista de las decisiones inherentemente gubernamentales.

La alerta de riesgo de la OIG del DHS de 2006 dijo que el departamento carecía de capacidad suficiente para planificar, supervisar y ejecutar SBInet, administrar contratos y controlar costos y cronograma. En esa etapa, una gran parte de los puestos planificados eran contratistas. El informe advirtió que los requisitos operativos se habían pospuesto hasta después de la selección del integrador y recomendó planes para desarrollar la capacidad de gestión y estabilizar los requisitos.

Un informe de la OIG de 2009 encontró que los contratistas de apoyo habían realizado o se habían acercado a actividades que deberían permanecer bajo un control gubernamental más fuerte. Recomendó distinguir los roles de contratistas y federales y asignar más representantes técnicos del oficial de contratos para supervisar el rendimiento.

La preocupación no es que los contratistas sean inherentemente poco confiables. Un contratista principal es responsable ante los incentivos contractuales, el alcance y los criterios de aceptación. Solo la agencia pública puede conciliar esos incentivos con el valor de la misión, las opciones de política y la administración de los fondos asignados.

La autoridad técnica del gobierno debe ser práctica, no ceremonial. El personal necesita acceso a datos fuente, líneas base de requisitos, inventarios de defectos, procedimientos de prueba, lógica del cronograma y suposiciones de costos. Necesita tiempo para revisar los entregables tardíos antes de un hito. Necesita el poder para rechazar la evidencia que no cumple con el estándar.

SBInet también ilustra por qué el número de personal es insuficiente. El programa necesitaba ingenieros de sistemas, gerentes de pruebas, analistas de costos, analistas de cronogramas, especialistas en contratación y representantes operativos con derechos de decisión claramente asignados. Si la institución no puede decir quién posee una interfaz, un cambio de umbral o una exención de aceptación, el integrador puede convertirse en el autor de facto de la evidencia pública.

La gobernanza de hitos necesitaba evidencia de entrada y salida

El informe de costos y cronograma de la OIG del DHS de 2010 se centró en un problema aparentemente procesal con grandes consecuencias: si los eventos del programa tenían criterios de entrada y salida documentados y si el gobierno mostraba por qué aceptaba la evidencia.

Se supone que las revisiones importantes reducen la incertidumbre. Una revisión de requisitos debe mostrar que las necesidades se comprenden y son trazables. Una revisión de diseño debe mostrar que la solución es lo suficientemente madura para la construcción o codificación. Una revisión de preparación para la prueba debe mostrar que los procedimientos, configuraciones y entornos pueden producir resultados válidos. Una revisión de preparación operativa debe mostrar que las partes interesadas están de acuerdo en que el sistema puede entrar en servicio bajo condiciones definidas.

Si el evento ocurre porque el calendario dice que debería, la revisión se convierte en teatro. Si los criterios son incompletos, los problemas no resueltos deben registrarse con propietarios, plazos y decisiones de riesgo. Si los líderes proceden condicionalmente, la condición debe limitar qué trabajo puede comenzar.

La OIG recomendó que el programa documentara la revisión y aceptación gubernamental de los logros y criterios del evento, asegurara que las condiciones de entrada y salida se cumplieran, abordara los problemas abiertos y actualizara las evaluaciones de riesgo antes de los eventos posteriores. La CBP estuvo de acuerdo mientras disputaba partes de la caracterización de la OIG de decisiones de despliegue particulares.

Ese desacuerdo en sí mismo demuestra el valor de un registro de evidencia duradero. Los auditores y gerentes pueden interpretar el riesgo de manera diferente. Un paquete de decisión completo debe permitir que un lector posterior vea los criterios, la evidencia, los elementos no resueltos, la justificación para proceder y los límites colocados en la siguiente fase.

Para un programa de tecnología pública, la gobernanza de hitos protege más que el cronograma. Preserva la base para la rendición de cuentas después de cambios de liderazgo, rotación de contratos y presión política. Dice a los equipos futuros si un sistema avanzó porque estaba listo, porque el riesgo se acotó conscientemente o porque el impulso superó los controles.

La evaluación de 2010 cambió la pregunta de decisión

En enero de 2010, el Secretario de Seguridad Nacional inició una evaluación departamental de SBInet. La pregunta ya no era simplemente cómo recuperar el cronograma actual. El DHS examinó si el enfoque era la estrategia de tecnología de seguridad fronteriza más eficiente, efectiva y económica.

El informe de la GAO de mayo de 2010 agudizó esa pregunta. Encontró un alcance reducido, un cronograma no confiable, una estimación del costo del ciclo de vida no confiable, beneficios esperados no identificados e implementación inconsistente de los procesos de gestión del ciclo de vida. La GAO recomendó limitar la inversión adicional más allá de las dos ubicaciones de despliegue actuales hasta que el DHS tuviera una base analítica defendible.

Este es un giro importante en la rendición de cuentas. Los programas a menudo responden a las dificultades produciendo una nueva fecha, un nuevo nombre de bloque o un umbral de rendimiento revisado. Esas acciones suponen que el concepto subyacente sigue siendo justificado. La evaluación de 2010 reabrió el concepto mismo.

Una decisión de alternativas necesita una comparación común. ¿Qué problema de misión debe resolverse en cada región? ¿Qué sistemas existentes contribuyen? ¿Qué condiciones de terreno y población importan? ¿Qué tecnologías comerciales son maduras? ¿Cuáles son los costos del ciclo de vida, incluido el personal gubernamental y el mantenimiento? ¿Con qué rapidez puede cada opción producir un beneficio mensurable?

El análisis también necesitaba evitar una falsa elección entre SBInet y ninguna tecnología. El DHS podía terminar con la arquitectura única mientras continuaba usando cámaras, sistemas móviles, imágenes térmicas, aeronaves no tripuladas y otras herramientas de vigilancia. La decisión era sobre el modelo de adquisición y el diseño integrado, no sobre la existencia de una misión fronteriza.

Al replantear la pregunta, la evaluación reconoció que la disciplina de recuperación a veces significa detenerse. La cancelación no es automáticamente una prueba de buena gobernanza; puede llegar tarde y dejar costos hundidos. Pero continuar un programa sin un caso de costo-beneficio creíble no recuperaría esos costos hundidos. Aumentaría la exposición.

La cancelación fue un reinicio de gobernanza, no una eliminación

En enero de 2011, el DHS puso fin a SBInet tal como se concibió originalmente. El departamento dijo que la evaluación mostraba que el programa no podía cumplir su objetivo original como una solución tecnológica fronteriza única. Se desplazó hacia un plan que utilizaba tecnologías probadas adaptadas al terreno, la densidad de población y la necesidad operativa.

La supervisión posterior resumió el registro de manera más directa: retrasos significativos y sobrecostos, tecnología entregada a dos áreas de Arizona y cancelación porque el programa no cumplió con los estándares de viabilidad y rentabilidad. La GAO consideró que la decisión de discontinuar el enfoque original respondía a sus recomendaciones acumuladas.

La decisión no estableció que todos los componentes de SBInet fueran inútiles. Se habían desplegado sistemas de vigilancia a lo largo de 53 millas, y el Proyecto 28 había proporcionado capacidad operativa limitada antes de ser reemplazado. Tampoco la cancelación probó que las tecnologías sucesoras fueran automáticamente efectivas.

La distinción importa para el aprendizaje institucional. Si la cancelación se narra como un fracaso tecnológico total, la evidencia de campo útil puede desecharse. Si se narra como un cambio de marca rutinario, los fallos de control pueden desaparecer. Un cierre responsable identifica qué requisitos eran válidos, qué suposiciones de arquitectura fallaron, qué componentes siguen siendo compatibles, qué contratos deben cerrarse y qué evidencia debe guiar al sucesor.

El Plan de Tecnología de Vigilancia Fronteriza de Arizona sucesor utilizó un menú de tecnologías en lugar del modelo integrado original. Informes posteriores de la GAO y la OIG del DHS aún encontraron debilidades en la planificación y medición. Esa continuación no hace que SBInet sea la causa de todos los problemas posteriores. Muestra que cambiar el portafolio de equipos no repara automáticamente la disciplina de adquisición.

El reinicio de gobernanza estaría completo solo cuando el nuevo plan pudiera documentar alternativas, beneficios de misión esperados, cronogramas, costos del ciclo de vida, medidas de rendimiento y evaluaciones operativas. Un conjunto diferente de torres no es un sistema de rendición de cuentas diferente a menos que la evidencia de decisión también cambie.

El riesgo público era más amplio que un dispositivo roto

Los riesgos públicos directos de SBInet eran riesgos de administración y capacidad. Los fondos asignados podían comprometerse sin evidencia confiable de valor. El despliegue podía retrasarse mientras los sistemas heredados seguían llevando la misión. La agencia podía escalar una arquitectura que no había demostrado un rendimiento integrado. Los cambios repetidos podían debilitar la confianza en la gestión tecnológica del DHS.

Esos riesgos no deben convertirse en afirmaciones no respaldadas sobre migración, delincuencia o incidentes fronterizos específicos. Las fuentes oficiales discutieron el objetivo de detectar y responder a entradas ilegales, pero este relato no atribuye un cruce, aprehensión o resultado de seguridad particular a un defecto de SBInet.

La distinción es una fortaleza, no una limitación. La rendición de cuentas pública no requiere inventar un evento dramático posterior. Una adquisición puede imponer un riesgo grave al consumir tiempo, presupuesto y atención organizacional mientras no logra probar que la capacidad prometida llegará.

También puede crear costos operativos ocultos. Agentes trabajando alrededor de comunicaciones no confiables, operadores compensando el comportamiento de los sensores, mantenedores manteniendo vivo el equipo mixto heredado y nuevo, y gerentes reconstruyendo cronogramas inciertos: todo ello gasta capacidad escasa. Esos efectos deben medirse en lugar de asumirse, pero pertenecen a un análisis completo del ciclo de vida.

La legitimidad institucional se ve afectada cuando las afirmaciones públicas se mantienen amplias mientras el alcance entregado se reduce. Los funcionarios pueden tener razones válidas de seguridad para no divulgar detalles de rendimiento sensibles. Aún pueden proporcionar a los organismos de supervisión evidencia controlada sobre costos, cronograma, rigor de las pruebas y criterios de decisión.

El estándar público no es que cada programa de tecnología deba tener éxito. La integración compleja revelará defectos. El estándar es que la incertidumbre se hace visible, los usuarios operativos influyen en la evidencia, los contratistas son supervisados y los líderes detienen o reconfiguran el programa cuando el caso de valor ya no es creíble.

La rendición de cuentas sigue al control práctico

La responsabilidad por SBInet estaba distribuida, pero el control práctico aún puede identificarse. El liderazgo del DHS controlaba el marco de inversión y la decisión de evaluar o finalizar el programa. La CBP era dueña de la misión y la organización de adquisición. La oficina del programa SBInet controlaba los requisitos, la supervisión de las órdenes de tarea, las líneas base y las recomendaciones de hitos. Boeing controlaba gran parte del trabajo de integración y la evidencia del contratista. Los usuarios de la Patrulla Fronteriza controlaban la retroalimentación operativa esencial.

Las organizaciones de pruebas y auditoría desafiaban la calidad de la prueba.

La rendición de cuentas debe seguir las decisiones que cada participante podía tomar. Un contratista es responsable del trabajo y las representaciones dentro del contrato. No es la autoridad final sobre si un umbral sirve a la misión pública. Los operadores son responsables de la evaluación disciplinada, pero no pueden arreglar una estimación de costos estructuralmente no confiable. Los auditores pueden identificar debilidades, pero los ejecutivos del programa son dueños de la respuesta.

El control más consecuente era la autoridad para escalar. La expansión compromete dinero y hace que las suposiciones de diseño sean más difíciles de revertir. La institución que la autoriza debería haber exigido un paquete de evidencia integrado: escenarios de misión estables, requisitos trazados, componentes calificados, defectos controlados, resultados de campo representativos, estimaciones confiables de costos y cronograma, planificación de mantenimiento y una comparación de beneficios.

Ningún artefacto favorable individual debe sustituir el paquete. Una prueba de aceptación aprobada puede no probar la mantenibilidad. Una estimación de costos puede estar bien documentada pero basarse en un rendimiento no probado. La retroalimentación positiva del usuario puede ser local y condicional. El valor reside en la consistencia de la evidencia.

Este marco también evita que la culpa se colapse en una cámara defectuosa, un equipo de software o un ejecutivo. El registro de SBInet muestra debilidades de control interactuantes durante varios años. La rendición de cuentas práctica pregunta quién podía ver cada debilidad, quién podía exigir una corrección y quién autorizó el siguiente compromiso.

Una mejor puerta de evidencia antes de escalar

Las adquisiciones públicas de vigilancia futuras pueden extraer un modelo de control concreto de SBInet.

Primero, definir escenarios operativos antes de seleccionar una arquitectura. El terreno, las comunicaciones, los tipos de objetivo, la carga de trabajo del operador, el acceso de mantenimiento y los procedimientos de respuesta deben dar forma al requisito.

Segundo, mantener la trazabilidad bidireccional. Cada requisito de componente y software debe conectarse hacia arriba a una necesidad del usuario y hacia abajo a un caso de prueba. Los cambios deben preservar la justificación y la autoridad de aprobación.

Tercero, separar la aceptación técnica, contractual y operativa. Cada puerta debe indicar qué prueba, qué permanece sin probar y qué acciones siguientes están autorizadas.

Cuarto, medir la madurez de los defectos. Los defectos deben tener gravedad, efecto operativo, propietario, versión objetivo y evidencia de cierre. La tendencia debe informar la preparación, no solo el recuento de tickets cerrados.

Quinto, hacer que las estimaciones de costos y cronograma sean lo suficientemente completas para las decisiones. El trabajo gubernamental, el esfuerzo del contratista, la infraestructura, el software, la capacitación, el mantenimiento, la superposición de sistemas heredados y el riesgo deben ser visibles. El cronograma debe identificar dependencias, ruta crítica e incertidumbre.

Sexto, preservar la autoridad técnica del gobierno. Los contratistas pueden integrar el sistema, pero el personal federal debe ser dueño de los requisitos, la aceptación, el riesgo y el registro de decisiones.

Séptimo, usar el despliegue incremental como un experimento con objetivos de aprendizaje explícitos. Un incremento debe responder preguntas definidas antes de que comience la siguiente expansión.

Finalmente, requerir una decisión de escala que pueda fallar. Si la evidencia no respalda la expansión, el valor predeterminado debe ser pausar, rediseñar o detener, no reinterpretar la promesa original.

Estos controles no garantizan el éxito. Hacen que el fracaso sea informativo y limitan el costo de descubrir que una arquitectura es incorrecta. También dan a los líderes una base defendible para continuar cuando la evidencia es sólida.

Conclusión: Una valla virtual debe demostrarse en el campo

SBInet se construyó en torno a una idea atractiva: integrar sensores y software para que una vasta frontera sea más visible y los agentes puedan responder con mejor información. La idea no fue refutada simplemente porque la adquisición original terminó. El registro del programa muestra lo difícil que es convertir esa idea en infraestructura pública confiable.

El Proyecto 28 entregó equipo y cierta capacidad limitada, pero también expuso problemas de integración, requisitos y operativos. Los bloques posteriores llevaban una promesa más grande mientras el alcance y las expectativas de rendimiento cambiaban. Los controles de costos y cronograma no dieron a los líderes una previsión confiable. La supervisión de contratistas e hitos no preservó consistentemente la evidencia necesaria para una expansión confiada.

El DHS eventualmente cambió la pregunta de cómo continuar SBInet a si la arquitectura era la inversión correcta. Terminar el programa tal como se concibió originalmente fue una admisión de que la evidencia existente no justificaba el modelo de escalamiento original.

La lección no es que los gobiernos deban evitar la tecnología compleja. La vigilancia fronteriza, los sistemas meteorológicos, el despacho de emergencias y los servicios digitales públicos dependen de la integración. La lección es que la complejidad aumenta la carga de la prueba.

Una torre no es cobertura. Una detección de radar no es identificación. Un icono de mapa no es una respuesta operativa. Un hito contractual no es valor de misión. Un piloto no es una arquitectura nacional.

La capacidad pública comienza cuando esos vínculos pueden demostrarse bajo condiciones representativas, con costo conocido, defectos controlados, usuarios capacitados, mantenimiento sostenible y un cronograma que refleje las dependencias reales. Hasta entonces, la valla virtual es una afirmación de adquisición.

SBInet convirtió la decisión de escala en el artefacto central de rendición de cuentas. Las instituciones con control práctico tenían que decidir si la evidencia de campo era lo suficientemente sólida como para justificar la siguiente milla. Cuando esa evidencia faltaba, detener la expansión no fue un abandono de la rendición de cuentas. Fue su ejercicio.

SBInet convirtió los sensores fronterizos virtuales en una prueba de rendición de cuentas en adquisiciones