En breve
Los documentos de contratación rusos rara vez emplean la expresión «videowall». El término que aparece en los pliegos de licitación es система отображения информации коллективного пользования, que literalmente significa «sistema de visualización de información de uso colectivo».
La diferencia no es cosmética: el término de la licitación designa el sistema completo y no las pantallas, y una oferta redactada con el vocabulario equivocado se percibe como una respuesta incompleta.
Qué abarca el término
Son cuatro grupos: la superficie de visualización (paneles LCD o gabinetes LED con sus soportes), el controlador —que hoy suele ser un servidor y no un equipo dedicado—, el software de control con sus roles de operador y disposiciones, y las fuentes que se muestran.
Un presupuesto que solo cubre el primer grupo responde a una pregunta distinta de la que planteaba la especificación.
Cómo redactar el requisito
Especifique capacidades, no un modelo: número de salidas de vídeo y su resolución, tipos y número de fuentes, roles de operador y requisitos de auditoría, sistema operativo y si el despliegue debe funcionar sin conectividad saliente.
Indicar el modelo de un fabricante ata la compra a un único proveedor y hace que la justificación sea más difícil de defender.
Pida a los responsables del emplazamiento y de compras que faciliten los requisitos de seguridad y de documentación aplicables. Documéntelos junto con la especificación técnica y acuerde cómo demostrará el proveedor el cumplimiento de cada uno durante la aceptación.
Convierta una tarea operativa en un requisito medible
Describa lo que el grupo necesita ver, no solo el equipamiento que prevé comprar. Defina los modos de operación: monitorización rutinaria, relevo de turno, coordinación de incidentes y briefing. Para cada modo, identifique a los destinatarios y a la persona que controla la visualización.
Elabore un registro de fuentes con el método de conexión, la resolución, la frecuencia de fotogramas, el responsable del acceso y la disponibilidad prevista. Indique qué fuentes aparecen juntas.
Un catálogo de todas las fuentes posibles es útil, pero no describe la carga de renderizado simultáneo.
Redacte un requisito aparte para la legibilidad. Seleccione etiquetas reales de los dashboards, anotaciones de mapas y detalles de vídeo, y acuerde después las posiciones de visualización que se usarán en la aceptación.
Una resolución indicada en la especificación no demuestra que un operador pueda leer el contenido previsto.
Defina las responsabilidades en los límites del sistema
Enumere los servicios que aporta el cliente: acceso a la red, cuentas de acceso a las fuentes, infraestructura de identidades, suministro eléctrico y acceso a la sala. Identifique el equipo responsable de cada uno.
Incluya los permisos necesarios para mostrar una fuente sin exponer credenciales de administrador a otros operadores.
Distinga la capa de visualización compartida del sistema responsable del proceso subyacente. Especifique dónde se emiten los comandos y qué información es de solo lectura en el videowall. Así, el plan de aceptación queda ligado a la función real del sistema de visualización.
Registre las interfaces necesarias sin dar por hecho que todos los fabricantes las implementan de la misma manera. Pida al proveedor que demuestre los formatos, el método de autenticación y el comportamiento de las fuentes que se usarán en la instalación.
Conserve una lista de las cuestiones de compatibilidad pendientes junto con la configuración propuesta.
Compare las ofertas sobre la misma lista de materiales
Separe las pantallas, el montaje, las conexiones de salida, el hardware de captura, el servidor del controlador, el software y los servicios. Pida a los licitadores que indiquen las cantidades incluidas, los supuestos y las exclusiones.
Una oferta comparable debe mostrar cómo se cumple cada requisito y qué dependencias siguen correspondiendo al cliente.
En el software con licencia por servidor, distinga los límites comerciales de la capacidad del hardware. Craft Wall no impone límites de licencia al número de pantallas, fuentes, operadores ni lienzos.
Aun así, el servidor necesita recursos de GPU y salidas físicas suficientes para la carga de trabajo acordada.
Redacte las pruebas de aceptación antes de la instalación
Describa una prueba repetible para cada requisito importante. Incluya la apertura de las fuentes previstas, la aplicación de una escena preparada, el cambio de disposición y el uso de los permisos de operador acordados.
Asigne a cada prueba un resultado esperado y un revisor responsable.
Pruebe con el equipo de implantación los escenarios de mantenimiento y recuperación exigidos. Registre qué ven los operadores cuando una fuente no está disponible, cómo se escala el problema y qué se comprueba antes de volver a la operación normal.
Al entregar el sistema, mantenga juntos la configuración aceptada, el registro de fuentes y las instrucciones para los operadores.
Los cambios futuros deben remitirse a esta documentación, de modo que añadir un dashboard o una pantalla no altere de forma inadvertida la carga de trabajo ni la responsabilidad de soporte acordada.