En los proyectos, los “requerimientos” y los “cambios” suelen mezclarse, aunque representan dos perspectivas distintas sobre el mismo estado objetivo. Los requerimientos definen el estado futuro de un sistema o proceso. Describen lo que debe existir en la solución objetivo, independientemente del estado actual. Los cambios, en cambioCualquier cambio planificado o aprobado en un sistema, proceso o unidad organizativa, ya sea técnico, organizativo o de procesos., definen la desviación del estado actual — el ajuste concreto necesario para alcanzar o modificar el estado objetivo. Esta distinción es esencial porque separa la definición funcional del estado objetivo del trabajo técnico u organizativo necesario para lograrlo.

1.1. Requerimientos como definición del estado objetivo

Un requerimiento describe lo que un sistema debe ofrecer en la solución objetivo. Surge normalmente en las fases tempranas del proyecto y es neutral respecto a la solución. Los requerimientos definen el alcance, las expectativas funcionales y los criterios que se aceptarán más adelante en el UAT. No son reactivos, sino orientados a la planificación. Un requerimiento como “El sistema debe soportar cuatro idiomas” describe únicamente el estado objetivo, no el trabajo necesario para alcanzarlo.

1.2. Cambios como ajustes del estado actual

Un cambio siempre surge de la diferencia entre el estado actual y el estado objetivo. Si un sistema ya soporta ruso y español, pero la solución objetivo requiere cuatro idiomas, el cambio consiste en añadir inglés y francés. El cambio es, por tanto, el ajuste concreto del estado actual, no la definición abstracta del estado objetivo. Los cambios surgen de nuevos conocimientos, restricciones técnicas, requisitosRequisitos que pueden dar lugar a cambios regulatorios o defectos y tienen impacto directo en el cronograma, el presupuesto, las pruebas y el cutover(i) Fase del modelo de 5 fases: ejecución de la transición a producción; incluye la conmutación técnica y la implementación operativa. (ii) Transición puntual de un proyecto al entorno de producción. (iii) Fase de transición a producción de un sistema de TI, a menudo bajo presión de tiempo y con un alto nivel de coordinación..

El User Acceptance Test (UAT) es la aceptación del estado objetivo. No prueba el cambio en sí, sino el resultado del cambio. Aunque el sistema ya soportara ruso y español, estos idiomas deben probarse nuevamente en el UAT porque el UAT acepta el estado objetivo completo. Por lo tanto, el UAT no prueba solo los nuevos idiomas inglés y francés, sino los cuatro idiomas, ya que el requerimiento define cuatro idiomas. El UAT no es una prueba de cambios, sino una prueba de requerimientos. Confirma que el estado objetivo se ha alcanzado completamente — independientemente de cuántos cambios hayan sido necesarios.

2.1. La regresión como parte integral del UAT

Volver a probar funcionalidades existentes es una consecuencia lógica de la aceptación del estado objetivo. Cualquier cambio puede afectar funcionalidades existentes, ya sea mediante nuevas configuraciones, nuevos modelos de datos, nuevos elementos de interfaz o nuevas lógicas de traducción. El UAT no prueba la historia; prueba el estado objetivo — y este estado objetivo incluye todas las funcionalidades, no solo las partes modificadas.

Los requerimientos definen el estado objetivo, pero no generan trabajo. Solo la desviación del estado actual — el cambio — genera esfuerzo, necesidad de recursos, impacto en el cronograma y presupuesto. Por eso los proyectos no planifican “requerimientos”, sino “cambios”. La planificación del proyecto responde a la pregunta: “¿Qué debemos hacer para alcanzar el estado objetivo?” Y esta pregunta solo puede responderse en función de los cambios, no de los requerimientos.

En la lógica clásica de PMI, un change request es una modificación del alcance aprobado. PMI considera los cambios exclusivamente como cambios de alcance y no diferencia entre cambios de requerimientos y cambios de solución. Para PMI, cada cambio es una modificación del alcance del proyecto, independientemente de si se origina por nuevos requerimientos funcionales, restricciones técnicas, exigencias regulatorias o defectos. Esta perspectiva es suficiente para la gestión de proyectos tradicional, pero no refleja la complejidad de las soluciones modernas.

