Comprenda cómo aplicar Engineering Change Management (ECM) en proyectos de ingeniería, desde la ECR hasta la aprobación, evaluación de impactos, implementación, control de configuración y trazabilidad.
¡Descúbrelo!
Engineering Change Management (ECM) es el proceso utilizado para identificar, registrar, analizar, decidir, implementar y verificar cambios que afectan la ingeniería de un proyecto. Su objetivo es impedir que cambios en requisitos, planos, especificaciones, equipos, interfaces o métodos de ejecución se incorporen informalmente, sin una evaluación completa de los impactos técnicos, de seguridad, plazo, costo, contratos, documentación y operación.
En este artículo, ECM significa Engineering Change Management, o gestión de cambios de ingeniería. La sigla no se refiere a Enterprise Content Management ni a la gestión del cambio organizacional. El foco está en el control técnico de los cambios que modifican la configuración, las líneas base o los entregables de proyectos de ingeniería.
Un proceso consistente de ECM conecta ingeniería, Project Controls, procurement, contratos, construcción, commissioning y operación. Convierte una necesidad de cambio en una decisión trazable: el cambio se formaliza mediante una solicitud, se analiza por las disciplinas afectadas, se somete a la autoridad competente, se convierte en una instrucción autorizada, se propaga a los documentos y se verifica antes del cierre.
Qué Es Engineering Change Management (ECM) en Proyectos de Ingeniería
Engineering Change Management es una disciplina de gobernanza técnica que controla cambios durante el desarrollo y la implantación de un proyecto. Su alcance comienza cuando una nueva condición, incompatibilidad, oportunidad de mejora o requisito adicional puede modificar la solución aprobada. El proceso termina únicamente cuando la decisión ha sido implementada, verificada, documentada y reflejada en la configuración vigente.
Un cambio puede parecer pequeño en el documento que lo originó y aun así producir efectos sistémicos. Cambiar la potencia de un equipo puede exigir revisar la alimentación eléctrica, protección, cables, ventilación, estructura, automatización, listas de señales, presupuesto, pedido de compra, cronograma, pruebas y procedimientos operativos. ECM existe para identificar estas dependencias antes de liberar el cambio para ejecución.
ECM, Control Integrado, Configuración y Documentos
| Concepto | Función principal | Aplicación en ingeniería |
| Engineering Change Management — ECM | Controlar el ciclo completo del cambio de ingeniería | Requisitos, solución, interfaces, equipos, ejecución y configuración final |
| Control integrado de cambios | Evaluar cambios que afectan el plan y las líneas base | Alcance, plazo, costo, calidad, riesgos, recursos y contratos |
| Gestión de configuración | Mantener bajo control las características funcionales y físicas | Baselines técnicas, ítems de configuración, versiones y estado aprobado |
| Control documental | Administrar emisión, revisión, aprobación y distribución | Planos, memorias, especificaciones, listas y registros |
| Gestión contractual de cambios | Formalizar consecuencias entre las partes | Alcance, precio, plazo, condiciones y responsabilidades |
ECM actúa como puente entre estos sistemas. Un cambio técnico aprobado debe actualizar la configuración; cuando afecta el plan, pasa por el control integrado; cuando cambia obligaciones contractuales, exige el mecanismo previsto en el contrato; y, en todos los casos, debe distribuirse mediante documentos controlados.
ECR, ECN, ECO y CCB
La nomenclatura varía entre organizaciones. Las siglas siguientes son frecuentes, pero el procedimiento del proyecto debe definir los términos adoptados.
| Sigla o término | Significado | Función |
| ECR — Engineering Change Request | Solicitud de cambio de ingeniería | Registrar necesidad, justificación y evaluación inicial |
| ECN — Engineering Change Notice | Notificación de cambio de ingeniería | Comunicar un cambio autorizado o en proceso |
| ECO — Engineering Change Order | Orden de cambio de ingeniería | Autorizar técnicamente la implementación |
| CCB — Change Control Board | Comité de control de cambios | Evaluar y decidir según el nivel de autoridad |
| Change Register | Registro de cambios | Consolidar estado, decisiones, responsables, impactos y plazos |
| Configuration Baseline | Línea base de configuración | Representar el conjunto aprobado de características |
| Change Order | Cambio contractual | Formalizar efectos sobre obligaciones, precio, plazo o condiciones |
ECR y ECO no necesitan ser formularios separados en proyectos pequeños. El requisito esencial es separar solicitar, analizar, autorizar, implementar y verificar, preservando historial, responsabilidades y evidencias.
Por Qué ECM Es Crítico en Proyectos de Ingeniería
Los proyectos de ingeniería son multidisciplinares y progresivos. La definición evoluciona desde la viabilidad hasta el detalle, mientras decisiones sucesivas comprometen recursos, contratos, equipos y obra. Cuanto más tarde ocurre un cambio, mayor tiende a ser la cantidad de elementos dependientes de la configuración anterior.
En fases iniciales, un cambio puede exigir solo un nuevo análisis. Después de procurement, puede exigir renegociación con proveedores. Durante la ejecución, puede provocar retrabajo, pérdida de productividad o paralización. Cerca del commissioning, puede invalidar pruebas y evidencias de aceptación. Esta relación debe tratarse junto con el ciclo de vida del proyecto.
Los Cambios Deben Controlarse, No Evitarse.
El valor de ECM está en permitir que los cambios necesarios avancen con un análisis proporcional, autoridad definida, comunicación completa y verificación de la implementación.
Comprenda Cómo el Ciclo de Vida Cambia el Costo y el Riesgo de los Cambios
Qué Cambios Deben Entrar en el Proceso de ECM
Debe entrar en ECM cualquier cambio capaz de modificar un requisito aprobado, desempeño esperado, solución técnica, interfaz, ítem de configuración, línea base, condición de seguridad, obligación contractual o información utilizada para fabricar, adquirir, instalar, probar, operar o mantener el sistema.
No toda corrección editorial necesita análisis multidisciplinario. Sin embargo, clasificar un cambio como «solo revisión de plano» sin examinar su contenido es un error. El criterio debe ser el efecto potencial del cambio, no el formato del documento.
Orígenes de los Cambios de Ingeniería
Los cambios pueden originarse en el propietario, diseñador, proveedor, constructor, operador, supervisión, autoridad reguladora o condición de campo. Entre los principales desencadenantes están:
- modificación de requisitos del propietario o usuario;
- corrección de error, omisión, conflicto o incompatibilidad;
- necesidad identificada en análisis de riesgo o seguridad;
- cambio normativo, regulatorio o de licenciamiento;
- indisponibilidad o sustitución de equipo;
- ingeniería de valor o mejora de constructibilidad;
- condición de campo distinta de la información de diseño;
- interferencia entre disciplinas o sistemas;
- cambio de proveedor, tecnología, material o método;
- resultado de inspección, FAT, SAT o commissioning;
- restricción de plazo, presupuesto, logística u operación;
- RFI, no conformidad o pendiente cuya solución modifica la ingeniería.
Una RFI puede aclarar sin cambiar; una no conformidad puede corregirse conforme al diseño; un riesgo puede tratarse sin modificar la baseline. Cuando la respuesta modifica la solución aprobada, el caso debe vincularse a un cambio controlado.
Clasificación por Naturaleza
| Clase | Ejemplo | Análisis normalmente requeridos |
| Requisito | Nueva capacidad, disponibilidad o condición operativa | Business case, arquitectura, validación y aceptación |
| Técnica | Cambio de dimensionamiento, topología o especificación | Cálculos, compatibilidad, seguridad y desempeño |
| Configuración | Sustitución de componente, material, firmware o modelo | Equivalencia, interoperabilidad, documentación y mantenimiento |
| Interfaz | Cambio en los límites entre disciplinas o proveedores | Responsabilidades, conexiones, datos, secuencia y pruebas |
| Constructiva | Cambio de método, acceso, secuencia o montaje | Constructibilidad, seguridad, recursos, plazo y calidad |
| Regulatoria | Nuevo requisito legal, normativo o ambiental | Conformidad, licencias y evidencias |
| Contractual | Inclusión, exclusión o modificación de una obligación | Alcance, precio, plazo, riesgos y notificaciones |
| Operativa | Cambio en operación, mantenimiento o contingencia | Procedimientos, capacitación, disponibilidad y activos |
| Emergencia | Acción inmediata para controlar un riesgo grave | Autorización excepcional, control temporal y regularización |
Un mismo cambio puede pertenecer a varias clases. La sustitución de un equipo puede modificar interfaces, consumo eléctrico, disipación térmica, protocolo, plazo, costo, garantía y repuestos.
Cambio, Desviación, No Conformidad y Revisión
| Registro | Característica | Cuándo activar ECM |
| Cambio | Propone cambiar una condición o baseline aprobada | Siempre |
| Desviación | Registra un alejamiento del requisito o plan | Cuando su aceptación cambia la configuración aprobada |
| No conformidad | Evidencia incumplimiento de un requisito | Cuando la disposición no sea simplemente corregir conforme a la baseline |
| RFI | Solicita aclaración | Cuando la respuesta introduzca un cambio técnico |
| Pendiente | Registra una acción o decisión abierta | Cuando la solución modifique requisito o configuración |
| Revisión documental | Nueva versión del documento | Cuando se modifique el contenido técnico |
| Redline | Registra una condición propuesta o ejecutada | Cuando difiera del documento liberado |
| Corrección editorial | Ajuste sin efecto técnico | Normalmente solo control documental |
La distinción evita burocratizar correcciones simples y, al mismo tiempo, impide que cambios relevantes se ejecuten como aclaraciones o ajustes de campo.
Materialidad y Fase del Proyecto
Un cambio es material cuando afecta función, seguridad, conformidad, interfaces, presupuesto, camino crítico, equipos comprometidos, trabajo ejecutado, pruebas, operación o documentos liberados.
| Fase | Impacto predominante | Control recomendado |
| Viabilidad y FEL | Premisas, beneficios, CAPEX y riesgos | Actualizar business case y decisión de continuidad |
| Diseño Conceptual | Arquitectura, capacidad e interfaces | Comparar alternativas y criterios de selección |
| FEED y Diseño Básico | Requisitos, bases, especificaciones y estimaciones | Análisis multidisciplinario y madurez para contratación |
| Diseño Ejecutivo | Cálculos, detalles, listas y coordinación | Control riguroso de configuración |
| Procurement | Requisiciones, equipos, fabricación y entrega | Evaluar compromisos y proveedores |
| Ejecución | Campo, método, retrabajo, seguridad y productividad | Aprobar antes de la ejecución, salvo emergencia |
| Commissioning | Pruebas, lógica, desempeño y evidencias | Revalidar procedimientos y criterios |
| Cierre | Configuración real y documentación final | Actualizar As-Built, manuales y registros |
Los contenidos sobre FEED, Diseño Básico y Diseño Ejecutivo detallan la evolución de la madurez. ECM debe impedir que decisiones tardías se traten como si el proyecto todavía estuviera en fase conceptual.
El Impacto del Cambio Aumenta con el Compromiso del Proyecto.
Un cambio aún conceptual puede exigir solo un nuevo análisis; después de la contratación, fabricación o ejecución, la misma decisión puede generar retrabajo, replanificación, renegociación y repetición de pruebas.
Profundice en Cómo Project Controls Mide Impactos en Plazo, Costo y Baseline
Cómo Funciona el Flujo de Solicitud, Análisis y Aprobación
Un flujo de ECM debe ser suficientemente formal para proteger la configuración y suficientemente ágil para no paralizar decisiones. La estructura recomendada separa identificación, registro, triaje, análisis integrado, decisión, autorización, implementación y verificación.
ECR: Identificación y Registro
La necesidad debe registrarse antes de incorporarla a los documentos o a la obra. La ECR recibe un código único y relaciona origen, solicitante, fecha, disciplina, ítem afectado, condición actual, propuesta, justificación, urgencia y evidencias.
La codificación puede reflejar proyecto, sistema y secuencia, como PRJ-ECM-ECR-001. El código permanece estable aunque el cambio resulte en varios documentos u órdenes.
Triaje y Alternativas
El triaje confirma si el caso es un cambio, verifica duplicidades, define prioridad, identifica disciplinas y selecciona el flujo. Puede devolver una solicitud incompleta o vincularla a una RFI, no conformidad, riesgo, contrato o pendiente.
Los cambios relevantes no deben llegar a decisión con una única solución asumida. La ingeniería debe comparar alternativas, incluso mantener la configuración vigente, explicitando requisitos cumplidos, riesgos, interfaces, costo, plazo, reversibilidad e implicaciones operativas.
Análisis Integrado de Impacto
Cada área afectada registra su evaluación en una base común. El coordinador consolida contribuciones, evidencia divergencias y confirma si se consultaron las interfaces. La matriz RACI define participación, pero no sustituye niveles de autoridad técnicos, financieros o contractuales.
Decisión y ECO
Las decisiones deben estandarizarse: aprobada, aprobada con condiciones, rechazada, devuelta, suspendida, transferida a una fase futura o cancelada. El registro debe presentar la versión analizada, participantes, justificación y condicionantes.
La aprobación debe convertirse en una instrucción ejecutable. La ECO — Engineering Change Order — define la alternativa autorizada, documentos e ítems afectados, responsables, plazo, restricciones, verificaciones, efectos en las baselines y vínculo con un eventual change order contractual.
Implementación y Cierre
El estado «aprobada» no significa «implementada». La implementación incluye revisión de ingeniería, emisión documental, adquisición, fabricación, obra, parametrización, pruebas y comunicación. Cuando involucra varios paquetes, el cambio puede descomponerse y vincularse a la WBS.
El cierre confirma documentos vigentes, retirada de versiones obsoletas, coherencia de materiales y equipos, ejecución de pruebas, actualización de contratos y baselines, As-Built, manuales, registros y comunicación a las partes interesadas.
Checklist Mínimo de una ECR
- ☐ Identificación única y fecha
- ☐ Solicitante, origen y responsable
- ☐ Condición actual
- ☐ Cambio propuesto
- ☐ Justificación y beneficio esperado
- ☐ Requisitos e ítems afectados
- ☐ Documentos, contratos y activos relacionados
- ☐ Disciplinas e interfaces involucradas
- ☐ Criticidad y urgencia
- ☐ Alternativas consideradas
- ☐ Impactos preliminares
- ☐ Anexos y evidencias
- ☐ Decisión requerida y plazo
Cambios de Emergencia
Una emergencia puede justificar una acción inmediata cuando existe riesgo grave para las personas, el medio ambiente, el activo, la continuidad o la conformidad. Esto no elimina ECM; solo cambia la secuencia. El flujo de emergencia debe definir autoridad, límite de intervención, controles temporales, preservación de evidencias, plazo de regularización, verificación y actualización de la configuración definitiva.
Aprobación No Significa Cierre.
El cambio solo puede cerrarse cuando los documentos vigentes, la condición ejecutada, las pruebas, los registros y la comunicación a operación sean coherentes con la decisión autorizada.
Vea Cómo el As-Built Consolida la Configuración Efectivamente Implantada
Cómo Evaluar Impactos Técnicos, Contractuales, de Plazo y Costo
El análisis de impacto es el núcleo de ECM. Decidir únicamente por el costo directo puede ignorar incompatibilidades, retrabajo, retrasos, pérdida de productividad, nuevas pruebas, obligaciones contractuales y consecuencias operativas.
| Dimensión | Preguntas principales | Evidencias típicas |
| Requisitos | ¿Se siguen cumpliendo la función, capacidad y aceptación? | Matriz de requisitos, Basis of Design y cálculos |
| Seguridad | ¿El cambio introduce riesgo o modifica la conformidad? | Análisis de riesgo, dictámenes y aprobaciones |
| Ingeniería | ¿Qué disciplinas, cálculos e interfaces cambian? | Lista de documentos y análisis multidisciplinario |
| Constructibilidad | ¿La solución puede ejecutarse en las condiciones disponibles? | Método, campo, recursos y secuencia |
| Procurement | ¿Afecta al proveedor, pedido, fabricación o logística? | Requisiciones, pedidos y fechas comprometidas |
| Plazo | ¿Afecta lógica, camino crítico, holguras o hitos? | Cronograma, fragnet y análisis de camino |
| Costo | ¿Qué costos directos, indirectos y de ciclo de vida surgen? | Estimación, cotizaciones y forecast |
| Contrato | ¿Modifica obligación, precio, plazo o riesgo? | Contrato, notificaciones y dictamen administrativo |
| Pruebas | ¿Invalida inspecciones, FAT, SAT o aceptación? | ITP, protocolos y registros |
| Operación | ¿Afecta capacitación, mantenimiento o continuidad? | Manuales y análisis operativo |
| Configuración | ¿Qué baselines y documentos deben actualizarse? | Matriz de propagación y lista maestra |
| Riesgos | ¿Qué riesgos se introducen o eliminan? | Registro de riesgos y respuestas |
La gestión de riesgos en proyectos de ingeniería debe actualizarse. Riesgo y cambio no son sinónimos: riesgo es incertidumbre; cambio es una alteración propuesta u ocurrida. Un cambio puede ser respuesta a un riesgo y también generar nuevos riesgos.
Plazo, Costo e Impacto Acumulativo
El análisis de plazo debe insertar el cambio en el cronograma vigente y evaluar lógica, recursos, procurement, holgura, camino crítico, hitos, mitigación y aceleración. El cronograma físico-financiero muestra por qué plazo, medición y costo no pueden evaluarse por separado.
La estimación debe declarar alcance, premisas, exclusiones, fecha base, fuentes y grado de definición. Puede incluir ingeniería, materiales, cancelación de pedidos, fabricación, logística, mano de obra, supervisión, movilización, retrabajo, pruebas, permanencia, productividad y ciclo de vida.
El impacto directo pertenece al trabajo modificado. El indirecto deriva del efecto sobre otras actividades. El impacto acumulativo surge cuando varios cambios producen un efecto combinado que no puede atribuirse a una única alteración. Pequeños cambios sucesivos pueden fragmentar frentes, reducir productividad y consumir capacidad de ingeniería.
Cambio Técnico, Change Order y Claim
Un cambio de ingeniería no es automáticamente un cambio contractual. Primero se identifica y analiza la necesidad técnica; después se verifican responsabilidades, se cuantifican efectos y se aplica el mecanismo contractual.
Cuando existe acuerdo, el efecto puede formalizarse mediante change order, adenda, orden de servicio o instrumento equivalente. Cuando existe desacuerdo sobre derecho, responsabilidad, precio o plazo, el caso puede evolucionar hacia un claim. El contenido sobre EPC y EPCM ayuda a comprender la asignación de riesgos.
La aprobación técnica no sustituye la autorización comercial y la aprobación comercial no exime de validación técnica.
Cuándo Revisar la Baseline
No todo cambio justifica un rebaseline. Cambiar la referencia únicamente para eliminar desviaciones destruye la memoria del desempeño. La revisión es apropiada cuando un cambio formalmente autorizado vuelve inadecuada la baseline anterior al cambiar alcance, presupuesto, plazo, hitos o estrategia.
El historial debe preservarse. El sistema distingue baseline original, revisiones autorizadas, cronograma vigente y forecast. La Gestión del Valor Ganado depende de esta disciplina.
El Rebaseline Exige Decisión Formal e Historial Preservado.
Una nueva línea base debe reflejar un cambio autorizado que haya modificado materialmente alcance, plazo, presupuesto o estrategia, sin borrar la referencia original ni transformar una desviación en desempeño planificado.
Comprenda Cómo la Gestión del Valor Ganado Depende de Baselines Confiables
Cómo Aplicar Change Control en una Gestión Ágil o Híbrida
Un enfoque ágil o híbrido no elimina Engineering Change Management. Lo que cambia es la velocidad de descubrimiento, calificación y encaminamiento del cambio. Ideas, pendientes, requisitos emergentes y alternativas pueden refinarse en ciclos cortos; sin embargo, cuando un cambio afecta baseline, requisito aprobado, configuración, contrato, seguridad, costo o plazo, debe atravesar la gobernanza formal correspondiente.
PMBOK Guide 8ª edición trata tailoring y enfoques híbridos como parte de la arquitectura normal de gestión. Para Ingeniería, esto significa separar dos capas: una capa adaptativa para explorar y calificar trabajo aún no autorizado y una capa formal de decisión para cambios que alteran compromisos aprobados. Esta separación se detalla en la arquitectura de gestión ágil e híbrida de proyectos de Ingeniería.
| Situación | Tratamiento recomendado | Control necesario |
| idea o hipótesis técnica | refinamiento, estudio o backlog | registro y responsable |
| aclaración sin impacto material | flujo operativo rápido | trazabilidad documental |
| cambio que afecta interfaz o requisito | análisis integrado de impacto | ECR/CCB o workflow equivalente |
| cambio en baseline, contrato o presupuesto | decisión formal antes de la ejecución | change control, nivel de autoridad e historial |
| emergencia de campo | flujo excepcional previamente definido | autoridad, límite, evidencia y regularización posterior |
Un Backlog de Cambio No Es Autorización de Cambio
Un backlog de proyecto puede organizar solicitudes, alternativas, estudios y pendientes antes de la decisión. No sustituye la ECR, el CCB, la orden de cambio ni ningún mecanismo formal exigido por el contrato y la gobernanza. El ítem puede estar priorizado en el backlog y aun así permanecer no autorizado para implementación.
Esta separación evita uno de los principales riesgos de una adopción superficial de métodos ágiles: confundir la capacidad de reaccionar rápidamente con el permiso para cambiar una referencia aprobada sin análisis de impacto.
El Change Control Híbrido Debe Acelerar el Triaje, No Reducir el Rigor
La ganancia del enfoque híbrido está en reducir tiempo muerto. Gestión visual, Kanban, clases de servicio, aging y cadencias cortas pueden hacer más visibles los cambios pendientes y acelerar la recopilación de información. La decisión formal continúa siendo proporcional a la materialidad: una corrección documental simple no necesita recorrer el mismo rito que un cambio que modifica CAPEX, plazo contractual, seguridad funcional o configuración de campo.
Por ello, ECM híbrido combina gestión de flujo con gobernanza de cambios. La primera reduce cola y aging; la segunda protege baseline, responsabilidad y trazabilidad.
Cómo Controlar Configuración, Documentos e Implementación
ECM solo produce resultados cuando la decisión llega a todos los elementos afectados. El cambio no termina en el acta del CCB ni con la emisión de un plano. Es necesario controlar requisitos, documentos, materiales, equipos, software, parámetros, obra y registros de operación.
Ítems de Configuración y Baselines
Un ítem de configuración es un elemento controlado porque sus características deben identificarse, aprobarse y rastrearse. Puede ser un requisito, sistema, equipo, componente, software, lógica, parámetro, interfaz, documento, modelo o conjunto instalado.
La baseline de configuración representa el estado aprobado. Puede ser funcional, de diseño, fabricación, construcción o As-Built. El procedimiento define cuándo se establece, quién la aprueba y qué cambios exigen control formal.
Matriz de Propagación Documental
| Elemento modificado | Documentos potencialmente afectados |
| Requisito funcional | URS, OPR, Basis of Design, matriz de requisitos y aceptación |
| Capacidad o carga | Memorias, balances, diagramas, listas y especificaciones |
| Equipo | Hoja de datos, requisición, materiales, planos y mantenimiento |
| Disposición física | Planos, secciones, soportes, accesos y seguridad |
| Alimentación eléctrica | Unifilar, demanda, cables, protección y selectividad |
| Automatización | Narrativa, I/O, causa y efecto, software y pruebas |
| Comunicaciones | Arquitectura, direccionamiento, protocolos y ciberseguridad |
| Método de ejecución | Procedimiento, riesgo, planificación e inspección |
| Criterio de prueba | ITP, FAT, SAT, commissioning y aceptación |
| Condición operativa | Manual, capacitación, mantenimiento y registro del activo |
En proyectos BIM, la serie ISO 19650 ayuda a la gestión de la información, pero ECM también se aplica sin BIM.
Estados de la Información y Paquete de Implementación
El sistema debe distinguir estados como elaboración, análisis, aprobado, liberado para adquisición, fabricación o construcción, cancelado, sustituido y As-Built. No puede haber duda sobre qué versión es válida para cada finalidad.
Los cambios relevantes deben generar un paquete con ECO, planos, memoria de análisis, método, seguridad, materiales, responsabilidades, ventana, inspección, pruebas, rollback cuando corresponda y criterios de conclusión.
Campo, Redlines y Commissioning
El equipo de campo no debe cambiar la solución por conveniencia sin autorización. Los redlines documentan una condición propuesta o ejecutada, pero no constituyen aprobación automática. La configuración final debe consolidarse en el As-Built.
Los cambios posteriores a las pruebas pueden invalidar evidencias. El commissioning debe indicar qué verificaciones deben repetirse y cómo el cambio afecta la aceptación técnica.
El cierre debe separar conclusión física, documental, técnica, contractual y comunicación a operación.
La Configuración Autorizada Debe Llegar al Campo.
Planos, listas, parámetros, equipos, software, procedimientos y registros de prueba deben representar la misma solución aprobada; las divergencias entre documento e instalación mantienen el cambio abierto.
Profundice en Cómo el Commissioning Verifica Cambios Antes de la Aceptación
Cómo Estructurar Gobernanza, Indicadores y Auditoría de ECM
La gobernanza define política, roles, niveles de autoridad, criterios, flujo, información y supervisión. ECM debe integrarse a los procesos y la gobernanza, no operar como un registro paralelo desconectado de documentos, cronograma, costos y contratos.
Política, CCB y Niveles de Autoridad
La política establece principios y responsabilidades; el procedimiento describe tipos, materialidad, urgencia, estado, documentación, roles, niveles de autoridad, plazos, CCB, integraciones, rebaseline, emergencia, indicadores y auditoría.
El CCB evalúa cambios por encima de los niveles de autoridad delegados o con impacto multidisciplinario relevante. Puede incluir propietario, gerente, ingeniería, Project Controls, contratos, procurement, construcción, commissioning, operación, seguridad y calidad. La matriz debe indicar quién recomienda, quién decide y quién es consultado.
Los niveles de autoridad pueden considerar seguridad, requisito, valor, plazo, camino crítico, disciplinas, contratos, parada, reversibilidad y exposición operativa. Un cambio de seguridad o conformidad no debe simplificarse únicamente porque tenga bajo costo.
Roles Recomendados
| Rol | Responsabilidad principal |
| Solicitante | Registrar necesidad e información inicial |
| Coordinador de ECM | Administrar flujo, plazos e integración |
| Líder técnico | Desarrollar alternativas y consolidar ingeniería |
| Disciplinas afectadas | Evaluar interfaces y consecuencias |
| Project Controls | Analizar plazo, costo, baseline y forecast |
| Procurement | Evaluar proveedores, pedidos y logística |
| Contratos | Verificar obligaciones, change orders y claims |
| Construcción | Evaluar campo, método, seguridad y retrabajo |
| Commissioning | Evaluar pruebas y criterios de aceptación |
| Operación | Evaluar mantenimiento, capacitación y activos |
| CCB o autoridad | Aprobar, rechazar o condicionar |
| Verificador | Confirmar implementación y cierre |
En proyectos con Owner’s Engineering, la función puede incluir análisis independiente, consolidación de impactos, verificación de evidencias y apoyo a la decisión del propietario, sin sustituir responsabilidades de diseñadores, proveedores y ejecutores.
Indicadores
| Indicador | Qué revela |
| Cambios abiertos por estado | Volumen y cuellos de botella |
| Antigüedad del backlog | Riesgo de decisiones retenidas |
| Tiempo entre ECR y decisión | Eficiencia del análisis |
| Tiempo entre aprobación e implementación | Capacidad de ejecución |
| Solicitudes devueltas | Calidad de las entradas |
| Cambios de emergencia | Exposición y madurez de la planificación |
| Cambios sin autorización | Falla grave de control |
| Impacto en costo y plazo | Consecuencia acumulada |
| Origen y disciplina | Fuentes de inestabilidad |
| Reapertura | Calidad de la implementación |
| Pendiente documental | Divergencia de configuración |
| Repetición de causas | Efectividad de las lecciones aprendidas |
Auditoría, Errores y Madurez
La auditoría debe permitir reconstruir origen, baseline, análisis, decisión, instrucción, revisiones, ejecución, pruebas, impactos y cierre. El assurance independiente es útil en cambios críticos, rebaseline relevante, disputas o cambios próximos a la aceptación.
Los errores recurrentes incluyen ejecutar antes de aprobar, analizar solo la disciplina originadora, ignorar procurement y operación, estimar solo costo directo, cambiar la baseline para eliminar variación, cerrar sin verificar campo y no actualizar As-Built o manuales.
| Nivel | Características |
| Reactivo | Cambios identificados después de la ejecución y registros dispersos |
| Controlado | Formulario, registro y aprobación básica |
| Integrado | Ingeniería, plazo, costo, riesgo, contratos y configuración conectados |
| Gestionado | Niveles de autoridad, indicadores, auditoría y análisis de causas |
| Optimizado | Datos históricos, prevención, automatización y mejora continua |
La implantación puede comenzar de forma simple, siempre que preserve los controles esenciales. Un formulario complejo no compensa una autoridad indefinida ni la ausencia de verificación. Las causas recurrentes deben alimentar lecciones aprendidas.
Un ECM Maduro Integra Ingeniería, Controles y Gobernanza.
La madurez no está en la complejidad del formulario, sino en la capacidad de relacionar decisión técnica, impactos, responsabilidades, baselines, contratos, implementación y evidencias de cierre.
Conozca la Actuación de A3A Engenharia en Owner’s Engineering
Referencias Técnicas
[5] AACE INTERNATIONAL. Recommended Practice 10S-90: Cost Engineering Terminology.
[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Information management using BIM.
[8] FIDIC. Conditions of Contract for EPC/Turnkey Projects. 2. ed. Silver Book, 2017.
[9] FIDIC. Client/Consultant Model Services Agreement. 5. ed. White Book, 2017.
Preguntas Frecuentes
Es el proceso de identificar, registrar, analizar, aprobar, implementar y verificar cambios que afectan requisitos, configuración, documentos, equipos, interfaces o ejecución de un proyecto de ingeniería.
ECR es la solicitud que describe y justifica el cambio. ECO es la autorización para implementar la alternativa aprobada. La nomenclatura varía, pero solicitar y autorizar deben permanecer separados.
CCB es el comité o instancia de gobernanza que evalúa cambios relevantes y recomienda, aprueba, condiciona o rechaza su implementación según los niveles de autoridad.
No. Las correcciones editoriales pueden permanecer en el control documental. Las revisiones que modifican requisitos, solución, interfaces, configuración, fabricación, construcción, pruebas u operación deben evaluarse mediante ECM.
No. ECM controla el cambio técnico y sus impactos. Un change order es un instrumento contractual cuando el cambio modifica obligaciones, precio, plazo o condiciones.
Mediante un flujo excepcional que defina autoridad, límite de intervención, controles temporales, evidencias, plazo de regularización, verificación posterior y actualización de la configuración.
Cuando un cambio autorizado modifica de forma relevante alcance, presupuesto, plazo, hitos o estrategia y vuelve inadecuada la baseline anterior. El historial debe preservarse.
No. El proceso puede comenzar con registros controlados. Los proyectos complejos se benefician de plataformas que relacionen cambios con requisitos, documentos, cronograma, costos, contratos, riesgos y configuración.
Materiales Técnicos Complementarios
Whitepapers
- Owner’s Engineering: framework executivo para contratação, governança e aceite
- Projeto: o investimento que reduz riscos, custos e retrabalho
Artículos Técnicos
- Proyectos de Ingeniería
- Ciclo de Vida del Proyecto
- Project Controls
- Procesos y Gobernanza en Proyectos de Ingeniería
- Gestión de Riesgos en Proyectos de Ingeniería
- Procurement en Proyectos de Ingeniería
- Ejecución de Obras de Ingeniería
- As-Built en Ingeniería
Guías Técnicas
- Gestión de Proyectos: Guía Completa para Ingeniería, Gobernanza y Control
- Guía Completa sobre Ingeniería Consultiva
Servicios Relacionados
- Gestión de Proyectos: Owner’s Engineering desde el Inicio hasta la Aceptación Técnica
- Gestión de Proyectos: Cronograma, Costos y Valor Ganado
- EPCM: Gestión Integrada de la Implantación
