Conozca cómo aplicar Owner’s Engineering en Data Centers, con responsabilidades, matriz RACI, límites, interfaces, entregables, comisionamiento y aceptación.
¡Descúbrelo!
El Owner’s Engineering en Data Centers es la aplicación de la Ingeniería del Propietario a la gobernanza de proyectos en los que la energía crítica, la climatización, las telecomunicaciones, la automatización, la seguridad, la protección contra incendios, la arquitectura, la operación y la tecnología deben funcionar como un único sistema. Su función es representar técnicamente al propietario, preservar los requisitos aprobados, controlar interfaces, cualificar decisiones y consolidar evidencias para la implementación, el comisionamiento y la aceptación.
Este artículo no pretende sustituir la explicación general sobre qué es Owner’s Engineering. El enfoque aquí es otro: cómo debe estructurarse la función específicamente en proyectos, ampliaciones y modernizaciones de Data Centers, qué responsabilidades puede asumir, qué decisiones permanecen con el propietario y qué actividades corresponden a los proyectistas, proveedores, gerencia, fiscalización y autoridad de comisionamiento.
En un Data Center, el OE no debe entenderse como una fiscalización ampliada ni como un proyectista paralelo. Organiza la gobernanza técnica entre requisitos, proyectos, contratos, submittals, ejecución, pruebas y operación. La responsabilidad técnica por las soluciones y los suministros continúa con sus respectivos autores y ejecutores; el propietario sigue siendo responsable de las decisiones de inversión, riesgo y operación.
Síntesis técnica
| Pregunta | Respuesta objetiva |
| ¿Cuál es la función del OE? | Representar técnicamente al propietario y preservar requisitos, interfaces, riesgos y criterios de aceptación. |
| ¿El OE diseña? | Puede desarrollar estudios o proyectos cuando esto esté contratado, pero debe separar autoría, revisión independiente y aprobación. |
| ¿El OE ejecuta la obra? | Normalmente no. La ejecución permanece con constructoras, contratistas EPC, integradores y proveedores. |
| ¿El OE aprueba por sí solo? | No necesariamente. Analiza y recomienda; la autoridad de aprobación debe definirse en la gobernanza. |
| ¿El OE sustituye la gestión? | No. Puede integrar la estructura de gestión, pero plazo, costo, contratos y comunicación tienen responsabilidades propias. |
| ¿El OE sustituye el comisionamiento? | No. Gobierna los requisitos y la aceptación del propietario; la autoridad de comisionamiento conduce el proceso de verificación conforme al alcance contratado. |
| ¿Cuándo genera más valor? | Cuando participa desde los requisitos, el diseño y la contratación, antes de que las decisiones se incorporen a contratos y equipos. |
| ¿Cuál es el principal entregable? | No existe uno solo. El valor está en el conjunto trazable de dictámenes, matrices, registros, decisiones, evidencias y recomendaciones. |
¿Por qué los Data Centers requieren una aplicación específica de Owner’s Engineering?
La infraestructura de un Data Center está compuesta por cadenas funcionales interdependientes. La carga TIC depende de la alimentación eléctrica, el rechazo de calor, la conectividad, el control ambiental, la protección física, la automatización, la detección de incendios, los procedimientos operativos y equipos preparados. Un componente puede cumplir aisladamente su especificación y, aun así, el sistema integrado puede fallar en una condición de mantenimiento, transferencia o emergencia.
Este riesgo aumenta porque cada cadena suele involucrar diferentes proyectistas, fabricantes, instaladores y contratos. La compañía eléctrica entrega energía en un punto determinado; la subestación transforma y distribuye; los generadores y UPS sostienen las cargas; los sistemas de climatización rechazan calor; la automatización supervisa estados; las redes transportan datos y alarmas; los sistemas de incendio y seguridad aplican sus propias lógicas. Entre estos paquetes existen decenas de fronteras físicas, funcionales, documentales y contractuales.
La serie ISO/IEC 22237 organiza principios de infraestructura de Data Centers considerando disponibilidad, seguridad y eficiencia a lo largo del ciclo de vida. La ANSI/TIA-942-C abarca instalaciones de diferentes tamaños y modelos, incluyendo arquitectura, telecomunicaciones, energía, climatización, incendios, seguridad y monitoreo. Estas referencias ayudan a estructurar requisitos, pero no sustituyen la gobernanza específica del propietario.
El OE crea esta capa de gobernanza al conectar:
- objetivos de la inversión y requisitos del propietario;
- criterios de diseño y decisiones de arquitectura;
- responsabilidades de los contratos;
- interfaces entre disciplinas y proveedores;
- cambios, desviaciones y riesgos;
- evidencias de fabricación, instalación y pruebas;
- condiciones de aceptación y preparación operativa.
El artículo general y la cola larga de Data Centers
La palabra clave amplia Owner’s Engineering pertenece al artículo general de A3A Engenharia. El nuevo contenido debe funcionar como una especialización semántica y metodológica.
| Contenido | Intención principal |
| Owner’s Engineering: gobernanza técnica para obras y sistemas críticos | explicar el concepto general, aplicaciones, modelos y diferencias con funciones relacionadas |
| Este artículo | explicar responsabilidades, RACI, entregables y límites del OE en Data Centers |
| Owner’s Engineering para Data Centers | presentar el servicio contratable, alcance comercial y actuación de A3A Engenharia |
Por ello, la definición general será breve. El resto del artículo tratará situaciones propias de los Data Centers: carga TIC, distribución A/B, redundancia, mantenibilidad concurrente, climatización crítica, telecomunicaciones, BMS, EPMS, DCIM, fases energizadas, pruebas integradas y handover operativo.
¿Qué representa el Owner’s Engineering en el proyecto?
El OE actúa como extensión técnica del propietario, pero no recibe automáticamente autoridad irrestricta. Su autoridad debe establecerse en el contrato, plan de gobernanza, matriz RACI, flujos de aprobación y delegaciones formales.
En la práctica, la función puede asumir cuatro niveles de actuación:
| Nivel | Actuación | Ejemplo |
| Informar | organizar datos, riesgos y evidencias | consolidar un informe de desviación de capacidad |
| Analizar | evaluar adherencia e impacto | revisar una modificación de UPS o chiller |
| Recomendar | emitir un dictamen para la decisión | recomendar la aprobación condicionada de un submittal |
| Aprobar por delegación | decidir dentro de límites autorizados | aprobar un documento de baja criticidad conforme a la matriz |
El hecho de que el OE revise un documento no transfiere automáticamente la responsabilidad de diseño. Un plano elaborado por el proyectista continúa bajo responsabilidad de su autor. Un equipo seleccionado y suministrado por un fabricante permanece bajo responsabilidad del proveedor. Una instalación ejecutada por una constructora permanece bajo responsabilidad de la ejecutora.
La revisión del OE verifica la adherencia a los requisitos del propietario e identifica riesgos, inconsistencias e interfaces. No debe utilizarse como mecanismo para trasladar al propietario la responsabilidad que corresponde a la cadena de suministro.
¿Qué no debe sustituir el OE?
El propietario
Las decisiones sobre inversión, tolerancia al riesgo, prioridad de plazo, capacidad, modelo operativo, aceptación de riesgo residual y estrategia de expansión pertenecen al propietario. El OE aporta análisis y recomendaciones, pero no debe asumir silenciosamente decisiones empresariales.
El proyectista
El proyectista desarrolla y responde técnicamente por las soluciones dentro de su alcance. El OE puede revisar criterios, cálculos, diagramas, layouts e interfaces, pero no debe corregir informalmente documentos y permitir que la autoría quede indefinida.
El ejecutor o contratista EPC
Constructoras, integradores y contratistas EPC responden por la ejecución, calidad, seguridad, planificación de sus servicios y cumplimiento contractual. El seguimiento del OE no elimina sus propias inspecciones, control de calidad ni responsabilidad por las correcciones.
La gerencia o el PMO
La gestión del alcance, plazo, costo, contratos, comunicación y riesgos del proyecto puede ser ejercida por una gerencia, PMO o equipo interno. El OE aporta contenido técnico para estas decisiones, pero el control integrado del proyecto debe seguir teniendo un responsable definido.
La autoridad de comisionamiento
El comisionamiento posee su propio proceso, documentación y responsabilidades. La ASHRAE/IES Standard 202-2024 describe el proceso y los roles de los principales agentes. El OE protege los intereses del propietario, participa en la definición de requisitos y evalúa evidencias; la autoridad de comisionamiento coordina la verificación conforme al plan aprobado.
La operación
El equipo de operación debe participar en requisitos, revisiones, procedimientos, pruebas y capacitación. El OE no debe decidir por sí solo cómo se operará, mantendrá y recuperará la instalación después de fallas.
Diferencias entre OE, gestión, fiscalización, EPCM y comisionamiento
| Función | Responsabilidad dominante | Entregables típicos | Límite principal |
| Owner’s Engineering | gobernanza técnica y representación del propietario | dictámenes, matrices, revisiones, decisiones, evidencias y recomendaciones | no sustituye la autoría técnica ni la decisión empresarial |
| Gestión | coordinación de plazo, costo, alcance, comunicación y contratos | cronogramas, informes, controles, actas y dashboards | puede no tener profundidad multidisciplinaria de ingeniería |
| Fiscalización | verificación de la ejecución en campo | informes, registros, mediciones y no conformidades | frecuentemente concentrada en la construcción |
| EPCM | engineering, procurement y construction management | proyectos, paquetes, adquisiciones y gestión de la implementación | puede asumir un papel ejecutivo más amplio que el OE |
| EPC o design-build | entrega integrada de la solución | ingeniería, suministros, construcción y pruebas | representa al contratista, no al propietario |
| Comisionamiento | verificación documentada de requisitos y desempeño | planes, checklists, pruebas, issue logs e informes | no sustituye la gobernanza global de la inversión |
| Operación | explotación segura y confiable del activo | SOPs, MOPs, EOPs, registros y mantenimiento | no debe recibir un sistema sin baseline y capacitación |
Estas funciones pueden coexistir. En un contrato EPC, por ejemplo, el contratista EPC desarrolla y entrega la solución; una gerencia controla plazo y costo; la autoridad de comisionamiento estructura las pruebas; y el OE verifica que requisitos, interfaces, cambios y evidencias permanezcan alineados con los intereses del propietario.
La función del Owner’s Engineering debe estar definida antes de las principales contrataciones.
Autoridad, responsabilidades, interfaces, submittals, cambios, inspecciones y criterios de aceptación deben constar en la gobernanza y en los documentos contractuales. Sin esta definición, el OE tiende a actuar únicamente de forma reactiva durante la obra.
Conozca el servicio de Owner’s Engineering para Data Centers
Modelo de gobernanza para un Data Center
La gobernanza debe diseñarse antes de la emisión de las principales RFP. Una vez que responsabilidades, precios, plazos y exclusiones se incorporan a los contratos, corregir brechas se vuelve más difícil y costoso.
Una estructura mínima incluye:
1. definición de las autoridades del propietario; 2. identificación de los responsables técnicos por disciplina; 3. matriz RACI por proceso y entregable; 4. jerarquía documental y baselines; 5. flujo de submittals, RFI y cambios; 6. matriz de interfaces entre paquetes; 7. registro de riesgos y decisiones; 8. plan de inspección, pruebas y comisionamiento; 9. criterios de aceptación y transferencia a operación; 10. reglas para pendientes, excepciones y riesgo residual.
La gobernanza no debe existir únicamente como organigrama. Cada flujo debe indicar entradas, plazo, autoridad, evidencia de decisión y condición de cierre.
¿Cómo utilizar la matriz RACI?
La matriz RACI identifica quién es responsable de ejecutar una actividad, quién posee autoridad final, quién debe ser consultado y quién debe ser informado.
- R — Responsible: ejecuta o produce el trabajo.
- A — Accountable: responde por la decisión o aprobación final.
- C — Consulted: participa técnicamente antes de la decisión.
- I — Informed: recibe la información después del hito o decisión.
Una actividad debe tener responsables definidos y, preferentemente, una única autoridad final. Cuando varios agentes creen ser el aprobador, surgen decisiones paralelas. Cuando ningún agente asume la autoridad, los documentos permanecen indefinidos o se liberan por el mero transcurso del plazo.
Ejemplo de matriz RACI por fase
La matriz siguiente es conceptual. La configuración real depende del modelo contractual, las delegaciones y la estructura del propietario.
| Actividad | Propietario | OE | Proyectista | Gerencia | EPC/Ejecutor | CxA | Operación |
| aprobar objetivos y OPR | A | R/C | C | I | I | C | C |
| desarrollar Basis of Design | C | C | R/A | I | C | C | C |
| aprobar arquitectura conceptual | A | R/C | R | C | I | C | C |
| elaborar proyecto ejecutivo | I | C | R/A | C | C | C | C |
| revisar proyecto frente a requisitos | A | R | C | I | I | C | C |
| elaborar RFP técnica | A | R | C | C | I | C | C |
| responder propuesta y desviaciones | I | C | C | I | R/A | I | I |
| igualar técnicamente propuestas | A | R | C | C | I | C | C |
| aprobar submittal | A o delegado | R/C | C | I | R | C | C |
| ejecutar construcción | I | C | C | C | R/A | I | I |
| fiscalizar ejecución | A | R o C | C | C/R | R | I | I |
| elaborar procedimientos de prueba | I | C | C | I | R | A/R | C |
| aprobar criterios de aceptación | A | R/C | C | I | C | R/C | C |
| ejecutar FAT y SAT | I | C | C | I | R | A/R | C |
| decidir sobre riesgo residual | A | R/C | C | C | I | C | C |
| aceptar técnicamente el sistema | A | R/C | C | I | I | C | C |
| asumir operación | A | C | I | I | C | C | R |
La matriz no debe copiarse mecánicamente. En algunos proyectos, el proyectista principal aprueba submittals; en otros, esa autoridad permanece con el propietario. La autoridad de comisionamiento puede ser contratada por el propietario o integrar otra estructura, siempre que su independencia y sus límites estén claros.
Matriz de autoridad decisoria
RACI explica la participación, pero las decisiones críticas también exigen límites de autoridad.
| Decisión | Recomendación del OE | Autoridad final típica |
| modificar capacidad TIC | análisis de impacto y escenarios | propietario |
| aceptar reducción de redundancia | dictamen de riesgo y operación | propietario |
| aprobar equivalencia técnica | análisis de conformidad | propietario o delegado |
| aceptar desviación sin impacto funcional | recomendación documentada | OE, si está formalmente delegado |
| modificar cronograma de energización | análisis técnico y de interfaces | dirección del proyecto |
| utilizar contingencia temporal | análisis de riesgo y controles | propietario y operación |
| aceptar pendiente menor | clasificación y recomendación | autoridad definida en el plan |
| aceptar riesgo residual crítico | dictamen y condicionantes | propietario |
| rechazar entrega sin evidencia | recomendación técnica | autoridad contractual |
La delegación debe establecer límites por valor, criticidad, disciplina, tipo de documento e impacto. Sin ello, el OE puede ser responsabilizado por decisiones que no tenía autoridad para tomar o, en sentido opuesto, puede aprobar modificaciones que deberían haber permanecido con el propietario.
Responsabilidades en la viabilidad y selección del sitio
En la fase de estudio de viabilidad de Data Center, el OE ayuda a estructurar criterios, evidencias y condicionantes. Su actuación puede incluir la revisión de capacidad eléctrica, conectividad, expansión, riesgos del terreno, permisos, agua, climatización, cronograma y alternativas de implementación.
El papel no consiste únicamente en producir una puntuación de sitios. El OE debe identificar qué información sigue siendo una hipótesis, qué depende de compromisos de compañías eléctricas u operadores y qué condiciones deben resolverse antes de la adquisición o inversión.
Entregables posibles:
| Entregable | Función |
| matriz de criterios y ponderaciones | comparar alternativas de forma trazable |
| registro de evidencias | separar datos confirmados, declaraciones y premisas |
| matriz de riesgos | registrar impacto, responsable y tratamiento |
| dictamen de alternativas | recomendar avance, condicionamiento o descarte |
| condiciones precedentes | establecer qué debe demostrarse antes del compromiso |
| gate de decisión | apoyar una decisión Go, Hold o No-Go |
El artículo Cómo elegir la ubicación de un Data Center profundiza en la selección geográfica e inmobiliaria. En este artículo, la selección aparece únicamente como una fase de la gobernanza del OE.
Responsabilidades sobre OPR, URS y Basis of Design
El propietario debe contar con requisitos claros antes de que el equipo de diseño consolide la solución. El artículo sobre Basis of Design, OPR y URS explica la función de cada documento.
El OE puede facilitar workshops, estructurar requisitos, organizar conflictos y mantener la trazabilidad. Sin embargo:
- el propietario aprueba objetivos, prioridades y riesgos;
- los usuarios y operadores aportan necesidades funcionales;
- los proyectistas documentan la respuesta técnica en el BoD;
- el OE verifica consistencia, integridad, trazabilidad e impacto;
- la autoridad de comisionamiento utiliza los requisitos para planificar verificaciones.
Una de las responsabilidades más importantes es impedir que los requisitos se modifiquen informalmente para acomodar una solución ya adquirida. Cuando una decisión de diseño exige un cambio en el OPR, la modificación debe pasar por análisis de impacto y aprobación del propietario.
Responsabilidades en la fase de diseño
El artículo Cómo diseñar un Data Center presenta las fases, disciplinas y entregables del proyecto. El OE no necesita reproducir el trabajo del proyectista; debe verificar que la evolución documental preserve los requisitos del proyecto.
Revisión de diseño
La revisión debe considerar:
- capacidad nominal, disponible y utilizable;
- arquitectura eléctrica y rutas A/B;
- redundancia y modos comunes de falla;
- estados normal, mantenimiento, falla, emergencia y retorno;
- mantenibilidad y sustitución de activos;
- segregación física y funcional;
- instrumentación y testabilidad;
- expansión y estados temporales;
- integración entre sistemas eléctricos, HVAC, automatización, incendio y seguridad;
- condiciones para operación y recuperación.
Una revisión de OE no debe limitarse a marcar comentarios en planos. Debe relacionar cada observación con el requisito, riesgo, interfaz o criterio de verificación correspondiente.
Constructibilidad
El diseño puede ser correcto en cálculo y ser inviable en campo. La revisión de constructibilidad considera accesos, transporte, izaje, secuencia, áreas de montaje, rutas temporales, interferencias, drenaje, conexiones, sustitución futura y coexistencia con áreas activas.
Operabilidad
El OE debe involucrar a operación para verificar si maniobras, aislamientos, bypasses, alarmas, interbloqueos y procedimientos pueden ejecutarse con claridad y seguridad.
Testabilidad
Los puntos de medición, conexiones temporales, cargas de prueba, simulaciones, controles, registros y seguridad de los ensayos deben preverse antes de la construcción. Un sistema imposible de probar tiende a producir una aceptación basada en presunciones.
La revisión del OE no sustituye un diseño de Data Center desarrollado con requisitos y entregables claros.
El diseño conceptual, básico y ejecutivo debe registrar capacidad, arquitectura, interfaces, modos de operación, expansión, testabilidad y criterios de aceptación. El OE verifica adherencia y riesgos sin asumir informalmente la autoría de las soluciones.
Interfaces técnicas que el OE debe gobernar
Energía y climatización
La carga eléctrica TIC se convierte casi íntegramente en carga térmica. Los cambios de densidad, UPS, distribución o expansión afectan climatización, espacio, peso, autonomía, cables, protecciones y controles. El OE verifica que las premisas sean comunes entre disciplinas.
Energía y automatización
Transferencias, estados de UPS, generadores, interruptores, medición y alarmas deben llegar al EPMS o BMS con prioridades, timestamps, permisos y lógica coherentes. La frontera entre fabricante, integrador y operador debe ser explícita.
Climatización y controles
Setpoints, sensores, etapas, fallas, redundancia, válvulas, bombas, ventiladores y estrategias de contención deben funcionar en conjunto. La simple disponibilidad de los equipos no demuestra un control térmico adecuado.
Telecomunicaciones y energía
Rutas de fibra, MMR, racks, alimentación A/B, puesta a tierra, identificación y segregación deben mantener diversidad real. Rutas diferentes en el plano pueden compartir un mismo shaft, sala o punto de entrada.
Incendio, HVAC y energía
Detección, alarmas, desconexiones, dampers, presurización, ventilación, descarga de agentes y procedimientos de emergencia tienen interacciones críticas. La matriz de causa y efecto debe ser compatible con las secuencias eléctricas y mecánicas.
Seguridad física y operación
Control de acceso, videovigilancia, credenciales, interbloqueos, visitantes y emergencias deben permitir operación, mantenimiento y evacuación sin eliminar la protección por capas.
DCIM, BMS y EPMS
La gobernanza debe definir qué plataforma es la fuente de cada dato, cómo intercambian información los sistemas, qué alarmas son operativas, cómo se realiza la sincronización de tiempo y cómo se entregarán los datos al propietario.
Matriz de interfaces entre paquetes
| Interfaz | Paquete A | Paquete B | Pregunta que debe responderse |
| alimentación del chiller | eléctrica | HVAC | ¿quién suministra cables, protección, arranque y señales? |
| comunicación de UPS | UPS | EPMS/DCIM | ¿protocolo, gateway, puntos, prueba y responsabilidad? |
| desconexión por incendio | incendio | eléctrica/HVAC | ¿qué cargas se desconectan, en qué secuencia y bajo qué autoridad? |
| alimentación A/B de racks | eléctrica | racks/TI | ¿conectores, balanceo, identificación y límite de carga? |
| entrada de operadores | telecom | civil/seguridad | ¿rutas, sellado, acceso y diversidad física? |
| contención de pasillo | arquitectura | HVAC/TI | ¿responsabilidad por geometría, puertas, sensores y desempeño? |
| combustible | generadores | civil/operación | ¿almacenamiento, transferencia, autonomía, acceso y pruebas? |
| datos de medición | eléctrica/HVAC | DCIM | ¿precisión, protocolo, registro, retención y ownership? |
El OE debe mantener la matriz viva. Una interfaz “resuelta” en una reunión solo puede cerrarse cuando se haya incorporado a los documentos, contratos, instalación y pruebas aplicables.
Responsabilidades en la RFP y el procurement
La RFP para Data Center transforma los requisitos en una base comparable para el mercado. El OE puede coordinar o revisar:
- objeto y límites del paquete;
- requisitos funcionales y técnicos;
- documentos de entrada;
- matriz de responsabilidades;
- matriz de conformidad y desviaciones;
- entregables de diseño y fabricación;
- criterios de calificación;
- estructura de precios y opcionales;
- cronograma y long lead items;
- FAT, SAT, pruebas integradas y aceptación;
- documentación, capacitación, garantía y soporte.
Igualación de propuestas
El OE debe separar cumplimiento integral, cumplimiento condicionado, alternativa y desviación. El análisis debe considerar alcance, capacidad, arquitectura, ciclo de vida, riesgos, cronograma, pruebas, documentación y costo total — no solo el valor presentado.
Alternativas técnicas
La RFP puede permitir alternativas, pero el proveedor también debe presentar una propuesta base conforme. La alternativa debe demostrar su impacto sobre capacidad, disponibilidad, mantenimiento, expansión, operación, plazo, costo y comisionamiento.
Conflicto de interés
Cuando la misma empresa elabora la especificación, suministra el equipo y valida su conformidad sin revisión independiente, surge un riesgo de conflicto de interés. El modelo contractual debe separar adecuadamente autoría, recomendación, decisión y verificación.
Submittals, shop drawings y documentos de proveedores
El OE debe participar en el flujo documental de acuerdo con su autoridad. Un submittal típico puede pasar por:
1. verificación formal de integridad; 2. análisis del proyectista responsable; 3. revisión del OE frente a requisitos e interfaces; 4. consulta a operación o comisionamiento cuando corresponda; 5. decisión por la autoridad definida; 6. registro de condicionantes y desviaciones; 7. incorporación al diseño, fabricación y as built; 8. cierre tras evidencia de cumplimiento.
Estados genéricos como “aprobado con comentarios” deben tener significado contractual. Debe quedar claro si el proveedor puede fabricar, qué comentarios son obligatorios, quién verifica su incorporación y cuándo el documento se considera cerrado.
El OE no debe modificar directamente el documento del proveedor y asumir su autoría. Comentarios, respuestas y revisiones deben preservar la trazabilidad.
RFI y aclaraciones técnicas
Las RFI son instrumentos para resolver dudas o inconsistencias. No deben convertirse en un canal informal de modificación del alcance.
Cada RFI relevante debe identificar:
- documento y requisito afectado;
- duda o conflicto;
- propuesta del solicitante;
- impacto en otras disciplinas;
- efecto sobre plazo, costo y pruebas;
- decisión y autoridad;
- documentos que deben actualizarse.
Una respuesta rápida pero incompleta puede generar consecuencias en múltiples interfaces. El OE evalúa el efecto sistémico antes de recomendar la decisión.
Gestión de cambios y desviaciones
Las modificaciones en Data Centers pueden afectar disponibilidad, capacidad, eficiencia, mantenimiento y seguridad. Un cambio aparentemente simple — sustituir un interruptor, modificar una válvula, mover un rack o cambiar un gateway — puede alterar selectividad, secuencia, acceso, medición o pruebas.
El proceso recomendado es:
1. registrar el origen y la justificación; 2. identificar requisitos, documentos y contratos afectados; 3. analizar alternativas; 4. evaluar el impacto técnico multidisciplinario; 5. evaluar plazo, costo, riesgo y operación; 6. definir pruebas y evidencias adicionales; 7. someter a la autoridad correspondiente; 8. actualizar baselines y comunicar a las partes; 9. verificar la implementación y cerrar el cambio.
El OE debe distinguir cambio aprobado, desviación temporal, no conformidad y concesión. Estos términos tienen efectos diferentes sobre corrección, plazo, aceptación y riesgo residual.
Responsabilidades durante la construcción
El seguimiento en campo del OE debe planificarse por riesgo. No es necesario observar continuamente cada actividad; es necesario definir puntos de inspección, hold points, witness points, muestreo y evidencias adecuados a la criticidad.
Planes de inspección y prueba
Los ITP deben indicar actividad, requisito, método, responsable, criterio, registro y punto de intervención. El OE revisa si la secuencia de inspección es suficiente para impedir que trabajos críticos queden ocultos antes de la verificación.
No conformidades
Una NCR debe registrar condición observada, requisito incumplido, evidencia, criticidad, acción propuesta, responsable, plazo, verificación de la corrección e impacto residual. Cerrar la NCR solo porque el trabajo fue rehecho no basta; es necesario verificar la eficacia.
Medición e hitos de pago
El OE puede proporcionar evidencia técnica para medición, retención o liberación de hitos, pero la autoridad financiera y contractual permanece con el propietario. El criterio debe estar definido antes de la ejecución.
Seguridad y método de ejecución
El OE puede revisar impactos técnicos e interfaces de los métodos de ejecución, pero la responsabilidad por seguridad laboral y planificación de la ejecución permanece con el contratista, conforme a la legislación y el contrato.
Expansión en un Data Center operativo
En entornos activos, el riesgo no está únicamente en el resultado final. Los estados temporales durante la obra pueden reducir redundancia, eliminar rutas, modificar alarmas o exponer cargas a una falla única.
El OE debe gobernar:
- segregación entre áreas activas y construcción;
- capacidad disponible durante cada fase;
- estados temporales y riesgo residual;
- MOP, SOP y EOP aplicables;
- ventanas y criterios de autorización;
- contingencias y rollback;
- monitoreo reforzado;
- preparación del equipo y proveedores;
- pruebas antes, durante y después de la intervención;
- actualización inmediata de la documentación.
Un futuro artículo sobre modernización sin interrumpir la operación profundizará en el método de intervención. Aquí, el tema se trata como una responsabilidad específica de gobernanza del OE.
Relación con el comisionamiento
El OE y la autoridad de comisionamiento trabajan sobre la misma cadena de requisitos, pero tienen perspectivas diferentes.
| Aspecto | Owner’s Engineering | Autoridad de comisionamiento |
| interés representado | propietario e inversión | proceso independiente de verificación |
| enfoque | gobernanza, decisiones, interfaces, riesgos y aceptación | planificación y ejecución de las verificaciones |
| inicio ideal | viabilidad y requisitos | pre-diseño, junto con el OPR |
| diseño | revisa adherencia y riesgos | revisa con foco en comisionabilidad |
| construcción | acompaña conformidad y cambios | verifica preparación y documentación |
| pruebas | evalúa evidencias e impacto en la aceptación | coordina procedimientos, ejecución e issues |
| decisión final | recomienda al propietario | informa resultados y pendientes |
La separación no significa aislamiento. El OE debe asegurar que los requisitos de comisionamiento estén incluidos en las RFP, contratos, submittals, cronogramas y métodos de ejecución.
Comisionamiento y Owner’s Engineering deben compartir la misma cadena de requisitos y evidencias.
FAT, SAT, pruebas funcionales e IST deben planificarse desde la contratación. El OE gobierna impacto, pendientes y recomendación de aceptación; la autoridad de comisionamiento coordina el proceso de verificación conforme al plan aprobado.
Conozca el servicio de Comisionamiento y Aceptación de Data Centers
FAT, SAT y pruebas integradas
FAT
El Factory Acceptance Test verifica funciones, fabricación, lógica, comunicación y desempeño que pueden demostrarse antes del envío. El OE participa en la definición del alcance, testificación, tratamiento de pendientes y autorización de embarque conforme a la gobernanza.
SAT
El Site Acceptance Test confirma instalación, configuración, conexiones, protecciones, comunicación y funciones en el entorno real. El hecho de que el equipo haya superado el FAT no elimina las verificaciones en campo.
Pruebas funcionales
Las pruebas funcionales demuestran el comportamiento de los sistemas en modos normal, mantenimiento, falla y emergencia. Los procedimientos deben citar requisitos, precondiciones, instrumentos, pasos, criterios y evidencias.
IST
Las pruebas integradas simulan interacciones entre sistemas: pérdida de la red eléctrica, arranque de generadores, transferencia de UPS, falla de climatización, pérdida de comunicación, incendio, estados degradados y retorno a la condición normal.
El OE evalúa si los resultados sustentan la recomendación de aceptación y si los pendientes o excepciones fueron correctamente clasificados.
Aceptación técnica y riesgo residual
La aceptación no significa ausencia absoluta de pendientes. Significa que la autoridad competente evaluó evidencias, pendientes, restricciones y riesgos y decidió conforme a criterios previamente establecidos.
Una clasificación práctica puede considerar:
| Clase | Condición | Efecto típico |
| crítica | compromete seguridad, función esencial o disponibilidad | impide energización, operación o aceptación |
| mayor | afecta desempeño, redundancia, mantenimiento o documentación esencial | exige corrección o decisión formal antes del hito |
| menor | no compromete la función principal y tiene tratamiento controlado | puede permanecer en punch list con plazo |
| documental | evidencia o registro incompleto | aceptación condicionada según el impacto |
El OE debe recomendar la decisión, pero los riesgos relevantes deben ser aceptados por el propietario. Ningún dictamen técnico debe ocultar que un determinado requisito no fue demostrado.
Handover y preparación operativa
La entrega física no representa preparación operativa. El handover debe reunir:
- requisitos vigentes y Basis of Design final;
- as built, diagramas y listas de activos;
- configuraciones, backups y licencias;
- informes de pruebas y pendientes;
- manuales y planes de mantenimiento;
- repuestos, herramientas y contratos de soporte;
- SOP, MOP y EOP;
- matriz de alarmas y escalamiento;
- capacitación y registros de competencia;
- límites, riesgos residuales y recomendaciones.
El OE verifica integridad y consistencia, pero operación debe confirmar que puede asumir el activo. La aceptación debe incluir personas, procesos, datos y soporte, no solo equipos.
Principales entregables del OE en Data Centers
| Fase | Entregables posibles |
| viabilidad | matriz de criterios, riesgos, condicionantes y dictamen de alternativas |
| requisitos | OPR/URS estructurados, matriz de trazabilidad y decisiones |
| diseño | dictámenes, design review, matriz de interfaces y constructibilidad |
| contratación | RFP, matriz de conformidad, igualación y recomendación técnica |
| fabricación | revisión de submittals, plan de inspección, FAT y seguimiento |
| construcción | informes, NCR, RFI, cambios, hold points y evidencias |
| comisionamiento | requisitos, revisión de procedimientos, issue log y dictámenes |
| aceptación | matriz de pendientes, riesgo residual y recomendación de aceptación |
| handover | checklist de preparación, documentación consolidada y baseline operativo |
El contrato no debe listar únicamente nombres genéricos de informes. Cada entregable debe tener finalidad, contenido mínimo, periodicidad, responsable, plazo y criterio de aceptación.
Registros y controles mínimos
Una estructura de OE debe mantener, según corresponda:
- registro de requisitos;
- matriz de trazabilidad;
- registro de decisiones;
- registro de riesgos;
- matriz de interfaces;
- matriz RACI;
- lista maestra de documentos;
- log de submittals;
- log de RFI;
- log de cambios;
- registro de no conformidades;
- issue log de comisionamiento;
- matriz de pendientes;
- registro de riesgo residual;
- dashboard de preparación.
Estos controles pueden integrarse en una plataforma digital. El objetivo no es multiplicar hojas de cálculo, sino preservar una fuente confiable de estado, decisión y evidencia.
Indicadores para medir la actuación del OE
La cantidad de comentarios emitidos no mide la calidad. Un OE puede generar miles de observaciones superficiales y no identificar una interfaz crítica.
Indicadores más útiles incluyen:
| Indicador | Interpretación |
| requisitos sin respuesta | brechas entre OPR y diseño |
| interfaces abiertas por fase | riesgo de integración aún no resuelto |
| submittals vencidos | presión sobre fabricación y cronograma |
| cambios con impacto no evaluado | fragilidad de gobernanza |
| NCR críticas abiertas | riesgo para energización o aceptación |
| pruebas aprobadas en la primera ejecución | madurez de diseño e instalación |
| pendientes por criticidad | preparación real del sistema |
| documentos de handover aceptados | preparación para operación |
| decisiones a la espera del propietario | cuello de botella de autoridad |
| riesgos residuales sin aceptación | impedimento para un cierre responsable |
Los indicadores deben analizarse en contexto. Una reducción rápida de pendientes puede representar una corrección efectiva o una simple reclasificación inadecuada.
¿Cómo dimensionar el equipo de Owner’s Engineering?
El dimensionamiento depende del tamaño, fases, modelo contractual, criticidad, dispersión geográfica, cantidad de paquetes y capacidad interna del propietario.
Núcleo permanente
Puede incluir gerente de OE, coordinador técnico, control documental e interfaces con planificación, contratos y operación.
Especialistas por disciplina
Especialistas en eléctrica, mecánica, telecomunicaciones, automatización, seguridad, incendio, civil, arquitectura, comisionamiento y operación pueden actuar según hitos y riesgos.
Presencia en campo
La cobertura puede variar entre visitas por hold point, equipo residente o modelo híbrido. La presencia continua sin método no sustituye especialistas en los momentos críticos.
Independencia
El equipo debe declarar conflictos de interés y separar la revisión independiente de actividades en las que participó como autor. Cuando A3A Engenharia también desarrolla proyectos o estudios, la gobernanza debe definir revisores distintos o mecanismos de verificación adecuados.
¿Cuándo contratar al OE?
El momento ideal es antes de consolidar los requisitos y las principales contrataciones. La entrada tardía reduce la capacidad de prevenir problemas y concentra la actuación en identificar desviaciones ya incorporadas.
| Momento de contratación | Capacidad de actuación |
| viabilidad | influye en criterios, riesgos, sitio y estrategia |
| requisitos | organiza OPR, URS, BoD y gobernanza |
| diseño conceptual | compara arquitecturas y define interfaces |
| diseño básico | cualifica RFP y criterios de contratación |
| diseño ejecutivo | revisa detalles, constructibilidad y testabilidad |
| construcción | controla conformidad, cambios e interfaces |
| comisionamiento | evalúa evidencias y pendientes, pero corrige menos causas |
| posobra | realiza auditoría, diagnóstico y recomisionamiento |
Contratar durante la construcción todavía puede generar valor, especialmente en proyectos con dificultades. Sin embargo, el alcance debe reconocer que varias decisiones ya estarán contractualizadas.
¿Cómo estructurar el contrato del OE?
El alcance debe definir:
1. objetivos de la actuación; 2. fases y paquetes incluidos; 3. responsabilidades y exclusiones; 4. autoridad y delegaciones; 5. disciplinas y disponibilidad del equipo; 6. entregables y periodicidad; 7. flujos documentales y plazos de respuesta; 8. participación en reuniones, inspecciones y pruebas; 9. criterios de medición y aceptación; 10. tratamiento de conflictos de interés; 11. propiedad y retención de los registros; 12. límites de responsabilidad profesional.
El contrato debe evitar expresiones como “garantizar el desempeño del Data Center” cuando el OE no controla diseño, fabricación, instalación y operación. La obligación debe definirse en términos de diligencia técnica, revisión, verificación, recomendación y evidencia, según el alcance.
Errores comunes
| Error | Consecuencia |
| contratar al OE solo para visitar la obra | requisitos y contratos permanecen sin gobernanza |
| no definir autoridad | las decisiones quedan paralizadas o son contradictorias |
| confundir revisión con autoría | la responsabilidad técnica se vuelve ambigua |
| usar una matriz RACI genérica | actividades críticas permanecen sin un responsable real |
| no involucrar a operación | la solución se entrega sin procedimientos ni competencia |
| dejar el comisionamiento para el final | los sistemas no se diseñan para ser probados |
| aprobar submittals sin analizar interfaces | equipos incompatibles avanzan a fabricación |
| permitir cambios por correo informal | la baseline y los contratos pierden coherencia |
| medir al OE por cantidad de informes | incentiva burocracia sin valor técnico |
| no registrar riesgo residual | la aceptación ocurre sin una decisión consciente del propietario |
| mantener al OE subordinado al ejecutor | la independencia y representación del propietario quedan comprometidas |
| no actualizar as built y BoD | operación recibe documentación histórica e inconsistente |
Checklist ejecutivo
1. ¿El artículo general de Owner’s Engineering sigue siendo la referencia conceptual del cluster? 2. ¿El nuevo alcance está explícitamente limitado a Data Centers? 3. ¿El propietario definió objetivos, capacidad, disponibilidad y riesgo? 4. ¿Existe autoridad formal para aprobar requisitos y cambios? 5. ¿La matriz RACI tiene un accountable claro por actividad? 6. ¿Proyectistas, proveedores y ejecutores mantienen sus responsabilidades técnicas? 7. ¿El OE posee independencia suficiente para emitir dictámenes? 8. ¿OPR, URS y BoD tienen baselines y trazabilidad? 9. ¿Están registradas las interfaces entre energía, HVAC, telecom, automatización, incendio y seguridad? 10. ¿Las RFP exigen matriz de conformidad y declaración de desviaciones? 11. ¿Los submittals tienen flujo, plazo, estado y condición de cierre? 12. ¿Se evita que las RFI se utilicen como cambios informales? 13. ¿Los cambios tienen análisis multidisciplinario de impacto? 14. ¿ITP, hold points y witness points fueron definidos por riesgo? 15. ¿Se evaluaron los estados temporales de expansión en ambiente activo? 16. ¿FAT, SAT, pruebas funcionales e IST citan requisitos verificables? 17. ¿Los pendientes tienen criticidad, responsable, plazo e impacto en la aceptación? 18. ¿Los riesgos residuales serán decididos por el propietario? 19. ¿Documentación, procedimientos y capacitación forman parte del handover? 20. ¿Operación confirmó su preparación para asumir el activo?
Alcance de ingeniería consultiva de A3A Engenharia
A3A Engenharia actúa en Owner’s Engineering para Data Centers desde la estructuración de requisitos y gobernanza hasta la implementación, el comisionamiento y la aceptación. El alcance puede adaptarse a Data Centers corporativos, colocation, Edge, Micro Data Centers, instalaciones modulares, ampliaciones, modernizaciones y entornos de alta criticidad.
La actuación puede incluir matriz RACI, OPR y URS, revisión del Basis of Design, design reviews, RFP, igualación técnica, matriz de interfaces, análisis de submittals, fiscalización orientada por riesgo, control de cambios, seguimiento de FAT y SAT, gobernanza de pruebas integradas, preparación operativa y recomendación de aceptación.
El servicio especializado se presenta en Owner’s Engineering para Data Centers. Puede integrarse con el Diseño de Data Center, el Estudio de Viabilidad y el Comisionamiento y Aceptación.
Resumen técnico
El Owner’s Engineering en Data Centers es una función de gobernanza técnica aplicada a un proyecto multidisciplinario y crítico. Representa al propietario, organiza requisitos, revisa decisiones, controla interfaces, evalúa cambios y consolida evidencias para la aceptación.
Su valor no está en sustituir proyectistas, ejecutores, gerencias, comisionamiento u operación. Está en mantener a estos agentes alineados con una baseline común, con responsabilidades, autoridades y límites explícitos.
La matriz RACI ayuda a identificar la participación, pero debe complementarse con delegaciones, flujos de aprobación y criterios de decisión. El OE recomienda y, cuando está formalmente autorizado, puede aprobar dentro de límites; los riesgos relevantes, cambios estratégicos y la aceptación final permanecen bajo la autoridad del propietario.
Cuando se contrata desde la viabilidad y los requisitos, el OE actúa preventivamente. Cuando se contrata únicamente durante la obra, todavía puede controlar desviaciones y evidencias, pero tiene menos margen para corregir decisiones ya incorporadas a contratos y equipos.
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 22237-1:2021 — Information technology — Data centre facilities and infrastructures — Part 1: General concepts. Geneva: ISO, 2021.
[2] 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.
[3] TELECOMMUNICATIONS INDUSTRY ASSOCIATION. ANSI/TIA-942-C — Telecommunications Infrastructure Standard for Data Centers. Arlington: TIA, 2024.
[4] ASHRAE; IES. ANSI/ASHRAE/IES Standard 202-2024 — The Commissioning Process Requirements for New Buildings and New Systems. Atlanta: ASHRAE, 2024.
[5] ASHRAE. Guideline 0-2019 — The Commissioning Process. Atlanta: ASHRAE, 2019.
[6] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020.
[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018.
[8] FIDIC. Conditions of Contract for EPC/Turnkey Projects. Silver Book. 2. ed. Geneva: International Federation of Consulting Engineers, 2017.
[9] INTERNATIONAL ATOMIC ENERGY AGENCY. Role of the Owner’s Engineer in Project Development and Management. Vienna: IAEA, 2014.
[10] A3A ENGENHARIA. Owner’s Engineering: gobernanza técnica para obras de ingeniería, sistemas críticos e integración multidisciplinaria. Ponta Grossa: A3A Engenharia.
[11] A3A ENGENHARIA. Basis of Design, OPR y URS en proyectos de Data Center. Ponta Grossa: A3A Engenharia.
[12] A3A ENGENHARIA. RFP para Data Center: qué es, cómo elaborarla y qué requisitos incluir. Ponta Grossa: A3A Engenharia.
Preguntas frecuentes
Representa técnicamente al propietario, preserva requisitos, revisa proyectos y propuestas, controla interfaces y cambios, acompaña evidencias y recomienda decisiones de implementación, comisionamiento y aceptación.
No. El proyectista continúa siendo responsable de las soluciones y documentos bajo su autoría. El OE revisa la adherencia a requisitos, riesgos e interfaces sin asumir automáticamente la responsabilidad de diseño.
La fiscalización se concentra en la ejecución y conformidad en campo. El OE posee un alcance más amplio de gobernanza técnica y puede actuar desde requisitos, diseño y contratación hasta pruebas, aceptación y handover.
El OE representa los intereses del propietario y gobierna requisitos, riesgos y decisiones. La autoridad de comisionamiento coordina el proceso de verificación, procedimientos, pruebas, issues e informes.
Es la matriz que identifica quién ejecuta, quién posee autoridad final, quién debe ser consultado y quién necesita ser informado en cada actividad, documento o decisión.
Depende de la delegación formal. El OE puede analizar y recomendar, o aprobar dentro de límites autorizados. Los cambios estratégicos y riesgos relevantes normalmente permanecen bajo la autoridad del propietario.
Preferentemente antes de consolidar los requisitos y las principales RFP. La contratación temprana permite actuar preventivamente sobre arquitectura, interfaces, riesgos, contratos y criterios de aceptación.
Sí. En EPC, protege los requisitos del propietario frente a la entrega integrada. En EPCM o paquetes separados, ayuda a gobernar múltiples interfaces, responsabilidades y proveedores.
Matrices de requisitos, riesgos, RACI e interfaces; dictámenes de diseño; RFP e igualaciones; revisiones de submittals; informes de campo; control de cambios; evidencias de pruebas; pendientes y recomendación de aceptación.
No. El OE reduce riesgos mediante gobernanza, revisión y verificación, pero no controla por sí solo diseño, fabricación, construcción, operación y eventos externos. Las responsabilidades deben definirse contractualmente.
Materiales técnicos complementarios
- 1. Concepto general y aplicación especializada
- 2. Requisitos, viabilidad y decisiones iniciales
- 3. Diseño, RFP y contratación
- 4. Comisionamiento, pruebas y aceptación
- 5. Arquitecturas y modelos de Data Center
- 6. Infraestructura crítica e interfaces