En los proyectos reales no existe una relación lineal entre requerimientos y cambios. Siempre es una relación n:n: un requerimiento puede generar varios cambios, y un cambio puede afectar varios requerimientos. Un requerimiento puede no requerir ningún cambio si el estado actual ya coincide con el estado objetivo. Un cambio puede surgir sin un requerimiento, por ejemplo debido a exigencias regulatorias o defectos. El requirement‑to‑change mapping hace visibles estas relaciones y proporciona la base para que los cambios sean trazables, comprobables y gobernables.

El mapeo muestra qué cambios concretos son necesarios para implementar un requerimiento y qué requerimientos se ven afectados por un cambio. Forma la base para el análisis de impacto, la planificación de pruebas y la evaluación del cutover. Sin mapeo, la conexión entre el estado objetivo y los ajustes del estado actual permanece invisible — y también los riesgos, dependencias y regresiones.

En ITILMarco para la gestión de servicios de TI con procesos definidos., el Change Advisory Board (CAB)Comité de gobernanza para la evaluación y aprobación de cambios, especialmente aquellos relevantes para la productividad o la seguridad. está destinado a evaluar cambios — las desviaciones del estado actual necesarias para alcanzar o ajustar el estado objetivo. En la práctica, sin embargo, en el CAB a menudo se presentan requerimientos en lugar de cambios. El CAB discute definiciones funcionales del estado objetivo, aunque debería evaluar el impacto de los cambios concretos. La razón es simple: el requirement‑to‑change mapping rara vez se realiza. Cuando no está claro qué cambios surgen de un requerimiento, el CAB no tiene más opción que evaluar el requerimiento mismo.

Como resultado, el CAB pierde su función real como órgano de gobernanzaControl estructurado y lógica de decisión para el cutover, incluyendo roles, reglas y canales de comunicación. de cambios de solución y se convierte en un comité de revisión de alcance — similar a la lógica clásica de PMI. Los riesgos, dependencias, regresiones y efectos en el cutover permanecen invisibles porque los cambios no se documentaron explícitamente.

La Change Governance Matrix (ChGM)(i) Instrumento estratégico de control para el registro, la evaluación y la aprobación de cambios, incluyendo la lógica RACI y las dimensiones de relevancia. (ii) Marco para el control de los dominios de cambio separa claramente estas capas. Trata los requerimientos como la definición del estado objetivo y los cambios como desviaciones del estado actual. Solo mediante el requirement‑to‑change mapping se hace visible qué cambios concretos son necesarios para implementar un requerimiento y qué impactos tienen estos cambios. El CAB entonces evalúa no el requerimiento, sino los cambios que surgen de él. La ChGM proporciona la estructura que PMI y muchos métodos clásicos de proyectos no ofrecen. Operacionaliza la conexión entre el estado objetivo y los ajustes del estado actual y hace transparente la relación n:n entre requerimientos y cambios.

Los requerimientos definen el estado objetivo. Los cambios definen la desviación del estado actual. La planificación del proyecto se basa en los cambios porque representan el trabajo real. El UAT prueba los requerimientos porque acepta el estado objetivo. PMI considera los cambios como cambios de alcance y no diferencia entre cambios de requerimientos y cambios de solución. La Change Governance Matrix (ChGM) va más allá: gobierna los cambios a nivel de solución y utiliza el requirement‑to‑change mapping para hacer transparente y manejable la relación n:n entre el estado objetivo y los ajustes del estado actual. Esto permite que el CAB cumpla su función prevista: evaluar y gobernar los cambios a nivel de solución.

La matriz de gobernanza de cambios está disponible (i) como producto digital y (ii) se describe en el libro “SAP Cutover Management“, escrito por Guido Nageldinger.