{"id":81790,"date":"2026-09-19T18:42:43","date_gmt":"2026-09-19T21:42:43","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&#038;p=81790"},"modified":"2026-09-19T18:43:11","modified_gmt":"2026-09-19T21:43:11","slug":"basis-of-design-opr-urs-proyectos-data-center","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/es-es\/contenido\/articulos-tecnicos\/basis-of-design-opr-urs-proyectos-data-center\/","title":{"rendered":"Basis of Design, OPR y URS en proyectos de Data Center"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">El <strong>OPR, URS y el Basis of Design organizan tres perspectivas diferentes del proyecto de un Data Center<\/strong>. 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\u00f3mo el equipo de ingenier\u00eda interpreta esos requisitos y desarrolla la soluci\u00f3n t\u00e9cnica.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Estos documentos no deben tratarse como nombres intercambiables. El <strong>Owner\u2019s Project Requirements (OPR)<\/strong> pertenece a la gobernanza del propietario y debe expresar objetivos, criterios de desempe\u00f1o, operaci\u00f3n, mantenimiento, expansi\u00f3n, riesgos y condiciones de aceptaci\u00f3n. La <strong>User Requirements Specification (URS)<\/strong> re\u00fane requisitos de usuarios, operadores, equipos de tecnolog\u00eda, seguridad, facilities y dem\u00e1s partes que utilizar\u00e1n o sostendr\u00e1n la instalaci\u00f3n. El <strong>Basis of Design (BoD)<\/strong> es producido por el equipo de dise\u00f1o para registrar premisas, criterios, c\u00e1lculos, decisiones, interfaces y justificaciones adoptadas para atender el OPR y las necesidades aprobadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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\u00edcitas, criterios contradictorios y brechas que aparecen solamente durante la contrataci\u00f3n, la obra o el commissioning.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">S\u00edntesis t\u00e9cnica<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Documento<\/td><td>Pregunta principal<\/td><td>Responsabilidad dominante<\/td><td>Contenido central<\/td><td>Uso en la aceptaci\u00f3n<\/td><\/tr><tr><td>OPR<\/td><td>\u00bfQu\u00e9 necesita alcanzar el propietario?<\/td><td>Propietario, patrocinador y gobernanza<\/td><td>objetivos, desempe\u00f1o, riesgos, operaci\u00f3n, expansi\u00f3n y criterios de \u00e9xito<\/td><td>define la intenci\u00f3n que debe demostrarse<\/td><\/tr><tr><td>URS<\/td><td>\u00bfQu\u00e9 necesitan hacer y recibir los usuarios y operadores?<\/td><td>usuarios, TI, operaci\u00f3n, facilities y \u00e1reas funcionales<\/td><td>funciones, capacidades, interfaces, condiciones de uso y restricciones<\/td><td>origina requisitos funcionales y operacionales verificables<\/td><\/tr><tr><td>Basis of Design<\/td><td>\u00bfC\u00f3mo pretende la ingenier\u00eda atender los requisitos?<\/td><td>dise\u00f1adores y responsables t\u00e9cnicos<\/td><td>premisas, criterios, arquitecturas, c\u00e1lculos, selecciones y justificaciones<\/td><td>explica la soluci\u00f3n que ser\u00e1 inspeccionada y probada<\/td><\/tr><tr><td>Especificaciones y planos<\/td><td>\u00bfQu\u00e9 debe suministrarse y construirse?<\/td><td>equipo de dise\u00f1o<\/td><td>requisitos contractuales, detalles, materiales, equipos e instalaci\u00f3n<\/td><td>establece obligaciones de suministro y ejecuci\u00f3n<\/td><\/tr><tr><td>Plan y procedimientos de commissioning<\/td><td>\u00bfC\u00f3mo se demostrar\u00e1 el cumplimiento?<\/td><td>autoridad de commissioning y equipo del proyecto<\/td><td>inspecciones, pruebas, evidencias, responsabilidades y criterios<\/td><td>produce la verificaci\u00f3n documentada<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">La secuencia correcta no es necesariamente lineal, porque requisitos y decisiones maduran a lo largo del emprendimiento. Sin embargo, la direcci\u00f3n de autoridad debe permanecer clara: <strong>el dise\u00f1o responde a los requisitos; los requisitos no deben reescribirse silenciosamente para justificar una soluci\u00f3n ya elegida<\/strong>.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfQu\u00e9 es Owner\u2019s Project Requirements?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El <strong>Owner\u2019s Project Requirements<\/strong>, u OPR, es el documento que registra los requisitos funcionales del proyecto y las expectativas del propietario sobre uso y operaci\u00f3n. La terminolog\u00eda y la funci\u00f3n del OPR est\u00e1n consolidadas en el proceso de commissioning de ASHRAE. La propia ASHRAE destaca que el OPR debe orientar la verificaci\u00f3n del \u00e9xito desde el preproyecto hasta la operaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En un Data Center, el OPR transforma objetivos de inversi\u00f3n en criterios que la ingenier\u00eda, la contrataci\u00f3n, la construcci\u00f3n y el commissioning puedan utilizar. No debe limitarse a declaraciones como \u201calta disponibilidad\u201d, \u201cm\u00e1xima seguridad\u201d o \u201calta eficiencia\u201d. Estas expresiones deben traducirse en condiciones, prioridades, l\u00edmites y m\u00e9todos de verificaci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">El OPR pertenece al propietario<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Los consultores pueden facilitar workshops, organizar informaci\u00f3n 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\u00f3n, crecimiento, riesgo residual y operaci\u00f3n no pueden transferirse \u00edntegramente al dise\u00f1ador o al proveedor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El propietario tampoco es una sola persona. En un emprendimiento de Data Center, esta funci\u00f3n puede involucrar inversores, direcci\u00f3n, tecnolog\u00eda, facilities, operaciones, seguridad, sostenibilidad, finanzas, jur\u00eddico, compliance y usuarios de negocio. El OPR debe consolidar estas perspectivas y registrar conflictos que exijan decisi\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">OPR no es solamente un programa de necesidades<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El programa de necesidades describe \u00e1reas, capacidades y usos. El OPR es m\u00e1s amplio: incluye desempe\u00f1o, calidad, operaci\u00f3n, mantenimiento, documentaci\u00f3n, capacitaci\u00f3n, expansi\u00f3n, riesgos y criterios de aceptaci\u00f3n. Tambi\u00e9n debe indicar prioridades cuando los requisitos entran en tensi\u00f3n, por ejemplo:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>reducir CAPEX inicial versus preservar expansi\u00f3n;<\/li><li>elevar disponibilidad versus limitar complejidad operacional;<\/li><li>reducir consumo de agua versus reducir energ\u00eda;<\/li><li>estandarizar equipos versus preservar competencia entre proveedores;<\/li><li>anticipar infraestructura com\u00fan versus implantar solamente la capacidad ocupada.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Estas tensiones no se resuelven con una lista de equipos. Exigen gobernanza y decisi\u00f3n expl\u00edcita.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfQu\u00e9 es User Requirements Specification?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La <strong>User Requirements Specification<\/strong>, o URS, describe aquello que usuarios y operadores esperan que la soluci\u00f3n permita realizar. El t\u00e9rmino se utiliza ampliamente en ingenier\u00eda de requisitos, validaci\u00f3n de sistemas y sectores regulados, pero su posici\u00f3n documental puede variar seg\u00fan la organizaci\u00f3n. En proyectos de Data Center, la URS puede existir como documento propio, conjunto de especificaciones funcionales o capa estructurada dentro del OPR.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfQui\u00e9nes son los usuarios de un Data Center?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El concepto incluye m\u00e1s personas y procesos que los consumidores finales de las aplicaciones. Entre los grupos relevantes est\u00e1n:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Grupo<\/td><td>Ejemplos de necesidades<\/td><\/tr><tr><td>TI y plataforma<\/td><td>potencia por rack, conectividad, espacios, implantaci\u00f3n, acceso y capacidad<\/td><\/tr><tr><td>operaci\u00f3n de infraestructura<\/td><td>supervisi\u00f3n, alarmas, maniobras, mantenimiento, repuestos y documentaci\u00f3n<\/td><\/tr><tr><td>seguridad<\/td><td>zonas, credenciales, investigaci\u00f3n, retenci\u00f3n de im\u00e1genes y respuesta<\/td><\/tr><tr><td>facilities<\/td><td>utilities, contratos, inspecciones, limpieza, agua y gesti\u00f3n predial<\/td><\/tr><tr><td>commissioning<\/td><td>puntos de medici\u00f3n, modos de prueba, cargas, accesos y evidencias<\/td><\/tr><tr><td>sostenibilidad<\/td><td>medici\u00f3n, energ\u00eda, agua, emisiones, informes y metas<\/td><\/tr><tr><td>negocio o clientes<\/td><td>capacidad, plazo, disponibilidad, SLA, segregaci\u00f3n y expansi\u00f3n<\/td><\/tr><tr><td>auditor\u00eda y compliance<\/td><td>registros, trazabilidad, segregaci\u00f3n de funciones y retenci\u00f3n documental<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Una necesidad puede ser leg\u00edtima sin ser autom\u00e1ticamente aprobada. La URS debe registrar origen, justificaci\u00f3n, prioridad y responsable de la aprobaci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Un requisito del usuario no es una preferencia de soluci\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">\u201cNecesitamos instalar UPS del fabricante X\u201d generalmente es una preferencia de soluci\u00f3n, no un requisito del usuario. El requisito subyacente puede ser compatibilidad con el mantenimiento existente, disponibilidad de repuestos, estandarizaci\u00f3n, eficiencia, autonom\u00eda o soporte regional. Al separar necesidad y soluci\u00f3n, el proyecto preserva alternativas y reduce bloqueos tecnol\u00f3gicos sin justificaci\u00f3n.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfQu\u00e9 es Basis of Design?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El <strong>Basis of Design<\/strong>, o BoD, es el documento del equipo de dise\u00f1o que registra los conceptos, criterios, premisas, c\u00e1lculos y decisiones utilizados para atender los requisitos del propietario. Explica la l\u00f3gica de la soluci\u00f3n y crea un puente entre OPR, URS, planos, memorias, especificaciones y pruebas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">ASHRAE relaciona el BoD con el proceso de commissioning: el propietario establece los requisitos y el equipo de dise\u00f1o documenta los medios mediante los cuales pretende atenderlos. En Data Centers, el BoD debe demostrar c\u00f3mo capacidad, disponibilidad, mantenimiento, seguridad, eficiencia, expansi\u00f3n y operaci\u00f3n fueron transformados en arquitecturas multidisciplinarias.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">BoD no es una memoria descriptiva gen\u00e9rica<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Una memoria puede describir sistemas y equipos. El Basis of Design debe explicar <strong>por qu\u00e9<\/strong> se adopt\u00f3 la configuraci\u00f3n, qu\u00e9 premisas sustentan los c\u00e1lculos, qu\u00e9 alternativas fueron descartadas, qu\u00e9 interfaces son cr\u00edticas y c\u00f3mo se verificar\u00e1 el desempe\u00f1o.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, no basta registrar que habr\u00e1 distribuci\u00f3n el\u00e9ctrica A\/B. El BoD debe aclarar:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>qu\u00e9 cargas reciben dos caminos;<\/li><li>d\u00f3nde los caminos permanecen independientes;<\/li><li>qu\u00e9 elementos son compartidos;<\/li><li>c\u00f3mo se mantiene cada camino;<\/li><li>qu\u00e9 fallas fueron consideradas;<\/li><li>c\u00f3mo ocurren las transferencias y retornos;<\/li><li>qu\u00e9 condiciones temporales surgen durante la expansi\u00f3n;<\/li><li>c\u00f3mo las pruebas demostrar\u00e1n el comportamiento esperado.<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">El BoD debe evolucionar con el proyecto<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">En el concepto, registra criterios y arquitecturas de alto nivel. En el dise\u00f1o b\u00e1sico, incorpora configuraciones, capacidades, interfaces y requisitos de contrataci\u00f3n. En el ejecutivo, consolida c\u00e1lculos, equipos seleccionados, secuencias y condiciones reales de instalaci\u00f3n. Los cambios relevantes deben actualizar el BoD y la matriz de trazabilidad.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">OPR, URS y Basis of Design no son sin\u00f3nimos<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Aspecto<\/td><td>OPR<\/td><td>URS<\/td><td>Basis of Design<\/td><\/tr><tr><td>perspectiva<\/td><td>propietario<\/td><td>usuario y operaci\u00f3n<\/td><td>dise\u00f1ador<\/td><\/tr><tr><td>naturaleza<\/td><td>objetivos y criterios del emprendimiento<\/td><td>necesidades funcionales y operacionales<\/td><td>respuesta t\u00e9cnica y justificaci\u00f3n<\/td><\/tr><tr><td>momento inicial<\/td><td>preproyecto<\/td><td>levantamiento de requisitos<\/td><td>dise\u00f1o conceptual<\/td><\/tr><tr><td>lenguaje dominante<\/td><td>desempe\u00f1o, riesgo y resultado<\/td><td>funci\u00f3n, uso e interfaz<\/td><td>ingenier\u00eda, arquitectura y c\u00e1lculo<\/td><\/tr><tr><td>autoridad de aprobaci\u00f3n<\/td><td>propietario<\/td><td>propietario y responsables funcionales<\/td><td>responsable t\u00e9cnico y propietario, seg\u00fan gobernanza<\/td><\/tr><tr><td>relaci\u00f3n con proveedores<\/td><td>orienta el alcance<\/td><td>informa funciones requeridas<\/td><td>fundamenta especificaciones y planos<\/td><\/tr><tr><td>relaci\u00f3n con pruebas<\/td><td>define lo que debe demostrarse<\/td><td>define comportamientos y usos<\/td><td>define c\u00f3mo debe responder la soluci\u00f3n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">El modelo documental puede variar. Algunas organizaciones adoptan un OPR \u00fanico con anexos de requisitos de usuarios. Otras mantienen URS separadas por disciplina o grupo funcional. Tambi\u00e9n pueden utilizar Employer\u2019s Requirements, Project Requirements, Design Criteria o Technical Requirements. El nombre es menos importante que la claridad de autor\u00eda, jerarqu\u00eda, aprobaci\u00f3n y trazabilidad.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Arquitectura documental recomendada<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una estructura pr\u00e1ctica para Data Centers puede organizarse en cinco niveles.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Objetivos y decisi\u00f3n de inversi\u00f3n:<\/strong> business case, estudio de viabilidad, requisitos estrat\u00e9gicos y l\u00edmites del emprendimiento.<\/li>\n\n\n\n<li><strong>Requisitos del propietario:<\/strong> OPR, pol\u00edticas, metas, criterios de riesgo, disponibilidad, seguridad, sostenibilidad y operaci\u00f3n.<\/li>\n\n\n\n<li><strong>Requisitos de usuarios y funciones:<\/strong> URS, flujos, capacidades, interfaces, datos, accesos, alarmas, informes y mantenimiento.<\/li>\n\n\n\n<li><strong>Respuesta de ingenier\u00eda:<\/strong> Basis of Design, criterios de dise\u00f1o, c\u00e1lculos, diagramas, layouts y matriz de interfaces.<\/li>\n\n\n\n<li><strong>Documentos contractuales y de verificaci\u00f3n:<\/strong> especificaciones, planos, RFP, submittals, FAT, SAT, pruebas integradas, as-built y documentaci\u00f3n operacional.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Esta arquitectura no exige cinco archivos aislados. Exige cinco capas de informaci\u00f3n identificables y gobernadas.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfCu\u00e1ndo elaborar cada documento?<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Fase<\/td><td>OPR<\/td><td>URS<\/td><td>Basis of Design<\/td><\/tr><tr><td>oportunidad y viabilidad<\/td><td>versi\u00f3n inicial con objetivos, capacidad, riesgos y criterios<\/td><td>necesidades preliminares de los grupos cr\u00edticos<\/td><td>solo conceptos o estudio de alternativas<\/td><\/tr><tr><td>selecci\u00f3n del site<\/td><td>actualiza requisitos externos, plazo y expansi\u00f3n<\/td><td>incluye acceso, operaci\u00f3n y conectividad<\/td><td>registra criterios utilizados en la comparaci\u00f3n<\/td><\/tr><tr><td>dise\u00f1o conceptual<\/td><td>baseline inicial aprobado<\/td><td>requisitos funcionales priorizados<\/td><td>arquitecturas y decisiones conceptuales<\/td><\/tr><tr><td>dise\u00f1o b\u00e1sico<\/td><td>revisi\u00f3n controlada<\/td><td>consolidaci\u00f3n para contrataci\u00f3n<\/td><td>configuraciones, capacidades, interfaces y desempe\u00f1o<\/td><\/tr><tr><td>dise\u00f1o ejecutivo<\/td><td>cambios solamente mediante control formal<\/td><td>detalle de funciones afectadas<\/td><td>c\u00e1lculos, equipos, secuencias y criterios finales<\/td><\/tr><tr><td>construcci\u00f3n<\/td><td>actualizaci\u00f3n por cambios aprobados<\/td><td>validaci\u00f3n de desviaciones funcionales<\/td><td>incorpora submittals y decisiones de campo<\/td><\/tr><tr><td>commissioning<\/td><td>referencia principal de verificaci\u00f3n<\/td><td>base de escenarios operacionales<\/td><td>referencia del comportamiento dise\u00f1ado<\/td><\/tr><tr><td>entrega y operaci\u00f3n<\/td><td>convertido en requisitos actuales de la instalaci\u00f3n<\/td><td>procedimientos y usos consolidados<\/td><td>baseline t\u00e9cnico y registro de decisiones<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Contenido m\u00ednimo de un OPR para Data Center<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objetivos del emprendimiento<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El documento debe explicar por qu\u00e9 existe el Data Center, qu\u00e9 servicios atiende, qu\u00e9 modelo operacional se adoptar\u00e1 y qu\u00e9 resultados justifican la inversi\u00f3n. Esto evita que las disciplinas desarrollen soluciones t\u00e9cnicamente correctas, pero desalineadas con el prop\u00f3sito.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Capacidad y crecimiento<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Deben registrarse carga de TIC inicial y final, densidades, cantidad de racks, ocupaci\u00f3n, horizonte, bloques de expansi\u00f3n y gatillos. El requisito debe diferenciar capacidad nominal, capacidad disponible y capacidad efectivamente utilizable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Disponibilidad y continuidad<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El OPR debe definir tolerancia a interrupciones, necesidad de mantenimiento concurrente, modos degradados aceptables, recuperaci\u00f3n y dependencias entre infraestructura f\u00edsica y arquitectura de aplicaciones. Una clasificaci\u00f3n Tier o Rated no sustituye la definici\u00f3n de los servicios y riesgos del propietario.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Operaci\u00f3n y mantenimiento<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Deben considerarse equipo, cobertura, capacitaci\u00f3n, stock, asistencia, accesos, ventanas, procedimientos, capacidad de maniobra y filosof\u00eda de mantenimiento. Una soluci\u00f3n con alta redundancia puede ser inadecuada cuando su complejidad excede la capacidad operacional.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Seguridad y compliance<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El propietario debe indicar clasificaci\u00f3n de \u00e1reas, perfiles de acceso, registros, retenci\u00f3n, investigaci\u00f3n, privacidad, segregaci\u00f3n, auditor\u00eda y requisitos regulatorios aplicables.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Eficiencia y sostenibilidad<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Las metas de energ\u00eda, agua, emisiones, medici\u00f3n, informes y condiciones de carga deben tener fronteras claras. Un valor de PUE sin condici\u00f3n de utilizaci\u00f3n, clima y l\u00edmite de medici\u00f3n no es un requisito verificable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Expansi\u00f3n, flexibilidad y ciclo de vida<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El OPR debe declarar qu\u00e9 interfaces deben prepararse, qu\u00e9 activos pueden anticiparse, c\u00f3mo se construir\u00e1n las nuevas fases y qu\u00e9 tecnolog\u00edas deben permanecer sustituibles.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Commissioning y aceptaci\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El documento debe establecer alcance de sistemas, niveles de prueba, participaci\u00f3n de proveedores, disponibilidad de cargas, evidencias, criterios, capacitaci\u00f3n y documentaci\u00f3n necesaria para la aceptaci\u00f3n.<\/p>\n\n\n\n<div class=\"wp-block-a3a-destaque\">\n<p class=\"wp-block-paragraph\"><strong>Transforme requisitos aprobados en una arquitectura multidisciplinaria coordinada y verificable.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A3A Engenharia desarrolla dise\u00f1os conceptuales, b\u00e1sicos y ejecutivos preservando OPR, Basis of Design, interfaces, criterios de desempe\u00f1o y requisitos de aceptaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"\/servicos\/planejamento\/projeto-de-data-center\/\"><strong>Conozca el servicio de Dise\u00f1o de Data Center<\/strong><\/a><\/p>\n<\/div>\n\n\n\n\n<h2 class=\"wp-block-heading\">Contenido de una URS para Data Center<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La URS debe transformar necesidades en declaraciones funcionales. Puede organizarse por usuarios, \u00e1reas o sistemas, pero debe evitar duplicidades y conflictos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Capacidad e implantaci\u00f3n de TIC<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Los ejemplos incluyen dimensiones y masas de equipos, potencia por rack, alimentaci\u00f3n A\/B, conectores, posiciones, ocupaci\u00f3n, flujo de implantaci\u00f3n, staging, muelles, ascensores y rutas de movimiento.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Redes e interconexi\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Deben definirse cantidad y diversidad de entradas, carriers, MMRs, backbone, fibras, cableado, patching, identificaci\u00f3n, latencia, capacidad, crecimiento y requisitos de certificaci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Operaci\u00f3n y supervisi\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">La URS puede especificar alarmas, prioridades, puntos, dashboards, hist\u00f3ricos, informes, integraciones, sincronizaci\u00f3n de tiempo, acceso remoto, out-of-band y comportamiento durante p\u00e9rdida de comunicaci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Seguridad f\u00edsica<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Incluye recorridos de acceso, visitantes, contratistas, doble custodia, \u00e1reas cr\u00edticas, videovigilancia, retenci\u00f3n, investigaci\u00f3n, credenciales, biometr\u00eda, interbloqueos y contingencia.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Mantenimiento<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Deben registrarse accesos, espacios, izado, sustituci\u00f3n, aislamiento, drenaje, iluminaci\u00f3n, tomas, puntos de prueba, herramientas, repuestos y restricciones de trabajo en \u00e1reas activas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Documentaci\u00f3n y capacitaci\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">La URS puede definir formatos, idioma, codificaci\u00f3n, modelos, as-built, listas de activos, manuales, videos, simuladores, capacitaci\u00f3n, evaluaci\u00f3n de competencia y actualizaci\u00f3n posterior a cambios.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">C\u00f3mo redactar requisitos verificables<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Un requisito de calidad debe ser necesario, claro, singular, viable, trazable y verificable. ISO\/IEC\/IEEE 29148 proporciona fundamentos generales de ingenier\u00eda de requisitos que pueden adaptarse al emprendimiento.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Estructura recomendada<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Campo<\/td><td>Funci\u00f3n<\/td><\/tr><tr><td>ID<\/td><td>identificaci\u00f3n \u00fanica y estable<\/td><\/tr><tr><td>declaraci\u00f3n<\/td><td>requisito en lenguaje objetivo<\/td><\/tr><tr><td>origen<\/td><td>propietario, usuario, norma, riesgo o decisi\u00f3n<\/td><\/tr><tr><td>justificaci\u00f3n<\/td><td>motivo y consecuencia<\/td><\/tr><tr><td>prioridad<\/td><td>obligatorio, deseable u opcional<\/td><\/tr><tr><td>responsable<\/td><td>qui\u00e9n decide y mantiene<\/td><\/tr><tr><td>m\u00e9todo de verificaci\u00f3n<\/td><td>an\u00e1lisis, inspecci\u00f3n, demostraci\u00f3n o prueba<\/td><\/tr><tr><td>fase de verificaci\u00f3n<\/td><td>dise\u00f1o, FAT, SAT, IST u operaci\u00f3n<\/td><\/tr><tr><td>evidencia<\/td><td>documento, informe, registro o medici\u00f3n<\/td><\/tr><tr><td>estado<\/td><td>propuesto, aprobado, modificado, atendido o pendiente<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Lenguaje de obligaci\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Los requisitos contractuales deben utilizar lenguaje consistente. Una formulaci\u00f3n com\u00fan utiliza \u201cdebe\u201d para obligaci\u00f3n y evita expresiones vagas como \u201ccuando sea posible\u201d, \u201cadecuado\u201d, \u201cpreferentemente\u201d o \u201calta calidad\u201d sin criterio.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>D\u00e9bil:<\/strong> el sistema de climatizaci\u00f3n debe ser altamente confiable.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Mejor:<\/strong> la p\u00e9rdida de una unidad de climatizaci\u00f3n del bloque no debe elevar la temperatura de entrada de los equipos de TIC por encima del l\u00edmite aprobado durante la condici\u00f3n de dise\u00f1o y por el per\u00edodo definido para respuesta operacional.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La formulaci\u00f3n todav\u00eda debe indicar l\u00edmite, condici\u00f3n de carga, ambiente, duraci\u00f3n, m\u00e9todo de medici\u00f3n y evidencia.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Matriz de trazabilidad de requisitos<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La matriz conecta cada requisito con decisiones, documentos y verificaciones. No necesita ser una hoja de c\u00e1lculo aislada; puede existir en una plataforma de requisitos o entorno com\u00fan de datos. Lo esencial es mantener relaciones auditables.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Requisito<\/td><td>Origen<\/td><td>BoD<\/td><td>Documento de dise\u00f1o<\/td><td>Suministro<\/td><td>Verificaci\u00f3n<\/td><td>Estado<\/td><\/tr><tr><td>OPR-AV-001<\/td><td>continuidad del negocio<\/td><td>BOD-EL-03<\/td><td>unifilar y especificaci\u00f3n el\u00e9ctrica<\/td><td>UPS, tableros y controles<\/td><td>FAT, SAT e IST<\/td><td>aprobado<\/td><\/tr><tr><td>URS-OPS-014<\/td><td>operaci\u00f3n<\/td><td>BOD-AUT-08<\/td><td>lista de puntos y causa-efecto<\/td><td>BMS\/EPMS<\/td><td>demostraci\u00f3n y prueba<\/td><td>en revisi\u00f3n<\/td><\/tr><tr><td>OPR-SEC-006<\/td><td>pol\u00edtica de seguridad<\/td><td>BOD-SEG-02<\/td><td>arquitectura de zonas<\/td><td>acceso y videovigilancia<\/td><td>inspecci\u00f3n y escenario<\/td><td>aprobado<\/td><\/tr><tr><td>URS-MAN-021<\/td><td>mantenimiento<\/td><td>BOD-MEC-12<\/td><td>layout y detalles<\/td><td>equipos HVAC<\/td><td>inspecci\u00f3n de acceso<\/td><td>pendiente<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cobertura y brechas<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Indicadores simples ayudan a la gobernanza:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>requisitos sin respuesta en el BoD;<\/li><li>decisiones de dise\u00f1o sin requisito de origen;<\/li><li>requisitos sin m\u00e9todo de verificaci\u00f3n;<\/li><li>pruebas sin requisito asociado;<\/li><li>cambios sin an\u00e1lisis de impacto;<\/li><li>requisitos aprobados todav\u00eda sin evidencia de cumplimiento.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">La cantidad de v\u00ednculos no sustituye la revisi\u00f3n t\u00e9cnica. Una relaci\u00f3n puede existir y aun ser inadecuada.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Ejemplo de cadena completa de requisito<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Considere la necesidad de mantenimiento de la alimentaci\u00f3n el\u00e9ctrica sin desconectar las cargas cr\u00edticas.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Objetivo del propietario:<\/strong> los servicios cr\u00edticos deben permanecer disponibles durante el mantenimiento planificado de la infraestructura el\u00e9ctrica.<\/li>\n\n\n\n<li><strong>OPR:<\/strong> cada bloque debe permitir la retirada planificada de los componentes definidos sin interrupci\u00f3n de las cargas clasificadas como cr\u00edticas, dentro de las condiciones y excepciones aprobadas.<\/li>\n\n\n\n<li><strong>URS de operaci\u00f3n:<\/strong> el equipo debe realizar aislamiento, transferencia, bloqueo, prueba y retorno mediante procedimientos controlados, con estados visibles en el EPMS.<\/li>\n\n\n\n<li><strong>Basis of Design:<\/strong> la soluci\u00f3n utiliza caminos A\/B, dispositivos de aislamiento, bypass, l\u00f3gica de transferencia y medici\u00f3n seg\u00fan los modos analizados.<\/li>\n\n\n\n<li><strong>Dise\u00f1o:<\/strong> unifilares, interbloqueos, lista de se\u00f1ales, especificaciones, selectividad, layouts y rutas detallan la soluci\u00f3n.<\/li>\n\n\n\n<li><strong>Verificaci\u00f3n:<\/strong> revisi\u00f3n de dise\u00f1o, FAT de controles, SAT, prueba de transferencia e IST demuestran los escenarios aprobados.<\/li>\n\n\n\n<li><strong>Operaci\u00f3n:<\/strong> MOP, SOP y capacitaci\u00f3n consolidan el procedimiento y las restricciones conocidas.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Sin esta cadena, la frase \u201cmantenimiento concurrente\u201d puede ser interpretada de formas diferentes por propietario, dise\u00f1ador, fabricante, instalador y operador.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">C\u00f3mo elaborar el Basis of Design<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Premisas y l\u00edmites<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El documento debe comenzar con alcance, referencias, condiciones de dise\u00f1o, datos recibidos, premisas, exclusiones y responsabilidades. Cada premisa relevante necesita origen y estado. Una informaci\u00f3n todav\u00eda no confirmada no debe desaparecer dentro de un c\u00e1lculo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Criterios de capacidad<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El BoD registra modelos de carga, factores, m\u00e1rgenes, simultaneidad, crecimiento, derating, reservas y capacidad utilizable. Debe explicar c\u00f3mo la carga de TIC se transforma en demanda el\u00e9ctrica, carga t\u00e9rmica, agua, espacio, peso y telecomunicaciones.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Arquitectura y redundancia<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Las topolog\u00edas deben justificarse mediante requisitos y an\u00e1lisis de riesgo. El documento debe identificar componentes redundantes, compartidos, modos comunes, estados degradados, recuperaci\u00f3n y limitaciones.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Selecci\u00f3n de tecnolog\u00edas<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">La decisi\u00f3n entre agua helada, expansi\u00f3n directa, InRow, refrigeraci\u00f3n l\u00edquida, bater\u00edas de plomo-\u00e1cido o litio, UPS centralizada o distribuida y otras alternativas debe registrar criterios t\u00e9cnicos y operacionales, no solamente marcas o preferencias.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Secuencias e interbloqueos<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El BoD debe describir el comportamiento esperado durante arranque, parada, falla, transferencia, emergencia, mantenimiento y retorno. Las secuencias deben ser coherentes entre el\u00e9ctrica, mec\u00e1nica, automatizaci\u00f3n, incendios y seguridad.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Mantenibilidad y sustituci\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Deben considerarse aislamiento, acceso, desmontaje, izado, drenaje, repuestos, herramientas, iluminaci\u00f3n, seguridad e impacto sobre otros sistemas. El espacio geom\u00e9trico sin un procedimiento viable no representa mantenibilidad.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Expansi\u00f3n y estados temporales<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El documento debe registrar condici\u00f3n inicial, fases, capacidad final, interfaces preparadas y estados transitorios. La arquitectura final puede ser resiliente mientras una etapa intermedia posee vulnerabilidades diferentes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Testabilidad<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Deben preverse puntos de medici\u00f3n, cargas, simulaciones, modos de prueba, bypass, conexiones temporales y seguridad de los ensayos. Un requisito no verificable en campo necesita otro m\u00e9todo de evidencia aprobado.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Relaci\u00f3n con normas y referencias t\u00e9cnicas<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La serie <a href=\"https:\/\/www.iso.org\/standard\/78550.html\">ISO\/IEC 22237<\/a> organiza principios, clasificaciones y requisitos de infraestructura de Data Centers. La <a href=\"https:\/\/tiaonline.org\/resource\/tia-942-c-data-center-infrastructure-standard\/\">ANSI\/TIA-942-C<\/a> abarca arquitectura, telecomunicaciones, energ\u00eda, climatizaci\u00f3n, seguridad y dem\u00e1s sistemas para instalaciones de diferentes tipos y tama\u00f1os.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Estas referencias no escriben el OPR del propietario. Ofrecen requisitos, clasificaciones y buenas pr\u00e1cticas que deben seleccionarse seg\u00fan riesgos, legislaci\u00f3n y finalidad del emprendimiento. Adoptar una norma no elimina la necesidad de declarar edici\u00f3n, alcance, excepciones y criterios espec\u00edficos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El art\u00edculo sobre <a href=\"\/conteudo\/artigos-tecnicos\/data-center-tier-3\/\">Tier I, II, III y IV en Data Centers<\/a> explica por qu\u00e9 clasificaci\u00f3n, redundancia y disponibilidad del servicio no deben confundirse.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Relaci\u00f3n con dise\u00f1o conceptual, b\u00e1sico y ejecutivo<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El art\u00edculo <a href=\"\/conteudo\/artigos-tecnicos\/como-projetar-data-center\/\">C\u00f3mo dise\u00f1ar un Data Center: etapas, disciplinas y entregables<\/a> presenta el proceso multidisciplinario completo. Dentro de \u00e9l, los documentos de requisitos y el BoD asumen funciones diferentes en cada fase.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Fase<\/td><td>Funci\u00f3n de los requisitos<\/td><td>Funci\u00f3n del BoD<\/td><\/tr><tr><td>conceptual<\/td><td>seleccionar objetivos, prioridades y restricciones<\/td><td>comparar alternativas y fijar principios<\/td><\/tr><tr><td>b\u00e1sico<\/td><td>consolidar criterios para contrataci\u00f3n<\/td><td>definir configuraciones, desempe\u00f1o e interfaces<\/td><\/tr><tr><td>ejecutivo<\/td><td>controlar cambios y detalles afectados<\/td><td>registrar c\u00e1lculos, elecciones y comportamiento final<\/td><\/tr><tr><td>construcci\u00f3n<\/td><td>evaluar desv\u00edos y propuestas<\/td><td>incorporar submittals y decisiones aprobadas<\/td><\/tr><tr><td>commissioning<\/td><td>definir lo que debe demostrarse<\/td><td>explicar c\u00f3mo deber\u00eda funcionar la soluci\u00f3n<\/td><\/tr><tr><td>operaci\u00f3n<\/td><td>preservar intenci\u00f3n y l\u00edmites<\/td><td>formar baseline t\u00e9cnico para cambios futuros<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Un dise\u00f1o ejecutivo detallado no compensa requisitos inadecuados. Solo detalla con mayor precisi\u00f3n una soluci\u00f3n que puede estar equivocada.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">OPR, URS y BoD en la RFP y la contrataci\u00f3n<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una RFP consistente debe declarar qu\u00e9 requisitos son obligatorios, cu\u00e1les permiten alternativas y c\u00f3mo se presentar\u00e1n los desv\u00edos. El proveedor no debe tener que inferir objetivos del propietario a partir de planos incompletos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Jerarqu\u00eda contractual<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">La documentaci\u00f3n debe establecer precedencia entre OPR, especificaciones, planos, listas, normas y propuestas. El OPR puede orientar la intenci\u00f3n sin necesariamente incorporarse \u00edntegramente como documento contractual. La organizaci\u00f3n debe evitar conflictos en los que un requisito de alto nivel contradiga una obligaci\u00f3n detallada sin mecanismo de resoluci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Matriz de conformidad<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Cada proponente puede estar obligado a responder:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Respuesta<\/td><td>Significado<\/td><\/tr><tr><td>cumple<\/td><td>la soluci\u00f3n cumple \u00edntegramente el requisito<\/td><\/tr><tr><td>cumple con aclaraci\u00f3n<\/td><td>cumple, pero exige una interpretaci\u00f3n registrada<\/td><\/tr><tr><td>alternativa<\/td><td>ofrece una soluci\u00f3n diferente con impacto demostrado<\/td><\/tr><tr><td>desv\u00edo<\/td><td>no cumple y solicita aceptaci\u00f3n formal<\/td><\/tr><tr><td>no aplicable<\/td><td>el requisito no pertenece al alcance, con justificaci\u00f3n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">El silencio no debe interpretarse autom\u00e1ticamente como conformidad.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Desv\u00edos t\u00e9cnicos<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El desv\u00edo debe indicar requisito afectado, soluci\u00f3n propuesta, motivo, impacto en capacidad, disponibilidad, operaci\u00f3n, mantenimiento, plazo, costo, pruebas y documentaci\u00f3n. La aprobaci\u00f3n debe actualizar trazabilidad y BoD.<\/p>\n\n\n\n<div class=\"wp-block-a3a-destaque\">\n<p class=\"wp-block-paragraph\"><strong>Mantenga requisitos, decisiones, desv\u00edos y cambios trazables durante contrataci\u00f3n e implantaci\u00f3n.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Owner\u2019s Engineering representa los intereses del propietario en la revisi\u00f3n de dise\u00f1os, propuestas, submittals, interfaces, cambios y evidencias de cumplimiento.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"\/servicos\/contratacao-integrada\/owners-engineering-para-data-centers\/\"><strong>Conozca Owner\u2019s Engineering para Data Centers<\/strong><\/a><\/p>\n<\/div>\n\n\n\n\n<h2 class=\"wp-block-heading\">Gobernanza de cambios<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Los cambios son inevitables; los cambios sin trazabilidad no. Un proceso m\u00ednimo incluye:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>identificaci\u00f3n del cambio y de los requisitos afectados;<\/li>\n\n\n\n<li>justificaci\u00f3n y alternativas;<\/li>\n\n\n\n<li>an\u00e1lisis multidisciplinario de impacto;<\/li>\n\n\n\n<li>evaluaci\u00f3n de costo, plazo, riesgo, operaci\u00f3n y pruebas;<\/li>\n\n\n\n<li>decisi\u00f3n por una autoridad definida;<\/li>\n\n\n\n<li>actualizaci\u00f3n de OPR, URS, BoD y documentos asociados;<\/li>\n\n\n\n<li>comunicaci\u00f3n a las partes y revisi\u00f3n de la matriz de trazabilidad;<\/li>\n\n\n\n<li>verificaci\u00f3n de la implantaci\u00f3n y cierre del cambio.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">La decisi\u00f3n debe preservar el historial. Sustituir silenciosamente una premisa borra la raz\u00f3n por la cual se tomaron decisiones anteriores.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Baselines y gates<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">En cada gate, versiones espec\u00edficas 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\u00f3n leg\u00edtima del scope creep.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Revisi\u00f3n de calidad del OPR<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de la aprobaci\u00f3n, el OPR debe verificarse en cuanto a:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Criterio<\/td><td>Pregunta de revisi\u00f3n<\/td><\/tr><tr><td>completitud<\/td><td>\u00bfest\u00e1n cubiertos objetivos, capacidad, operaci\u00f3n, seguridad, expansi\u00f3n y aceptaci\u00f3n?<\/td><\/tr><tr><td>claridad<\/td><td>\u00bflos t\u00e9rminos vagos tienen definici\u00f3n y l\u00edmite?<\/td><\/tr><tr><td>consistencia<\/td><td>\u00bflos requisitos se contradicen?<\/td><\/tr><tr><td>viabilidad<\/td><td>\u00bfplazo, tecnolog\u00eda, presupuesto y operaci\u00f3n son compatibles?<\/td><\/tr><tr><td>prioridad<\/td><td>\u00bflos conflictos poseen regla de decisi\u00f3n?<\/td><\/tr><tr><td>verificabilidad<\/td><td>\u00bfexisten m\u00e9todo y evidencia posibles?<\/td><\/tr><tr><td>trazabilidad<\/td><td>\u00bforigen, responsable y versi\u00f3n est\u00e1n registrados?<\/td><\/tr><tr><td>aplicabilidad<\/td><td>\u00bflas normas y requisitos externos est\u00e1n correctamente seleccionados?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">La revisi\u00f3n debe involucrar propietarios funcionales, no solamente al equipo de ingenier\u00eda.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Revisi\u00f3n de calidad de la URS<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La URS debe probarse contra jornadas y escenarios reales. Los workshops pueden utilizar flujos como implantaci\u00f3n de un nuevo rack, mantenimiento de UPS, entrada de contratistas, respuesta a fugas, p\u00e9rdida de comunicaci\u00f3n, falla de sensor, investigaci\u00f3n de acceso y expansi\u00f3n de capacidad.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Este enfoque revela requisitos que las listas gen\u00e9ricas no capturan: tiempo de respuesta, permisos, visualizaci\u00f3n, espacio, secuencia, datos, documentaci\u00f3n y responsabilidades.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Revisi\u00f3n de calidad del Basis of Design<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El BoD debe revisarse por disciplina y por interfaz. Una revisi\u00f3n adecuada confronta requisitos, diagramas, c\u00e1lculos, layouts, secuencias y m\u00e9todos de prueba.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Preguntas cr\u00edticas<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li>\u00bfCada arquitectura responde a requisitos aprobados?<\/li><li>\u00bfLas capacidades utilizan premisas consistentes entre disciplinas?<\/li><li>\u00bfSe identificaron modos comunes y estados degradados?<\/li><li>\u00bfEl mantenimiento puede ejecutarse con seguridad?<\/li><li>\u00bfLos equipos pueden sustituirse?<\/li><li>\u00bfLas fases temporales est\u00e1n representadas?<\/li><li>\u00bfLas secuencias de control son coherentes?<\/li><li>\u00bfEl dise\u00f1o posee puntos y condiciones de prueba?<\/li><li>\u00bfLas excepciones y riesgos residuales est\u00e1n expl\u00edcitos?<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Una revisi\u00f3n de clash detection no responde a estas preguntas.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Integraci\u00f3n con BIM y entorno com\u00fan de datos<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">BIM puede asociar requisitos a espacios, sistemas y activos, pero no sustituye la gobernanza. El entorno com\u00fan de datos debe controlar c\u00f3digos, versiones, estados, aprobaciones, comentarios y transmittals.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una estructura posible relaciona:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>requisito con sistema y espacio;<\/li><li>objeto BIM con especificaci\u00f3n y submittal;<\/li><li>activo con prueba e informe;<\/li><li>cambio con documentos afectados;<\/li><li>pendiente con responsable y gate;<\/li><li>as-built con registro operacional.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Los v\u00ednculos deben sobrevivir a la exportaci\u00f3n, entrega y operaci\u00f3n. Una plataforma sin plan de datos puede concentrar informaci\u00f3n que se pierde en el handover.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Integraci\u00f3n con commissioning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El commissioning no debe comenzar con la redacci\u00f3n de pruebas al final de la obra. La <a href=\"https:\/\/www.ashrae.org\/technical-resources\/bookstore\/commissioning\">ASHRAE\/IES Standard 202<\/a> describe un proceso integrado para entregar instalaciones que atiendan el OPR.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Revisi\u00f3n de dise\u00f1o<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">La autoridad de commissioning verifica si el BoD y los documentos responden a los requisitos, identificando brechas de testabilidad, operaci\u00f3n, medici\u00f3n, acceso y secuencia.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Submittals y FAT<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Las propuestas y planos de fabricantes se eval\u00faan frente a especificaciones y requisitos. Los FAT pueden verificar funciones, controles, alarmas y desempe\u00f1o antes del env\u00edo, reduciendo descubrimientos en el site.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">SAT y pruebas funcionales<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">En campo, inspecciones y pruebas confirman instalaci\u00f3n, configuraci\u00f3n y comportamiento de sistemas individuales. Cada procedimiento debe indicar requisitos, precondiciones, instrumentos, pasos, criterios y evidencias.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pruebas integradas de sistemas<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Los IST demuestran interacciones durante fallas y transiciones: p\u00e9rdida de red, arranque de generadores, transferencia de UPS, falla de climatizaci\u00f3n, incendio, p\u00e9rdida de comunicaci\u00f3n, mantenimiento y retorno a la condici\u00f3n normal.<\/p>\n\n\n\n<div class=\"wp-block-a3a-destaque\">\n<p class=\"wp-block-paragraph\"><strong>Defina los criterios de verificaci\u00f3n antes de la compra, la instalaci\u00f3n y las pruebas.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El commissioning conecta OPR, Basis of Design, especificaciones, FAT, SAT, pruebas funcionales y pruebas integradas para producir evidencias objetivas de cumplimiento.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"\/servicos\/servicos-complementares\/comissionamento-aceite-data-centers\/\"><strong>Conozca Commissioning y Aceptaci\u00f3n de Data Centers<\/strong><\/a><\/p>\n<\/div>\n\n\n\n\n<h2 class=\"wp-block-heading\">Entrega a operaci\u00f3n<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Al final, los requisitos y el BoD deben reconciliarse con la instalaci\u00f3n construida. La documentaci\u00f3n de operaci\u00f3n debe reflejar desv\u00edos aprobados, limitaciones, configuraciones y evidencias.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Current Facility Requirements<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">En el proceso de commissioning, los requisitos de la instalaci\u00f3n existente pueden consolidarse como Current Facility Requirements. Para Data Centers, esta l\u00f3gica ayuda a mantener una referencia actualizada despu\u00e9s de cambios, expansiones y modernizaciones.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Baseline operacional<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">El handover debe conectar:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>requisitos vigentes;<\/li><li>BoD final;<\/li><li>as-built y diagramas;<\/li><li>listas de activos y configuraciones;<\/li><li>pruebas y pendientes;<\/li><li>MOPs, SOPs y EOPs;<\/li><li>capacitaci\u00f3n y competencia;<\/li><li>l\u00edmites operacionales;<\/li><li>plan de mantenimiento;<\/li><li>matriz de alarmas y escalamiento.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Sin esta reconciliaci\u00f3n, la operaci\u00f3n recibe documentos hist\u00f3ricos que no representan la instalaci\u00f3n real.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Ejemplo de estructura de OPR<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Secci\u00f3n<\/td><td>Contenido<\/td><\/tr><tr><td>1. gobernanza<\/td><td>prop\u00f3sito, alcance, autoridades, aprobaciones y control de cambios<\/td><\/tr><tr><td>2. contexto<\/td><td>negocio, usuarios, servicios y modelo operacional<\/td><\/tr><tr><td>3. capacidad<\/td><td>TIC, racks, densidad, crecimiento y fases<\/td><\/tr><tr><td>4. disponibilidad<\/td><td>criticidad, mantenimiento, fallas y recuperaci\u00f3n<\/td><\/tr><tr><td>5. implantaci\u00f3n<\/td><td>site, edificios, expansi\u00f3n, accesos y log\u00edstica<\/td><\/tr><tr><td>6. infraestructura<\/td><td>energ\u00eda, t\u00e9rmica, telecom, automatizaci\u00f3n y utilities<\/td><\/tr><tr><td>7. seguridad<\/td><td>f\u00edsica, cibern\u00e9tica, incendios y compliance<\/td><\/tr><tr><td>8. operaci\u00f3n<\/td><td>equipo, procedimientos, mantenimiento, repuestos y soporte<\/td><\/tr><tr><td>9. sostenibilidad<\/td><td>energ\u00eda, agua, emisiones, medici\u00f3n e informes<\/td><\/tr><tr><td>10. calidad y pruebas<\/td><td>revisiones, FAT, SAT, IST y evidencias<\/td><\/tr><tr><td>11. documentaci\u00f3n<\/td><td>formatos, codificaci\u00f3n, BIM, as-built y handover<\/td><\/tr><tr><td>12. riesgos y excepciones<\/td><td>condicionantes, riesgos aceptados y decisiones pendientes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\n<h2 class=\"wp-block-heading\">Ejemplo de estructura de Basis of Design<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Secci\u00f3n<\/td><td>Contenido<\/td><\/tr><tr><td>1. alcance y referencias<\/td><td>l\u00edmites, normas, documentos de entrada e interfaces<\/td><\/tr><tr><td>2. premisas<\/td><td>datos, condiciones de dise\u00f1o, m\u00e1rgenes y pendientes<\/td><\/tr><tr><td>3. criterios generales<\/td><td>capacidad, disponibilidad, seguridad y eficiencia<\/td><\/tr><tr><td>4. arquitectura<\/td><td>implantaci\u00f3n, bloques, redundancia y expansi\u00f3n<\/td><\/tr><tr><td>5. disciplinas<\/td><td>bases el\u00e9ctricas, mec\u00e1nicas, telecom, automatizaci\u00f3n y seguridad<\/td><\/tr><tr><td>6. modos de operaci\u00f3n<\/td><td>normal, mantenimiento, falla, emergencia y retorno<\/td><\/tr><tr><td>7. c\u00e1lculos y selecciones<\/td><td>modelos, factores, derating y alternativas<\/td><\/tr><tr><td>8. coordinaci\u00f3n<\/td><td>espacios, rutas, cargas, interfaces y responsabilidades<\/td><\/tr><tr><td>9. testabilidad<\/td><td>puntos, cargas, procedimientos y criterios<\/td><\/tr><tr><td>10. riesgos y excepciones<\/td><td>limitaciones, desv\u00edos y riesgo residual<\/td><\/tr><tr><td>11. cambios<\/td><td>decisiones, revisiones e impactos<\/td><\/tr><tr><td>12. anexos<\/td><td>diagramas, matrices, tablas y registros<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Errores comunes<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Error<\/td><td>Consecuencia<\/td><\/tr><tr><td>copiar el OPR de otro emprendimiento<\/td><td>requisitos incompatibles con el negocio y la operaci\u00f3n<\/td><\/tr><tr><td>usar t\u00e9rminos vagos<\/td><td>proveedores y dise\u00f1adores adoptan interpretaciones diferentes<\/td><\/tr><tr><td>confundir requisito y soluci\u00f3n<\/td><td>bloqueo tecnol\u00f3gico y competencia limitada<\/td><\/tr><tr><td>dejar usuarios fuera del proceso<\/td><td>operaci\u00f3n recibe una instalaci\u00f3n dif\u00edcil de usar y mantener<\/td><\/tr><tr><td>producir el BoD despu\u00e9s de los planos<\/td><td>el documento se convierte en justificaci\u00f3n retrospectiva<\/td><\/tr><tr><td>no registrar premisas<\/td><td>los c\u00e1lculos parecen precisos sobre datos inciertos<\/td><\/tr><tr><td>no definir m\u00e9todos de verificaci\u00f3n<\/td><td>los requisitos no pueden aceptarse objetivamente<\/td><\/tr><tr><td>no controlar cambios<\/td><td>dise\u00f1o, contrato y pruebas utilizan versiones diferentes<\/td><\/tr><tr><td>tratar una norma como OPR<\/td><td>los objetivos espec\u00edficos del propietario quedan ausentes<\/td><\/tr><tr><td>desconectar el commissioning<\/td><td>las pruebas se improvisan al final de la obra<\/td><\/tr><tr><td>no reconciliar as-built y BoD<\/td><td>el baseline operacional no representa la instalaci\u00f3n<\/td><\/tr><tr><td>crear documentos excesivos sin jerarqu\u00eda<\/td><td>la duplicidad y el conflicto aumentan en lugar de reducirse<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\n<h2 class=\"wp-block-heading\">Checklist de gobernanza documental<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\u00bfEst\u00e1n definidos el objetivo y el modelo de operaci\u00f3n del Data Center?<\/li>\n\n\n\n<li>\u00bfExiste autoridad formal para aprobar requisitos y cambios?<\/li>\n\n\n\n<li>\u00bfEl OPR diferencia objetivos, requisitos y preferencias?<\/li>\n\n\n\n<li>\u00bfParticiparon usuarios de TI, operaci\u00f3n, seguridad y facilities?<\/li>\n\n\n\n<li>\u00bfLos requisitos poseen IDs, origen, prioridad y responsable?<\/li>\n\n\n\n<li>\u00bfLos criterios vagos se transformaron en condiciones medibles?<\/li>\n\n\n\n<li>\u00bfCada requisito posee m\u00e9todo y fase de verificaci\u00f3n?<\/li>\n\n\n\n<li>\u00bfEl BoD registra premisas y datos todav\u00eda pendientes?<\/li>\n\n\n\n<li>\u00bfLas elecciones de arquitectura poseen justificaci\u00f3n vinculada a requisitos?<\/li>\n\n\n\n<li>\u00bfLas capacidades y m\u00e1rgenes son consistentes entre disciplinas?<\/li>\n\n\n\n<li>\u00bfEst\u00e1n descritos los modos normal, mantenimiento, falla y emergencia?<\/li>\n\n\n\n<li>\u00bfSe consideraron expansiones y estados temporales?<\/li>\n\n\n\n<li>\u00bfLa matriz conecta requisitos, documentos, suministros y pruebas?<\/li>\n\n\n\n<li>\u00bfLa RFP exige conformidad y declaraci\u00f3n de desv\u00edos?<\/li>\n\n\n\n<li>\u00bfLos submittals se revisan frente a requisitos y BoD?<\/li>\n\n\n\n<li>\u00bfLos cambios actualizan todos los documentos afectados?<\/li>\n\n\n\n<li>\u00bfFAT, SAT e IST citan requisitos verificables?<\/li>\n\n\n\n<li>\u00bfLos pendientes poseen responsable, plazo e impacto en la aceptaci\u00f3n?<\/li>\n\n\n\n<li>\u00bfEl as-built fue reconciliado con el BoD final?<\/li>\n\n\n\n<li>\u00bfLa operaci\u00f3n recibi\u00f3 baseline, procedimientos y l\u00edmites actualizados?<\/li>\n<\/ol>\n\n\n\n\n<h2 class=\"wp-block-heading\">Alcance de Ingenier\u00eda Consultiva de A3A Engenharia<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A3A Engenharia apoya a propietarios y operadores en la estructuraci\u00f3n de requisitos y bases de dise\u00f1o para nuevos Data Centers, expansiones, modernizaciones, entornos Edge, instalaciones corporativas, colocation y soluciones modulares.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El alcance puede incluir workshops con stakeholders, levantamiento de necesidades, elaboraci\u00f3n o revisi\u00f3n de OPR y URS, desarrollo del Basis of Design, matriz de trazabilidad, criterios de contrataci\u00f3n, revisi\u00f3n multidisciplinaria, gesti\u00f3n de interfaces, requisitos de commissioning y reconciliaci\u00f3n de la documentaci\u00f3n final.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La actuaci\u00f3n puede integrar el <a href=\"\/servicos\/planejamento\/estudo-de-viabilidade-de-data-center\/\">Estudio de Viabilidad de Data Center<\/a>, el <a href=\"\/servicos\/planejamento\/projeto-de-data-center\/\">Dise\u00f1o de Data Center<\/a>, <a href=\"\/servicos\/contratacao-integrada\/owners-engineering-para-data-centers\/\">Owner\u2019s Engineering para Data Centers<\/a> y <a href=\"\/servicos\/servicos-complementares\/comissionamento-aceite-data-centers\/\">Commissioning y Aceptaci\u00f3n de Data Centers<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Resumen t\u00e9cnico<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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\u00f3mo la ingenier\u00eda responde a esos requisitos mediante premisas, criterios, arquitecturas, c\u00e1lculos y decisiones.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La calidad depende menos del nombre de los archivos y m\u00e1s de la gobernanza: autor\u00eda, aprobaci\u00f3n, jerarqu\u00eda, identificaci\u00f3n, verificabilidad, trazabilidad y control de cambios. Los requisitos deben orientar dise\u00f1o, contrataci\u00f3n y pruebas; el BoD debe explicar las elecciones; y el commissioning debe producir evidencias de cumplimiento.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando esta cadena se mantiene hasta el as-built y la operaci\u00f3n, el emprendimiento preserva su intenci\u00f3n t\u00e9cnica. Cuando se rompe, el proyecto tiende a acumular decisiones impl\u00edcitas, desv\u00edos no evaluados y criterios de aceptaci\u00f3n definidos demasiado tarde.<\/p>\n\n\n\n<details class=\"wp-block-details is-layout-flow wp-block-details-is-layout-flow\"><summary>Referencias t\u00e9cnicas<\/summary>\n<p class=\"wp-block-paragraph\">[1] ASHRAE. ASHRAE Guideline 0-2019 \u2014 The Commissioning Process. Atlanta: ASHRAE, 2019.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[2] ASHRAE; IES. ANSI\/ASHRAE\/IES Standard 202-2024 \u2014 The Commissioning Process Requirements for New Buildings and New Systems. Atlanta: ASHRAE, 2024.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO\/IEC 22237-1:2021 \u2014 Information technology \u2014 Data centre facilities and infrastructures \u2014 Part 1: General concepts. Geneva: ISO, 2021.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO\/IEC TS 22237-7:2018 \u2014 Information technology \u2014 Data centre facilities and infrastructures \u2014 Part 7: Management and operational information. Geneva: ISO, 2018.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[5] TELECOMMUNICATIONS INDUSTRY ASSOCIATION. ANSI\/TIA-942-C \u2014 Telecommunications Infrastructure Standard for Data Centers. Arlington: TIA, 2024.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[6] BICSI. ANSI\/BICSI 002-2024 \u2014 The Standard for Data Center Design. Tampa: BICSI, 2024.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEEE. ISO\/IEC\/IEEE 29148:2018 \u2014 Systems and software engineering \u2014 Life cycle processes \u2014 Requirements engineering. Geneva: ISO, 2018.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[8] UPTIME INSTITUTE. Tier Standard: Topology for Data Center Site Infrastructure. Uptime Institute.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[9] ASHRAE. Thermal Guidelines for Data Processing Environments. 5. ed. Atlanta: ASHRAE.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[10] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 \u2014 Risk management \u2014 Guidelines. Geneva: ISO, 2018.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[11] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9001:2015 \u2014 Quality management systems \u2014 Requirements. Geneva: ISO, 2015.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[12] A3A ENGENHARIA. Dise\u00f1o de Data Center: estudio, dise\u00f1o b\u00e1sico y ejecutivo. Ponta Grossa: A3A Engenharia.<\/p>\n<\/details>\n\n\n\n<details class=\"wp-block-details is-layout-flow wp-block-details-is-layout-flow\"><summary>Preguntas frecuentes<\/summary>\n<div class=\"schema-faq wp-block-yoast-faq-block\"><div class=\"schema-faq-section\" id=\"faq-question-qual-a-diferen-a-entre-opr-urs-e-basis-of-design-1316d1fc\"><strong class=\"schema-faq-question\">\u00bfCu\u00e1l es la diferencia entre OPR, URS y Basis of Design?<\/strong> <p class=\"schema-faq-answer\">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\u00f3mo el equipo de dise\u00f1o pretende atender esos requisitos.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-todo-projeto-de-data-center-precisa-de-uma-urs-s-7f3b90ee\"><strong class=\"schema-faq-question\">\u00bfTodo proyecto de Data Center necesita una URS separada?<\/strong> <p class=\"schema-faq-answer\">No necesariamente. La organizaci\u00f3n puede mantener requisitos de usuarios dentro del OPR o en documentos separados. Lo esencial es garantizar autor\u00eda, aprobaci\u00f3n, claridad y trazabilidad.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-quem-deve-elaborar-o-opr-417a1e66\"><strong class=\"schema-faq-question\">\u00bfQui\u00e9n debe elaborar el OPR?<\/strong> <p class=\"schema-faq-answer\">El propietario es responsable del contenido y de la aprobaci\u00f3n. Los consultores pueden facilitar workshops y redactar el documento, pero las decisiones sobre objetivos, riesgos, operaci\u00f3n e inversi\u00f3n pertenecen al propietario.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-quem-elabora-o-basis-of-design-4cd39170\"><strong class=\"schema-faq-question\">\u00bfQui\u00e9n elabora el Basis of Design?<\/strong> <p class=\"schema-faq-answer\">El equipo de dise\u00f1o y los responsables t\u00e9cnicos elaboran el BoD, registrando premisas, criterios, c\u00e1lculos, arquitecturas y justificaciones utilizadas para atender los requisitos aprobados.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-o-opr-faz-parte-do-contrato-43568199\"><strong class=\"schema-faq-question\">\u00bfEl OPR forma parte del contrato?<\/strong> <p class=\"schema-faq-answer\">Depende de la estrategia contractual. Puede orientar la intenci\u00f3n sin ser incorporado \u00edntegramente como documento contractual. La jerarqu\u00eda entre OPR, especificaciones, planos y propuestas debe ser explicitada.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-quando-o-opr-deve-ser-criado-8f1b1daf\"><strong class=\"schema-faq-question\">\u00bfCu\u00e1ndo debe crearse el OPR?<\/strong> <p class=\"schema-faq-answer\">Debe comenzar en el preproyecto o en la viabilidad y madurar a lo largo de los gates. Despu\u00e9s de cada baseline, los cambios deben seguir un proceso formal de evaluaci\u00f3n y aprobaci\u00f3n.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-como-saber-se-um-requisito-verific-vel-853ba592\"><strong class=\"schema-faq-question\">\u00bfC\u00f3mo saber si un requisito es verificable?<\/strong> <p class=\"schema-faq-answer\">El requisito debe indicar condici\u00f3n, l\u00edmite y m\u00e9todo posible de comprobaci\u00f3n, como an\u00e1lisis, inspecci\u00f3n, demostraci\u00f3n o prueba, adem\u00e1s de la evidencia esperada y de la fase de verificaci\u00f3n.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-o-basis-of-design-substitui-os-memoriais-e-desen-ad5c7837\"><strong class=\"schema-faq-question\">\u00bfEl Basis of Design sustituye las memorias y planos?<\/strong> <p class=\"schema-faq-answer\">No. El BoD explica la l\u00f3gica y las bases de la soluci\u00f3n. Memorias de c\u00e1lculo, memorias descriptivas, especificaciones, diagramas, plantas y detalles desarrollan y contractualizan esa soluci\u00f3n.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-como-opr-e-bod-se-relacionam-com-o-comissionamen-344e2541\"><strong class=\"schema-faq-question\">\u00bfC\u00f3mo se relacionan OPR y BoD con el commissioning?<\/strong> <p class=\"schema-faq-answer\">El OPR define lo que debe alcanzarse; el BoD explica c\u00f3mo el dise\u00f1o pretende atenderlo; y el commissioning revisa, inspecciona y prueba la soluci\u00f3n para producir evidencias de cumplimiento.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-o-que-uma-matriz-de-rastreabilidade-63a4b7b5\"><strong class=\"schema-faq-question\">\u00bfQu\u00e9 es una matriz de trazabilidad?<\/strong> <p class=\"schema-faq-answer\">Es el mecanismo que relaciona cada requisito con su origen, respuesta en el BoD, documentos de dise\u00f1o, suministros, m\u00e9todos de verificaci\u00f3n, evidencias y estado.<\/p><\/div><\/div>\n<\/details>\n\n\n\n<details class=\"wp-block-details is-layout-flow wp-block-details-is-layout-flow\"><summary>Materiales t\u00e9cnicos complementarios<\/summary>\n<h3 class=\"wp-block-heading\">Fundamentos y planificaci\u00f3n<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/conteudo\/artigos-tecnicos\/data-center-o-que-e-como-funciona-infraestrutura\/\">Data Center: qu\u00e9 es, c\u00f3mo funciona y qu\u00e9 sistemas componen la infraestructura<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/estudo-viabilidade-data-center\/\">Estudio de viabilidad de Data Center: energ\u00eda, conectividad, terreno y riesgos<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/como-escolher-localizacao-data-center\/\">C\u00f3mo elegir la ubicaci\u00f3n de un Data Center<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Requisitos, arquitectura y dise\u00f1o<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/conteudo\/artigos-tecnicos\/como-projetar-data-center\/\">C\u00f3mo dise\u00f1ar un Data Center: etapas, disciplinas y entregables<\/a><\/li><li><a href=\"\/servicos\/planejamento\/projeto-de-data-center\/\">Dise\u00f1o de Data Center<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/data-center-tier-3\/\">Tier I, II, III y IV en Data Centers<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/data-center-modular\/\">Data Center modular: dise\u00f1o, riesgos y cu\u00e1ndo utilizarlo<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Gobernanza, contrataci\u00f3n y control de cambios<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/servicos\/contratacao-integrada\/owners-engineering-para-data-centers\/\">Owner\u2019s Engineering para Data Centers<\/a><\/li><li><a href=\"\/solucoes\/gestao-e-governanca-de-engenharia\/engenharia-integrada-para-data-centers\/\">Ingenier\u00eda Integrada para Data Centers<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/stage-gate-projetos-engenharia\/\">Stage-gate en proyectos de ingenier\u00eda<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/gestao-riscos-projetos-engenharia\/\">Gesti\u00f3n de riesgos en proyectos de ingenier\u00eda<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Commissioning, verificaci\u00f3n y aceptaci\u00f3n<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/servicos\/servicos-complementares\/comissionamento-aceite-data-centers\/\">Commissioning y Aceptaci\u00f3n de Data Centers<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/comissionamento-sistemas-criticos-prontos-para-operar\/\">Commissioning de sistemas cr\u00edticos<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/sla-o-que-e-como-definir-calcular\/\">SLA: c\u00f3mo definir y calcular el nivel de servicio<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Disciplinas y sistemas especializados<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/solucoes\/engenharia-de-redes-e-telecomunicacoes\/redes-telecomunicacoes-para-data-centers\/\">Redes y Telecomunicaciones para Data Centers<\/a><\/li><li><a href=\"\/solucoes\/engenharia-de-sistemas-hvac\/climatizacao-de-data-centers\/\">Climatizaci\u00f3n de Data Centers<\/a><\/li><li><a href=\"\/solucoes\/gestao-de-ti\/data-center-infrastructure-management-dcim\/\">DCIM para Data Centers<\/a><\/li><li><a href=\"\/solucoes\/engenharia-de-sistemas-de-seguranca-eletronica\/seguranca-fisica-para-data-centers\/\">Seguridad F\u00edsica para Data Centers<\/a><\/li><li><a href=\"\/solucoes\/engenharia-de-seguranca-contra-incendio-e-panico\/incendio-em-data-centers\/\">Detecci\u00f3n y Supresi\u00f3n de Incendios en Data Centers<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Modelos y escalas de implantaci\u00f3n<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/conteudo\/artigos-tecnicos\/hyperscale-data-center-o-que-e\/\">Hyperscale Data Center: qu\u00e9 es y c\u00f3mo funciona<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/como-avaliar-provedor-colocation\/\">Colocation Data Center: c\u00f3mo evaluar un proveedor<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/edge-data-center-o-que-e\/\">Edge Data Center: aplicaciones y arquitectura<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/micro-data-center\/\">Micro Data Center: aplicaciones y criterios de especificaci\u00f3n<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Normas y fuentes oficiales<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"https:\/\/www.ashrae.org\/technical-resources\/bookstore\/commissioning\">ASHRAE \u2014 commissioning, OPR y Basis of Design<\/a><\/li><li><a href=\"https:\/\/www.iso.org\/standard\/78550.html\">ISO\/IEC 22237-1 \u2014 conceptos generales para Data Centers<\/a><\/li><li><a href=\"https:\/\/www.iso.org\/standard\/73014.html\">ISO\/IEC TS 22237-7 \u2014 gesti\u00f3n y operaci\u00f3n<\/a><\/li><li><a href=\"https:\/\/tiaonline.org\/resource\/tia-942-c-data-center-infrastructure-standard\/\">TIA-942-C \u2014 infraestructura de Data Centers<\/a><\/li><\/ul>\n<\/details>\n","protected":false},"excerpt":{"rendered":"<p>Comprenda OPR, URS y Basis of Design en proyectos de Data Center: requisitos del propietario y usuarios, respuesta de ingenier\u00eda, trazabilidad, commissioning y gobernanza documental.<\/p>\n","protected":false},"author":1,"featured_media":78775,"parent":0,"template":"","meta":{"_a3a_global_related_solutions":[],"_a3a_global_related_services":[],"_a3a_global_related_materials":[],"_a3a_post_lang":"es-es","_a3a_translation_group_id":"741250b7-11c7-4550-af09-dabdff453507","_a3a_i18n_canonical_slug":"basis-of-design-opr-urs-proyectos-data-center","_a3a_prod_post_id":"","_a3a_lang_url_en-us":"","_a3a_lang_url_es-es":""},"categories":[],"segments":[],"mercados":[],"etapas":[],"class_list":["post-81790","articles","type-articles","status-publish","has-post-thumbnail","hentry"],"_links":{"self":[{"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/articles\/81790","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/articles"}],"about":[{"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/types\/articles"}],"author":[{"embeddable":true,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":1,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/articles\/81790\/revisions"}],"predecessor-version":[{"id":81796,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/articles\/81790\/revisions\/81796"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/media\/78775"}],"wp:attachment":[{"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/media?parent=81790"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/categories?post=81790"},{"taxonomy":"segments","embeddable":true,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/segments?post=81790"},{"taxonomy":"mercados","embeddable":true,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/mercados?post=81790"},{"taxonomy":"etapas","embeddable":true,"href":"https:\/\/a3aengenharia.com\/es-es\/wp-json\/wp\/v2\/etapas?post=81790"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}