Comprenda OPR, URS y Basis of Design en proyectos de Data Center: requisitos del propietario y usuarios, respuesta de ingeniería, trazabilidad, commissioning y gobernanza documental.
¡Descúbrelo!
El OPR, URS y el Basis of Design organizan tres perspectivas diferentes del proyecto de un Data Center. El OPR registra lo que el propietario pretende alcanzar; la URS detalla las necesidades funcionales y operacionales de los usuarios; y el Basis of Design documenta cómo el equipo de ingeniería interpreta esos requisitos y desarrolla la solución técnica.
Estos documentos no deben tratarse como nombres intercambiables. El Owner’s Project Requirements (OPR) pertenece a la gobernanza del propietario y debe expresar objetivos, criterios de desempeño, operación, mantenimiento, expansión, riesgos y condiciones de aceptación. La User Requirements Specification (URS) reúne requisitos de usuarios, operadores, equipos de tecnología, seguridad, facilities y demás partes que utilizarán o sostendrán la instalación. El Basis of Design (BoD) es producido por el equipo de diseño para registrar premisas, criterios, cálculos, decisiones, interfaces y justificaciones adoptadas para atender el OPR y las necesidades aprobadas.
Cuando esta cadena documental es consistente, planos, memorias, especificaciones, propuestas, pruebas y procedimientos pueden relacionarse con requisitos verificables. Cuando no existe, el emprendimiento tiende a acumular decisiones implícitas, criterios contradictorios y brechas que aparecen solamente durante la contratación, la obra o el commissioning.
Síntesis técnica
| Documento | Pregunta principal | Responsabilidad dominante | Contenido central | Uso en la aceptación |
| OPR | ¿Qué necesita alcanzar el propietario? | Propietario, patrocinador y gobernanza | objetivos, desempeño, riesgos, operación, expansión y criterios de éxito | define la intención que debe demostrarse |
| URS | ¿Qué necesitan hacer y recibir los usuarios y operadores? | usuarios, TI, operación, facilities y áreas funcionales | funciones, capacidades, interfaces, condiciones de uso y restricciones | origina requisitos funcionales y operacionales verificables |
| Basis of Design | ¿Cómo pretende la ingeniería atender los requisitos? | diseñadores y responsables técnicos | premisas, criterios, arquitecturas, cálculos, selecciones y justificaciones | explica la solución que será inspeccionada y probada |
| Especificaciones y planos | ¿Qué debe suministrarse y construirse? | equipo de diseño | requisitos contractuales, detalles, materiales, equipos e instalación | establece obligaciones de suministro y ejecución |
| Plan y procedimientos de commissioning | ¿Cómo se demostrará el cumplimiento? | autoridad de commissioning y equipo del proyecto | inspecciones, pruebas, evidencias, responsabilidades y criterios | produce la verificación documentada |
La secuencia correcta no es necesariamente lineal, porque requisitos y decisiones maduran a lo largo del emprendimiento. Sin embargo, la dirección de autoridad debe permanecer clara: el diseño responde a los requisitos; los requisitos no deben reescribirse silenciosamente para justificar una solución ya elegida.
¿Qué es Owner’s Project Requirements?
El Owner’s Project Requirements, u OPR, es el documento que registra los requisitos funcionales del proyecto y las expectativas del propietario sobre uso y operación. La terminología y la función del OPR están consolidadas en el proceso de commissioning de ASHRAE. La propia ASHRAE destaca que el OPR debe orientar la verificación del éxito desde el preproyecto hasta la operación.
En un Data Center, el OPR transforma objetivos de inversión en criterios que la ingeniería, la contratación, la construcción y el commissioning puedan utilizar. No debe limitarse a declaraciones como “alta disponibilidad”, “máxima seguridad” o “alta eficiencia”. Estas expresiones deben traducirse en condiciones, prioridades, límites y métodos de verificación.
El OPR pertenece al propietario
Los consultores pueden facilitar workshops, organizar información y redactar el documento, pero la autoridad sobre los requisitos permanece con el propietario. Esto es importante porque las decisiones sobre tolerancia a fallas, inversión, crecimiento, riesgo residual y operación no pueden transferirse íntegramente al diseñador o al proveedor.
El propietario tampoco es una sola persona. En un emprendimiento de Data Center, esta función puede involucrar inversores, dirección, tecnología, facilities, operaciones, seguridad, sostenibilidad, finanzas, jurídico, compliance y usuarios de negocio. El OPR debe consolidar estas perspectivas y registrar conflictos que exijan decisión.
OPR no es solamente un programa de necesidades
El programa de necesidades describe áreas, capacidades y usos. El OPR es más amplio: incluye desempeño, calidad, operación, mantenimiento, documentación, capacitación, expansión, riesgos y criterios de aceptación. También debe indicar prioridades cuando los requisitos entran en tensión, por ejemplo:
- reducir CAPEX inicial versus preservar expansión;
- elevar disponibilidad versus limitar complejidad operacional;
- reducir consumo de agua versus reducir energía;
- estandarizar equipos versus preservar competencia entre proveedores;
- anticipar infraestructura común versus implantar solamente la capacidad ocupada.
Estas tensiones no se resuelven con una lista de equipos. Exigen gobernanza y decisión explícita.
¿Qué es User Requirements Specification?
La User Requirements Specification, o URS, describe aquello que usuarios y operadores esperan que la solución permita realizar. El término se utiliza ampliamente en ingeniería de requisitos, validación de sistemas y sectores regulados, pero su posición documental puede variar según la organización. En proyectos de Data Center, la URS puede existir como documento propio, conjunto de especificaciones funcionales o capa estructurada dentro del OPR.
Por eso, no es correcto afirmar que todo proyecto deba obligatoriamente poseer un documento llamado URS. Lo necesario es que las necesidades de los usuarios sean identificadas, aprobadas, transformadas en requisitos claros y trazadas hasta la verificación.
¿Quiénes son los usuarios de un Data Center?
El concepto incluye más personas y procesos que los consumidores finales de las aplicaciones. Entre los grupos relevantes están:
| Grupo | Ejemplos de necesidades |
| TI y plataforma | potencia por rack, conectividad, espacios, implantación, acceso y capacidad |
| operación de infraestructura | supervisión, alarmas, maniobras, mantenimiento, repuestos y documentación |
| seguridad | zonas, credenciales, investigación, retención de imágenes y respuesta |
| facilities | utilities, contratos, inspecciones, limpieza, agua y gestión predial |
| commissioning | puntos de medición, modos de prueba, cargas, accesos y evidencias |
| sostenibilidad | medición, energía, agua, emisiones, informes y metas |
| negocio o clientes | capacidad, plazo, disponibilidad, SLA, segregación y expansión |
| auditoría y compliance | registros, trazabilidad, segregación de funciones y retención documental |
Una necesidad puede ser legítima sin ser automáticamente aprobada. La URS debe registrar origen, justificación, prioridad y responsable de la aprobación.
Un requisito del usuario no es una preferencia de solución
“Necesitamos instalar UPS del fabricante X” generalmente es una preferencia de solución, no un requisito del usuario. El requisito subyacente puede ser compatibilidad con el mantenimiento existente, disponibilidad de repuestos, estandarización, eficiencia, autonomía o soporte regional. Al separar necesidad y solución, el proyecto preserva alternativas y reduce bloqueos tecnológicos sin justificación.
¿Qué es Basis of Design?
El Basis of Design, o BoD, es el documento del equipo de diseño que registra los conceptos, criterios, premisas, cálculos y decisiones utilizados para atender los requisitos del propietario. Explica la lógica de la solución y crea un puente entre OPR, URS, planos, memorias, especificaciones y pruebas.
ASHRAE relaciona el BoD con el proceso de commissioning: el propietario establece los requisitos y el equipo de diseño documenta los medios mediante los cuales pretende atenderlos. En Data Centers, el BoD debe demostrar cómo capacidad, disponibilidad, mantenimiento, seguridad, eficiencia, expansión y operación fueron transformados en arquitecturas multidisciplinarias.
BoD no es una memoria descriptiva genérica
Una memoria puede describir sistemas y equipos. El Basis of Design debe explicar por qué se adoptó la configuración, qué premisas sustentan los cálculos, qué alternativas fueron descartadas, qué interfaces son críticas y cómo se verificará el desempeño.
Por ejemplo, no basta registrar que habrá distribución eléctrica A/B. El BoD debe aclarar:
- qué cargas reciben dos caminos;
- dónde los caminos permanecen independientes;
- qué elementos son compartidos;
- cómo se mantiene cada camino;
- qué fallas fueron consideradas;
- cómo ocurren las transferencias y retornos;
- qué condiciones temporales surgen durante la expansión;
- cómo las pruebas demostrarán el comportamiento esperado.
El BoD debe evolucionar con el proyecto
En el concepto, registra criterios y arquitecturas de alto nivel. En el diseño básico, incorpora configuraciones, capacidades, interfaces y requisitos de contratación. En el ejecutivo, consolida cálculos, equipos seleccionados, secuencias y condiciones reales de instalación. Los cambios relevantes deben actualizar el BoD y la matriz de trazabilidad.
OPR, URS y Basis of Design no son sinónimos
| Aspecto | OPR | URS | Basis of Design |
| perspectiva | propietario | usuario y operación | diseñador |
| naturaleza | objetivos y criterios del emprendimiento | necesidades funcionales y operacionales | respuesta técnica y justificación |
| momento inicial | preproyecto | levantamiento de requisitos | diseño conceptual |
| lenguaje dominante | desempeño, riesgo y resultado | función, uso e interfaz | ingeniería, arquitectura y cálculo |
| autoridad de aprobación | propietario | propietario y responsables funcionales | responsable técnico y propietario, según gobernanza |
| relación con proveedores | orienta el alcance | informa funciones requeridas | fundamenta especificaciones y planos |
| relación con pruebas | define lo que debe demostrarse | define comportamientos y usos | define cómo debe responder la solución |
El modelo documental puede variar. Algunas organizaciones adoptan un OPR único con anexos de requisitos de usuarios. Otras mantienen URS separadas por disciplina o grupo funcional. También pueden utilizar Employer’s Requirements, Project Requirements, Design Criteria o Technical Requirements. El nombre es menos importante que la claridad de autoría, jerarquía, aprobación y trazabilidad.
Arquitectura documental recomendada
Una estructura práctica para Data Centers puede organizarse en cinco niveles.
- Objetivos y decisión de inversión: business case, estudio de viabilidad, requisitos estratégicos y límites del emprendimiento.
- Requisitos del propietario: OPR, políticas, metas, criterios de riesgo, disponibilidad, seguridad, sostenibilidad y operación.
- Requisitos de usuarios y funciones: URS, flujos, capacidades, interfaces, datos, accesos, alarmas, informes y mantenimiento.
- Respuesta de ingeniería: Basis of Design, criterios de diseño, cálculos, diagramas, layouts y matriz de interfaces.
- Documentos contractuales y de verificación: especificaciones, planos, RFP, submittals, FAT, SAT, pruebas integradas, as-built y documentación operacional.
Esta arquitectura no exige cinco archivos aislados. Exige cinco capas de información identificables y gobernadas.
¿Cuándo elaborar cada documento?
| Fase | OPR | URS | Basis of Design |
| oportunidad y viabilidad | versión inicial con objetivos, capacidad, riesgos y criterios | necesidades preliminares de los grupos críticos | solo conceptos o estudio de alternativas |
| selección del site | actualiza requisitos externos, plazo y expansión | incluye acceso, operación y conectividad | registra criterios utilizados en la comparación |
| diseño conceptual | baseline inicial aprobado | requisitos funcionales priorizados | arquitecturas y decisiones conceptuales |
| diseño básico | revisión controlada | consolidación para contratación | configuraciones, capacidades, interfaces y desempeño |
| diseño ejecutivo | cambios solamente mediante control formal | detalle de funciones afectadas | cálculos, equipos, secuencias y criterios finales |
| construcción | actualización por cambios aprobados | validación de desviaciones funcionales | incorpora submittals y decisiones de campo |
| commissioning | referencia principal de verificación | base de escenarios operacionales | referencia del comportamiento diseñado |
| entrega y operación | convertido en requisitos actuales de la instalación | procedimientos y usos consolidados | baseline técnico y registro de decisiones |
El OPR no debe congelarse demasiado pronto ni permanecer indefinido hasta el final. La gobernanza debe establecer baselines por gate y un proceso formal para cambios posteriores.
Contenido mínimo de un OPR para Data Center
Objetivos del emprendimiento
El documento debe explicar por qué existe el Data Center, qué servicios atiende, qué modelo operacional se adoptará y qué resultados justifican la inversión. Esto evita que las disciplinas desarrollen soluciones técnicamente correctas, pero desalineadas con el propósito.
Capacidad y crecimiento
Deben registrarse carga de TIC inicial y final, densidades, cantidad de racks, ocupación, horizonte, bloques de expansión y gatillos. El requisito debe diferenciar capacidad nominal, capacidad disponible y capacidad efectivamente utilizable.
Disponibilidad y continuidad
El OPR debe definir tolerancia a interrupciones, necesidad de mantenimiento concurrente, modos degradados aceptables, recuperación y dependencias entre infraestructura física y arquitectura de aplicaciones. Una clasificación Tier o Rated no sustituye la definición de los servicios y riesgos del propietario.
Operación y mantenimiento
Deben considerarse equipo, cobertura, capacitación, stock, asistencia, accesos, ventanas, procedimientos, capacidad de maniobra y filosofía de mantenimiento. Una solución con alta redundancia puede ser inadecuada cuando su complejidad excede la capacidad operacional.
Seguridad y compliance
El propietario debe indicar clasificación de áreas, perfiles de acceso, registros, retención, investigación, privacidad, segregación, auditoría y requisitos regulatorios aplicables.
Eficiencia y sostenibilidad
Las metas de energía, agua, emisiones, medición, informes y condiciones de carga deben tener fronteras claras. Un valor de PUE sin condición de utilización, clima y límite de medición no es un requisito verificable.
Expansión, flexibilidad y ciclo de vida
El OPR debe declarar qué interfaces deben prepararse, qué activos pueden anticiparse, cómo se construirán las nuevas fases y qué tecnologías deben permanecer sustituibles.
Commissioning y aceptación
El documento debe establecer alcance de sistemas, niveles de prueba, participación de proveedores, disponibilidad de cargas, evidencias, criterios, capacitación y documentación necesaria para la aceptación.
Transforme requisitos aprobados en una arquitectura multidisciplinaria coordinada y verificable.
A3A Engenharia desarrolla diseños conceptuales, básicos y ejecutivos preservando OPR, Basis of Design, interfaces, criterios de desempeño y requisitos de aceptación.
Contenido de una URS para Data Center
La URS debe transformar necesidades en declaraciones funcionales. Puede organizarse por usuarios, áreas o sistemas, pero debe evitar duplicidades y conflictos.
Capacidad e implantación de TIC
Los ejemplos incluyen dimensiones y masas de equipos, potencia por rack, alimentación A/B, conectores, posiciones, ocupación, flujo de implantación, staging, muelles, ascensores y rutas de movimiento.
Redes e interconexión
Deben definirse cantidad y diversidad de entradas, carriers, MMRs, backbone, fibras, cableado, patching, identificación, latencia, capacidad, crecimiento y requisitos de certificación.
Operación y supervisión
La URS puede especificar alarmas, prioridades, puntos, dashboards, históricos, informes, integraciones, sincronización de tiempo, acceso remoto, out-of-band y comportamiento durante pérdida de comunicación.
Seguridad física
Incluye recorridos de acceso, visitantes, contratistas, doble custodia, áreas críticas, videovigilancia, retención, investigación, credenciales, biometría, interbloqueos y contingencia.
Mantenimiento
Deben registrarse accesos, espacios, izado, sustitución, aislamiento, drenaje, iluminación, tomas, puntos de prueba, herramientas, repuestos y restricciones de trabajo en áreas activas.
Documentación y capacitación
La URS puede definir formatos, idioma, codificación, modelos, as-built, listas de activos, manuales, videos, simuladores, capacitación, evaluación de competencia y actualización posterior a cambios.
Cómo redactar requisitos verificables
Un requisito de calidad debe ser necesario, claro, singular, viable, trazable y verificable. ISO/IEC/IEEE 29148 proporciona fundamentos generales de ingeniería de requisitos que pueden adaptarse al emprendimiento.
Estructura recomendada
| Campo | Función |
| ID | identificación única y estable |
| declaración | requisito en lenguaje objetivo |
| origen | propietario, usuario, norma, riesgo o decisión |
| justificación | motivo y consecuencia |
| prioridad | obligatorio, deseable u opcional |
| responsable | quién decide y mantiene |
| método de verificación | análisis, inspección, demostración o prueba |
| fase de verificación | diseño, FAT, SAT, IST u operación |
| evidencia | documento, informe, registro o medición |
| estado | propuesto, aprobado, modificado, atendido o pendiente |
Lenguaje de obligación
Los requisitos contractuales deben utilizar lenguaje consistente. Una formulación común utiliza “debe” para obligación y evita expresiones vagas como “cuando sea posible”, “adecuado”, “preferentemente” o “alta calidad” sin criterio.
Débil: el sistema de climatización debe ser altamente confiable.
Mejor: la pérdida de una unidad de climatización del bloque no debe elevar la temperatura de entrada de los equipos de TIC por encima del límite aprobado durante la condición de diseño y por el período definido para respuesta operacional.
La formulación todavía debe indicar límite, condición de carga, ambiente, duración, método de medición y evidencia.
Matriz de trazabilidad de requisitos
La matriz conecta cada requisito con decisiones, documentos y verificaciones. No necesita ser una hoja de cálculo aislada; puede existir en una plataforma de requisitos o entorno común de datos. Lo esencial es mantener relaciones auditables.
| Requisito | Origen | BoD | Documento de diseño | Suministro | Verificación | Estado |
| OPR-AV-001 | continuidad del negocio | BOD-EL-03 | unifilar y especificación eléctrica | UPS, tableros y controles | FAT, SAT e IST | aprobado |
| URS-OPS-014 | operación | BOD-AUT-08 | lista de puntos y causa-efecto | BMS/EPMS | demostración y prueba | en revisión |
| OPR-SEC-006 | política de seguridad | BOD-SEG-02 | arquitectura de zonas | acceso y videovigilancia | inspección y escenario | aprobado |
| URS-MAN-021 | mantenimiento | BOD-MEC-12 | layout y detalles | equipos HVAC | inspección de acceso | pendiente |
La matriz debe permitir trazabilidad en ambos sentidos: desde un requisito hasta la evidencia y desde una prueba o equipo hasta los requisitos que justifican su existencia.
Cobertura y brechas
Indicadores simples ayudan a la gobernanza:
- requisitos sin respuesta en el BoD;
- decisiones de diseño sin requisito de origen;
- requisitos sin método de verificación;
- pruebas sin requisito asociado;
- cambios sin análisis de impacto;
- requisitos aprobados todavía sin evidencia de cumplimiento.
La cantidad de vínculos no sustituye la revisión técnica. Una relación puede existir y aun ser inadecuada.
Ejemplo de cadena completa de requisito
Considere la necesidad de mantenimiento de la alimentación eléctrica sin desconectar las cargas críticas.
- Objetivo del propietario: los servicios críticos deben permanecer disponibles durante el mantenimiento planificado de la infraestructura eléctrica.
- OPR: cada bloque debe permitir la retirada planificada de los componentes definidos sin interrupción de las cargas clasificadas como críticas, dentro de las condiciones y excepciones aprobadas.
- URS de operación: el equipo debe realizar aislamiento, transferencia, bloqueo, prueba y retorno mediante procedimientos controlados, con estados visibles en el EPMS.
- Basis of Design: la solución utiliza caminos A/B, dispositivos de aislamiento, bypass, lógica de transferencia y medición según los modos analizados.
- Diseño: unifilares, interbloqueos, lista de señales, especificaciones, selectividad, layouts y rutas detallan la solución.
- Verificación: revisión de diseño, FAT de controles, SAT, prueba de transferencia e IST demuestran los escenarios aprobados.
- Operación: MOP, SOP y capacitación consolidan el procedimiento y las restricciones conocidas.
Sin esta cadena, la frase “mantenimiento concurrente” puede ser interpretada de formas diferentes por propietario, diseñador, fabricante, instalador y operador.
Cómo elaborar el Basis of Design
Premisas y límites
El documento debe comenzar con alcance, referencias, condiciones de diseño, datos recibidos, premisas, exclusiones y responsabilidades. Cada premisa relevante necesita origen y estado. Una información todavía no confirmada no debe desaparecer dentro de un cálculo.
Criterios de capacidad
El BoD registra modelos de carga, factores, márgenes, simultaneidad, crecimiento, derating, reservas y capacidad utilizable. Debe explicar cómo la carga de TIC se transforma en demanda eléctrica, carga térmica, agua, espacio, peso y telecomunicaciones.
Arquitectura y redundancia
Las topologías deben justificarse mediante requisitos y análisis de riesgo. El documento debe identificar componentes redundantes, compartidos, modos comunes, estados degradados, recuperación y limitaciones.
Selección de tecnologías
La decisión entre agua helada, expansión directa, InRow, refrigeración líquida, baterías de plomo-ácido o litio, UPS centralizada o distribuida y otras alternativas debe registrar criterios técnicos y operacionales, no solamente marcas o preferencias.
Secuencias e interbloqueos
El BoD debe describir el comportamiento esperado durante arranque, parada, falla, transferencia, emergencia, mantenimiento y retorno. Las secuencias deben ser coherentes entre eléctrica, mecánica, automatización, incendios y seguridad.
Mantenibilidad y sustitución
Deben considerarse aislamiento, acceso, desmontaje, izado, drenaje, repuestos, herramientas, iluminación, seguridad e impacto sobre otros sistemas. El espacio geométrico sin un procedimiento viable no representa mantenibilidad.
Expansión y estados temporales
El documento debe registrar condición inicial, fases, capacidad final, interfaces preparadas y estados transitorios. La arquitectura final puede ser resiliente mientras una etapa intermedia posee vulnerabilidades diferentes.
Testabilidad
Deben preverse puntos de medición, cargas, simulaciones, modos de prueba, bypass, conexiones temporales y seguridad de los ensayos. Un requisito no verificable en campo necesita otro método de evidencia aprobado.
Relación con normas y referencias técnicas
La serie ISO/IEC 22237 organiza principios, clasificaciones y requisitos de infraestructura de Data Centers. La ANSI/TIA-942-C abarca arquitectura, telecomunicaciones, energía, climatización, seguridad y demás sistemas para instalaciones de diferentes tipos y tamaños.
Estas referencias no escriben el OPR del propietario. Ofrecen requisitos, clasificaciones y buenas prácticas que deben seleccionarse según riesgos, legislación y finalidad del emprendimiento. Adoptar una norma no elimina la necesidad de declarar edición, alcance, excepciones y criterios específicos.
El artículo sobre Tier I, II, III y IV en Data Centers explica por qué clasificación, redundancia y disponibilidad del servicio no deben confundirse.
Relación con diseño conceptual, básico y ejecutivo
El artículo Cómo diseñar un Data Center: etapas, disciplinas y entregables presenta el proceso multidisciplinario completo. Dentro de él, los documentos de requisitos y el BoD asumen funciones diferentes en cada fase.
| Fase | Función de los requisitos | Función del BoD |
| conceptual | seleccionar objetivos, prioridades y restricciones | comparar alternativas y fijar principios |
| básico | consolidar criterios para contratación | definir configuraciones, desempeño e interfaces |
| ejecutivo | controlar cambios y detalles afectados | registrar cálculos, elecciones y comportamiento final |
| construcción | evaluar desvíos y propuestas | incorporar submittals y decisiones aprobadas |
| commissioning | definir lo que debe demostrarse | explicar cómo debería funcionar la solución |
| operación | preservar intención y límites | formar baseline técnico para cambios futuros |
Un diseño ejecutivo detallado no compensa requisitos inadecuados. Solo detalla con mayor precisión una solución que puede estar equivocada.
OPR, URS y BoD en la RFP y la contratación
Una RFP consistente debe declarar qué requisitos son obligatorios, cuáles permiten alternativas y cómo se presentarán los desvíos. El proveedor no debe tener que inferir objetivos del propietario a partir de planos incompletos.
Jerarquía contractual
La documentación debe establecer precedencia entre OPR, especificaciones, planos, listas, normas y propuestas. El OPR puede orientar la intención sin necesariamente incorporarse íntegramente como documento contractual. La organización debe evitar conflictos en los que un requisito de alto nivel contradiga una obligación detallada sin mecanismo de resolución.
Matriz de conformidad
Cada proponente puede estar obligado a responder:
| Respuesta | Significado |
| cumple | la solución cumple íntegramente el requisito |
| cumple con aclaración | cumple, pero exige una interpretación registrada |
| alternativa | ofrece una solución diferente con impacto demostrado |
| desvío | no cumple y solicita aceptación formal |
| no aplicable | el requisito no pertenece al alcance, con justificación |
El silencio no debe interpretarse automáticamente como conformidad.
Desvíos técnicos
El desvío debe indicar requisito afectado, solución propuesta, motivo, impacto en capacidad, disponibilidad, operación, mantenimiento, plazo, costo, pruebas y documentación. La aprobación debe actualizar trazabilidad y BoD.
Mantenga requisitos, decisiones, desvíos y cambios trazables durante contratación e implantación.
Owner’s Engineering representa los intereses del propietario en la revisión de diseños, propuestas, submittals, interfaces, cambios y evidencias de cumplimiento.
Gobernanza de cambios
Los cambios son inevitables; los cambios sin trazabilidad no. Un proceso mínimo incluye:
- identificación del cambio y de los requisitos afectados;
- justificación y alternativas;
- análisis multidisciplinario de impacto;
- evaluación de costo, plazo, riesgo, operación y pruebas;
- decisión por una autoridad definida;
- actualización de OPR, URS, BoD y documentos asociados;
- comunicación a las partes y revisión de la matriz de trazabilidad;
- verificación de la implantación y cierre del cambio.
La decisión debe preservar el historial. Sustituir silenciosamente una premisa borra la razón por la cual se tomaron decisiones anteriores.
Baselines y gates
En cada gate, versiones específicas se aprueban como baseline. Los nuevos requisitos ingresan mediante cambio controlado, no por comentarios dispersos en actas, correos o planos. Esto permite distinguir una evolución legítima del scope creep.
Revisión de calidad del OPR
Antes de la aprobación, el OPR debe verificarse en cuanto a:
| Criterio | Pregunta de revisión |
| completitud | ¿están cubiertos objetivos, capacidad, operación, seguridad, expansión y aceptación? |
| claridad | ¿los términos vagos tienen definición y límite? |
| consistencia | ¿los requisitos se contradicen? |
| viabilidad | ¿plazo, tecnología, presupuesto y operación son compatibles? |
| prioridad | ¿los conflictos poseen regla de decisión? |
| verificabilidad | ¿existen método y evidencia posibles? |
| trazabilidad | ¿origen, responsable y versión están registrados? |
| aplicabilidad | ¿las normas y requisitos externos están correctamente seleccionados? |
La revisión debe involucrar propietarios funcionales, no solamente al equipo de ingeniería.
Revisión de calidad de la URS
La URS debe probarse contra jornadas y escenarios reales. Los workshops pueden utilizar flujos como implantación de un nuevo rack, mantenimiento de UPS, entrada de contratistas, respuesta a fugas, pérdida de comunicación, falla de sensor, investigación de acceso y expansión de capacidad.
Este enfoque revela requisitos que las listas genéricas no capturan: tiempo de respuesta, permisos, visualización, espacio, secuencia, datos, documentación y responsabilidades.
Revisión de calidad del Basis of Design
El BoD debe revisarse por disciplina y por interfaz. Una revisión adecuada confronta requisitos, diagramas, cálculos, layouts, secuencias y métodos de prueba.
Preguntas críticas
- ¿Cada arquitectura responde a requisitos aprobados?
- ¿Las capacidades utilizan premisas consistentes entre disciplinas?
- ¿Se identificaron modos comunes y estados degradados?
- ¿El mantenimiento puede ejecutarse con seguridad?
- ¿Los equipos pueden sustituirse?
- ¿Las fases temporales están representadas?
- ¿Las secuencias de control son coherentes?
- ¿El diseño posee puntos y condiciones de prueba?
- ¿Las excepciones y riesgos residuales están explícitos?
Una revisión de clash detection no responde a estas preguntas.
Integración con BIM y entorno común de datos
BIM puede asociar requisitos a espacios, sistemas y activos, pero no sustituye la gobernanza. El entorno común de datos debe controlar códigos, versiones, estados, aprobaciones, comentarios y transmittals.
Una estructura posible relaciona:
- requisito con sistema y espacio;
- objeto BIM con especificación y submittal;
- activo con prueba e informe;
- cambio con documentos afectados;
- pendiente con responsable y gate;
- as-built con registro operacional.
Los vínculos deben sobrevivir a la exportación, entrega y operación. Una plataforma sin plan de datos puede concentrar información que se pierde en el handover.
Integración con commissioning
El commissioning no debe comenzar con la redacción de pruebas al final de la obra. La ASHRAE/IES Standard 202 describe un proceso integrado para entregar instalaciones que atiendan el OPR.
Revisión de diseño
La autoridad de commissioning verifica si el BoD y los documentos responden a los requisitos, identificando brechas de testabilidad, operación, medición, acceso y secuencia.
Submittals y FAT
Las propuestas y planos de fabricantes se evalúan frente a especificaciones y requisitos. Los FAT pueden verificar funciones, controles, alarmas y desempeño antes del envío, reduciendo descubrimientos en el site.
SAT y pruebas funcionales
En campo, inspecciones y pruebas confirman instalación, configuración y comportamiento de sistemas individuales. Cada procedimiento debe indicar requisitos, precondiciones, instrumentos, pasos, criterios y evidencias.
Pruebas integradas de sistemas
Los IST demuestran interacciones durante fallas y transiciones: pérdida de red, arranque de generadores, transferencia de UPS, falla de climatización, incendio, pérdida de comunicación, mantenimiento y retorno a la condición normal.
Defina los criterios de verificación antes de la compra, la instalación y las pruebas.
El commissioning conecta OPR, Basis of Design, especificaciones, FAT, SAT, pruebas funcionales y pruebas integradas para producir evidencias objetivas de cumplimiento.
Entrega a operación
Al final, los requisitos y el BoD deben reconciliarse con la instalación construida. La documentación de operación debe reflejar desvíos aprobados, limitaciones, configuraciones y evidencias.
Current Facility Requirements
En el proceso de commissioning, los requisitos de la instalación existente pueden consolidarse como Current Facility Requirements. Para Data Centers, esta lógica ayuda a mantener una referencia actualizada después de cambios, expansiones y modernizaciones.
Baseline operacional
El handover debe conectar:
- requisitos vigentes;
- BoD final;
- as-built y diagramas;
- listas de activos y configuraciones;
- pruebas y pendientes;
- MOPs, SOPs y EOPs;
- capacitación y competencia;
- límites operacionales;
- plan de mantenimiento;
- matriz de alarmas y escalamiento.
Sin esta reconciliación, la operación recibe documentos históricos que no representan la instalación real.
Ejemplo de estructura de OPR
| Sección | Contenido |
| 1. gobernanza | propósito, alcance, autoridades, aprobaciones y control de cambios |
| 2. contexto | negocio, usuarios, servicios y modelo operacional |
| 3. capacidad | TIC, racks, densidad, crecimiento y fases |
| 4. disponibilidad | criticidad, mantenimiento, fallas y recuperación |
| 5. implantación | site, edificios, expansión, accesos y logística |
| 6. infraestructura | energía, térmica, telecom, automatización y utilities |
| 7. seguridad | física, cibernética, incendios y compliance |
| 8. operación | equipo, procedimientos, mantenimiento, repuestos y soporte |
| 9. sostenibilidad | energía, agua, emisiones, medición e informes |
| 10. calidad y pruebas | revisiones, FAT, SAT, IST y evidencias |
| 11. documentación | formatos, codificación, BIM, as-built y handover |
| 12. riesgos y excepciones | condicionantes, riesgos aceptados y decisiones pendientes |
Ejemplo de estructura de Basis of Design
| Sección | Contenido |
| 1. alcance y referencias | límites, normas, documentos de entrada e interfaces |
| 2. premisas | datos, condiciones de diseño, márgenes y pendientes |
| 3. criterios generales | capacidad, disponibilidad, seguridad y eficiencia |
| 4. arquitectura | implantación, bloques, redundancia y expansión |
| 5. disciplinas | bases eléctricas, mecánicas, telecom, automatización y seguridad |
| 6. modos de operación | normal, mantenimiento, falla, emergencia y retorno |
| 7. cálculos y selecciones | modelos, factores, derating y alternativas |
| 8. coordinación | espacios, rutas, cargas, interfaces y responsabilidades |
| 9. testabilidad | puntos, cargas, procedimientos y criterios |
| 10. riesgos y excepciones | limitaciones, desvíos y riesgo residual |
| 11. cambios | decisiones, revisiones e impactos |
| 12. anexos | diagramas, matrices, tablas y registros |
Errores comunes
| Error | Consecuencia |
| copiar el OPR de otro emprendimiento | requisitos incompatibles con el negocio y la operación |
| usar términos vagos | proveedores y diseñadores adoptan interpretaciones diferentes |
| confundir requisito y solución | bloqueo tecnológico y competencia limitada |
| dejar usuarios fuera del proceso | operación recibe una instalación difícil de usar y mantener |
| producir el BoD después de los planos | el documento se convierte en justificación retrospectiva |
| no registrar premisas | los cálculos parecen precisos sobre datos inciertos |
| no definir métodos de verificación | los requisitos no pueden aceptarse objetivamente |
| no controlar cambios | diseño, contrato y pruebas utilizan versiones diferentes |
| tratar una norma como OPR | los objetivos específicos del propietario quedan ausentes |
| desconectar el commissioning | las pruebas se improvisan al final de la obra |
| no reconciliar as-built y BoD | el baseline operacional no representa la instalación |
| crear documentos excesivos sin jerarquía | la duplicidad y el conflicto aumentan en lugar de reducirse |
Checklist de gobernanza documental
- ¿Están definidos el objetivo y el modelo de operación del Data Center?
- ¿Existe autoridad formal para aprobar requisitos y cambios?
- ¿El OPR diferencia objetivos, requisitos y preferencias?
- ¿Participaron usuarios de TI, operación, seguridad y facilities?
- ¿Los requisitos poseen IDs, origen, prioridad y responsable?
- ¿Los criterios vagos se transformaron en condiciones medibles?
- ¿Cada requisito posee método y fase de verificación?
- ¿El BoD registra premisas y datos todavía pendientes?
- ¿Las elecciones de arquitectura poseen justificación vinculada a requisitos?
- ¿Las capacidades y márgenes son consistentes entre disciplinas?
- ¿Están descritos los modos normal, mantenimiento, falla y emergencia?
- ¿Se consideraron expansiones y estados temporales?
- ¿La matriz conecta requisitos, documentos, suministros y pruebas?
- ¿La RFP exige conformidad y declaración de desvíos?
- ¿Los submittals se revisan frente a requisitos y BoD?
- ¿Los cambios actualizan todos los documentos afectados?
- ¿FAT, SAT e IST citan requisitos verificables?
- ¿Los pendientes poseen responsable, plazo e impacto en la aceptación?
- ¿El as-built fue reconciliado con el BoD final?
- ¿La operación recibió baseline, procedimientos y límites actualizados?
Alcance de Ingeniería Consultiva de A3A Engenharia
A3A Engenharia apoya a propietarios y operadores en la estructuración de requisitos y bases de diseño para nuevos Data Centers, expansiones, modernizaciones, entornos Edge, instalaciones corporativas, colocation y soluciones modulares.
El alcance puede incluir workshops con stakeholders, levantamiento de necesidades, elaboración o revisión de OPR y URS, desarrollo del Basis of Design, matriz de trazabilidad, criterios de contratación, revisión multidisciplinaria, gestión de interfaces, requisitos de commissioning y reconciliación de la documentación final.
La actuación puede integrar el Estudio de Viabilidad de Data Center, el Diseño de Data Center, Owner’s Engineering para Data Centers y Commissioning y Aceptación de Data Centers.
Resumen técnico
OPR, URS y Basis of Design poseen funciones complementarias. El OPR registra objetivos y criterios del propietario; la URS estructura necesidades de usuarios y operadores; y el BoD documenta cómo la ingeniería responde a esos requisitos mediante premisas, criterios, arquitecturas, cálculos y decisiones.
La calidad depende menos del nombre de los archivos y más de la gobernanza: autoría, aprobación, jerarquía, identificación, verificabilidad, trazabilidad y control de cambios. Los requisitos deben orientar diseño, contratación y pruebas; el BoD debe explicar las elecciones; y el commissioning debe producir evidencias de cumplimiento.
Cuando esta cadena se mantiene hasta el as-built y la operación, el emprendimiento preserva su intención técnica. Cuando se rompe, el proyecto tiende a acumular decisiones implícitas, desvíos no evaluados y criterios de aceptación definidos demasiado tarde.
Referencias técnicas
[1] ASHRAE. ASHRAE Guideline 0-2019 — The Commissioning Process. Atlanta: ASHRAE, 2019.
[2] ASHRAE; IES. ANSI/ASHRAE/IES Standard 202-2024 — The Commissioning Process Requirements for New Buildings and New Systems. Atlanta: ASHRAE, 2024.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 22237-1:2021 — Information technology — Data centre facilities and infrastructures — Part 1: General concepts. Geneva: ISO, 2021.
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC TS 22237-7:2018 — Information technology — Data centre facilities and infrastructures — Part 7: Management and operational information. Geneva: ISO, 2018.
[5] TELECOMMUNICATIONS INDUSTRY ASSOCIATION. ANSI/TIA-942-C — Telecommunications Infrastructure Standard for Data Centers. Arlington: TIA, 2024.
[6] BICSI. ANSI/BICSI 002-2024 — The Standard for Data Center Design. Tampa: BICSI, 2024.
[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEEE. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. Geneva: ISO, 2018.
[8] UPTIME INSTITUTE. Tier Standard: Topology for Data Center Site Infrastructure. Uptime Institute.
[9] ASHRAE. Thermal Guidelines for Data Processing Environments. 5. ed. Atlanta: ASHRAE.
[10] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018.
[11] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9001:2015 — Quality management systems — Requirements. Geneva: ISO, 2015.
[12] A3A ENGENHARIA. Diseño de Data Center: estudio, diseño básico y ejecutivo. Ponta Grossa: A3A Engenharia.
Preguntas frecuentes
El OPR registra objetivos y criterios del propietario; la URS detalla necesidades funcionales y operacionales de los usuarios; y el Basis of Design documenta cómo el equipo de diseño pretende atender esos requisitos.
No necesariamente. La organización puede mantener requisitos de usuarios dentro del OPR o en documentos separados. Lo esencial es garantizar autoría, aprobación, claridad y trazabilidad.
El propietario es responsable del contenido y de la aprobación. Los consultores pueden facilitar workshops y redactar el documento, pero las decisiones sobre objetivos, riesgos, operación e inversión pertenecen al propietario.
El equipo de diseño y los responsables técnicos elaboran el BoD, registrando premisas, criterios, cálculos, arquitecturas y justificaciones utilizadas para atender los requisitos aprobados.
Depende de la estrategia contractual. Puede orientar la intención sin ser incorporado íntegramente como documento contractual. La jerarquía entre OPR, especificaciones, planos y propuestas debe ser explicitada.
Debe comenzar en el preproyecto o en la viabilidad y madurar a lo largo de los gates. Después de cada baseline, los cambios deben seguir un proceso formal de evaluación y aprobación.
El requisito debe indicar condición, límite y método posible de comprobación, como análisis, inspección, demostración o prueba, además de la evidencia esperada y de la fase de verificación.
No. El BoD explica la lógica y las bases de la solución. Memorias de cálculo, memorias descriptivas, especificaciones, diagramas, plantas y detalles desarrollan y contractualizan esa solución.
El OPR define lo que debe alcanzarse; el BoD explica cómo el diseño pretende atenderlo; y el commissioning revisa, inspecciona y prueba la solución para producir evidencias de cumplimiento.
Es el mecanismo que relaciona cada requisito con su origen, respuesta en el BoD, documentos de diseño, suministros, métodos de verificación, evidencias y estado.
Materiales técnicos complementarios
Fundamentos y planificación
- Data Center: qué es, cómo funciona y qué sistemas componen la infraestructura
- Estudio de viabilidad de Data Center: energía, conectividad, terreno y riesgos
- Cómo elegir la ubicación de un Data Center
Requisitos, arquitectura y diseño
- Cómo diseñar un Data Center: etapas, disciplinas y entregables
- Diseño de Data Center
- Tier I, II, III y IV en Data Centers
- Data Center modular: diseño, riesgos y cuándo utilizarlo
Gobernanza, contratación y control de cambios
- Owner’s Engineering para Data Centers
- Ingeniería Integrada para Data Centers
- Stage-gate en proyectos de ingeniería
- Gestión de riesgos en proyectos de ingeniería
Commissioning, verificación y aceptación
- Commissioning y Aceptación de Data Centers
- Commissioning de sistemas críticos
- SLA: cómo definir y calcular el nivel de servicio
Disciplinas y sistemas especializados
- Redes y Telecomunicaciones para Data Centers
- Climatización de Data Centers
- DCIM para Data Centers
- Seguridad Física para Data Centers
- Detección y Supresión de Incendios en Data Centers
Modelos y escalas de implantación
- Hyperscale Data Center: qué es y cómo funciona
- Colocation Data Center: cómo evaluar un proveedor
- Edge Data Center: aplicaciones y arquitectura
- Micro Data Center: aplicaciones y criterios de especificación
