Puntos clave
- El gobierno heredado rara vez sobrevive intacto a la sustitución de un sistema: los flujos de aprobación, los modelos de acceso y las rutas de escalado suelen romperse y arrastran ineficiencias.
- No todos los controles deben conservarse: algunas configuraciones existen por limitaciones de la plataforma, así que identifica las diferencias antes de la transición para saber cuáles rediseñar y cuáles eliminar.
- El gobierno basado en resultados aguanta los cambios de sistema: define qué debe ocurrir, no cómo lo gestiona una plataforma. Así los controles son portables y más fáciles de mantener en cada sustitución.
- La cobertura de cumplimiento puede romperse sin hacer ruido durante una transición: si el nuevo sistema no genera pruebas de auditoría equivalentes antes de cambiar la plataforma heredada, la brecha solo aparecerá cuando la detecte una auditoría.
Cuando las organizaciones de TI sustituyen sistemas heredados de gestión de TI, el gobierno no es la primera prioridad. Sin embargo, los procesos de aprobación, las estructuras de informes, los controles de acceso y los modelos de cumplimiento se construyen en torno al funcionamiento de esas plataformas y sistemas antiguos. Con el tiempo, dejan de ser meras herramientas y el gobierno acaba dependiendo de cómo funcionan.
La transformación del gobierno de TI tiene que producirse a la vez que la sustitución del sistema, no después. Si no se actualiza el gobierno durante la transición, los equipos terminan reconstruyendo las mismas estructuras de control en el nuevo entorno. Y eso traslada viejas ineficiencias y costes más altos a la plataforma que debía resolverlos.
Cómo abordar la transformación y evolución del gobierno de TI al sustituir sistemas heredados de gestión de TI
Un marco de gobierno para la gestión del cambio da a los responsables de TI una vía concreta para rediseñar controles y responsabilidades mientras se sustituyen los sistemas heredados.
Así moldean los sistemas heredados el gobierno con el tiempo
Entender cómo los sistemas heredados han moldeado el gobierno actual es un primer paso imprescindible antes de empezar cualquier rediseño. Sin eso, es bastante fácil arrastrar las mismas dependencias al nuevo entorno sin darse cuenta.
Estas son algunas de las formas en que las plataformas heredadas moldean el gobierno con el tiempo:
- Flujos de aprobación impuestos por la lógica del sistema: los procesos de aprobación se construyen en torno a lo que permite el sistema heredado, no a lo que necesita la organización. Cuando cambian los sistemas, esos flujos puede que no encajen limpiamente en el nuevo.
- Formatos de informes atados a las salidas heredadas: los equipos se acostumbran a los informes que genera la plataforma heredada. Esos formatos se convierten en el estándar, aunque ya no reflejen lo que resulta útil o necesario.
- Control de acceso basado en limitaciones de la plataforma: los modelos de permisos suelen venir determinados por lo que soportaba el sistema heredado, no por requisitos de seguridad u operativos. Y esos modelos se arrastran salvo que se revisen o sustituyan de forma activa.
- Pruebas de auditoría generadas por herramientas concretas: los procesos de cumplimiento se construyen en torno a las salidas de una herramienta específica. Cuando se sustituye esa herramienta, la pista de auditoría puede romperse si no se tienen en cuenta esas salidas durante el cambio.
- Rutas de escalado definidas por restricciones del sistema: la lógica de escalado queda incrustada en la forma en que la plataforma heredada enruta las incidencias. Los equipos siguen esas rutas sin cuestionar si siguen teniendo sentido.
En definitiva, cuando el gobierno se construye alrededor de una plataforma en lugar de alrededor de las necesidades del negocio, rara vez sobrevive intacto a la sustitución de un sistema.
Identifica los elementos de gobierno ligados a sistemas heredados
Antes de rediseñar nada, los equipos de TI necesitan identificar qué partes del marco de gobierno de TI existente son esenciales y cuáles existen solo porque la plataforma heredada funcionaba de una forma determinada.
Estas son las áreas que conviene revisar en busca de dependencias heredadas:
- Jerarquías de aprobación y puntos de decisión: traza cómo funcionan hoy las aprobaciones e identifica qué pasos responden a la lógica del sistema y no a una política. Son los que más probabilidades tienen de reconstruirse sin necesidad en el nuevo entorno y los que hay que sustituir.
- Modelos de permisos y acceso: revisa cómo se concede y se restringe el acceso actualmente. Por ejemplo, si los modelos de permisos reflejan limitaciones de la plataforma y apenas atienden a los requisitos de seguridad, hay que rediseñarlos en lugar de migrarlos.
- Requisitos de cumplimiento y auditoría: identifica qué controles de cumplimiento dependen de las salidas del sistema heredado. Necesitan una cobertura equivalente en la nueva plataforma antes de retirar la antigua.
- Expectativas y salidas de informes: documenta qué informes se generan y quién los usa, y determina también si son necesarios o no.
- Procesos de gestión de excepciones: revisa cómo se gestionan y aprueban hoy las excepciones. Los procesos que dependen de flujos del sistema heredado quizá no se trasladen bien y haya que reconstruirlos de forma deliberada.
Separar los controles realmente necesarios de las implementaciones propias de una plataforma da a los equipos de TI una imagen más clara de qué debe mantenerse y qué puede simplificarse o eliminarse.
Pasa del control basado en herramientas al gobierno basado en resultados
El gobierno basado en herramientas se rompe cada vez que cambia una plataforma. El gobierno basado en resultados define qué debe ocurrir y se mantiene estable sin importar qué sistema se use para lograrlo.
Algunos ejemplos de cómo se traduce esto en la práctica:
- Garantizar que las aprobaciones se produzcan, con independencia de la plataforma: el requisito es que las aprobaciones ocurran y queden documentadas. Qué sistema gestiona ese proceso es secundario, siempre que el resultado sea coherente y verificable.
- Validar resultados de cumplimiento en lugar de actividad del sistema: las comprobaciones de cumplimiento deben confirmar que los controles exigidos funcionan, lo que hace que el cumplimiento sea portable y coherente entre plataformas.
- Medir el rendimiento del servicio en lugar del uso de la herramienta: las métricas de rendimiento deben reflejar la calidad con la que se prestan los servicios, no centrarse en el uso de una herramienta.
- Exigir responsabilidad en todos los flujos de trabajo: la responsabilidad debe estar vinculada a roles y funciones, no a cómo enrutaba el trabajo un sistema heredado.
Un gobierno definido en torno a resultados, y no a herramientas, es más fácil de mantener, más fácil de auditar y mucho menos propenso a romperse cuando cambian los sistemas subyacentes.
Define estructuras de propiedad y responsabilidad durante la modernización tecnológica
El gobierno puede desmoronarse si no se define la propiedad durante la modernización tecnológica. Si las responsabilidades no se reasignan de forma explícita, hay trabajo que se duplica en unas áreas y que se queda sin hacer en otras.
Estas son las buenas prácticas para definir propiedad y responsabilidad durante la transformación del gobierno de TI:
- Asigna la propiedad por servicio o dominio: cada área de servicio necesita un responsable con nombre y apellidos a cargo de los resultados de gobierno.
- Define la responsabilidad en función de resultados: la responsabilidad debe estar vinculada a entregables, no a cómo asignaba tareas el sistema heredado. Así queda clara incluso cuando los flujos de trabajo cambian a su alrededor.
- Alinea los roles con los flujos actualizados: a medida que se rediseñan los procesos, hay que revisar y actualizar los roles para reflejar cómo circula realmente el trabajo en el nuevo entorno. Los roles diseñados para flujos heredados no encajarán bien en un sistema modernizado.
- Establece una propiedad clara del escalado: define quién se responsabiliza de los escalados en el nuevo entorno antes de completar la transición. Las rutas de escalado que dependían del enrutamiento del sistema heredado hay que reconstruirlas a propósito, no dar por hecho que se trasladan solas.
Una propiedad clara durante la transición mantiene el gobierno operativo cuando el entorno presenta problemas o inestabilidad.
Estandariza los principios de gobierno en todos los sistemas
Un gobierno inconsistente genera brechas difíciles de detectar y aún más difíciles de cerrar. Por eso es clave estandarizar los principios de gobierno en todos los sistemas: así mantienes intacto el modelo de control mientras el entorno cambia a su alrededor.
Áreas clave que hay que estandarizar:
- Definición de políticas y criterios de aplicación: las políticas deben significar lo mismo y aplicarse de la misma manera, sea cual sea el sistema por el que pase un flujo de trabajo.
- Modelos de control de acceso: aplica los mismos estándares de control de acceso en todos los sistemas implicados en la transición. Tener modelos de permisos distintos funcionando en paralelo genera confusión y aumenta el riesgo de brechas de cobertura.
- Métricas y formatos de informes: define un conjunto coherente de métricas y formatos de informes que funcione en todos los sistemas. Así evitas que distintas plataformas den cifras distintas para la misma medida.
- Métodos de validación del cumplimiento: las comprobaciones de cumplimiento deben dar resultados equivalentes sea cual sea el sistema evaluado. Si los métodos de validación varían según la plataforma, las pruebas de auditoría son difíciles de comparar y de sostener.
La estandarización durante la transición es lo que evita que el modelo de gobierno se desmorone a medida que se añaden, sustituyen o retiran sistemas.
Alinea los modelos de cumplimiento y auditoría con los nuevos sistemas
La modernización tecnológica introduce un riesgo de cumplimiento concreto que a los equipos se les escapa con facilidad. Un sistema nuevo puede no generar las pruebas de auditoría igual que lo hacía el antiguo. Si esa brecha no se identifica y se cierra antes de retirar el sistema heredado, la cobertura de cumplimiento se rompe y nadie lo nota hasta que una auditoría lo descubre más adelante.
Pasos para alinear los modelos de cumplimiento y auditoría con los nuevos sistemas:
- Identificar las pruebas de auditoría necesarias: documenta qué pruebas exige cada requisito de cumplimiento y de dónde salen hoy. Así obtienes una lista clara de salidas que el nuevo sistema debe igualar o reemplazar.
- Asegurar que los nuevos sistemas puedan generar salidas equivalentes: verifica que la nueva plataforma puede producir los mismos tipos de pruebas de auditoría antes de apagar el sistema heredado. Si no puede, hay que tener un plan para cubrir esa brecha.
- Actualizar la documentación y las descripciones de los controles: la documentación de cumplimiento que hace referencia a procesos del sistema heredado hay que actualizarla para reflejar cómo funcionan los controles en el nuevo entorno. La documentación desfasada es un hallazgo de auditoría habitual durante las transiciones de sistemas.
- Validar la exactitud de los informes: confirma que los informes que genera el nuevo sistema son exactos y completos antes de usarlos con fines de cumplimiento. Los errores en los primeros informes son más fáciles de detectar y corregir antes de que pasen a formar parte del registro de auditoría.
Alinear el cumplimiento es mucho más difícil cuando la transición ya está hecha. Ese trabajo tiene que ir en paralelo a la sustitución del sistema para evitar brechas que luego cuesta cerrar.
Introduce los cambios de gobierno por fases
Un marco de gobierno para la gestión del cambio funciona mejor cuando los cambios de gobierno se introducen poco a poco en lugar de todos de golpe. Intentar migrar a un nuevo modelo de gobierno al mismo tiempo que a un nuevo sistema aumenta el riesgo de que fallen los dos a la vez.
Estrategias eficaces para una transición de gobierno por fases:
- Mantener en paralelo el modelo de gobierno heredado y el nuevo: deja activos los controles existentes mientras se introducen y validan los nuevos. Así evitas que se abran brechas durante la transición y das tiempo a los equipos a adaptarse antes de retirar el modelo heredado.
- Actualizar poco a poco las estructuras de aprobación e informes: cambia los flujos de aprobación y los formatos de informes de forma incremental en lugar de sustituirlos todos a la vez. Cada actualización debe validarse antes de introducir la siguiente.
- Validar la eficacia de los controles en cada etapa: confirma que los controles funcionan como se espera antes de pasar a la siguiente fase. Los problemas detectados al principio de un despliegue por fases quedan contenidos y se arreglan más fácilmente que los que aparecen tras una migración completa.
- Ajustar según la retroalimentación operativa: recoge la opinión de los equipos que usan el nuevo modelo de gobierno y úsala para afinar el enfoque antes de seguir ampliándolo. Un gobierno que funciona en teoría pero genera fricción en la práctica hay que ajustarlo antes de convertirlo en el estándar.
El cambio de gobierno por fases permite a las organizaciones modernizarse sin poner en riesgo la continuidad del servicio durante la transición.
Evita reproducir los patrones de gobierno heredados
Replicar los patrones de gobierno heredados en un sistema nuevo es algo que pasa con facilidad y sin darse cuenta. Cuando los equipos están bajo presión durante una transición, lo habitual es reconstruir lo que ya conocen en lugar de preguntarse si sigue teniendo sentido.
Señales de alerta de que se están reproduciendo patrones heredados:
- Reconstruir cadenas de aprobación complejas: si el nuevo sistema acaba con los mismos pasos de aprobación que el antiguo, merece la pena preguntarse si cada paso es realmente necesario o si se ha arrastrado por costumbre.
- Mantener capas de control innecesarias: los controles que se añadieron para esquivar limitaciones del sistema heredado no tienen por qué existir en un entorno moderno. Si un control no se puede vincular a un requisito actual, conviene revisarlo para eliminarlo.
- Replicar formatos de informes obsoletos: los informes creados en torno a las salidas heredadas puede que ya no reflejen lo que resulta útil. Reconstruirlos en el nuevo sistema sin revisar su propósito mantiene viejas ineficiencias con otro envoltorio.
- Conservar rutas de escalado ineficientes: las rutas de escalado moldeadas por el enrutamiento del sistema heredado suelen añadir pasos que ralentizan la resolución. La transición es el momento idóneo para simplificarlas, no para replicarlas.
El objetivo de modernizar el gobierno no es trasladar los controles existentes a un sistema nuevo. Es diseñar controles que reflejen lo que la organización necesita de verdad ahora mismo.
Haz que tu transformación del gobierno de TI no deje nada fuera
Sustituir un sistema heredado sin actualizar el gobierno deja a las organizaciones con plataformas modernas gobernadas por controles desfasados. La dependencia no desaparece por sí sola: hay que identificarla, rediseñarla y validarla como parte de la transición.
Por eso las organizaciones tienen que pasar a un gobierno basado en resultados. Además, definir una propiedad clara y estandarizar los controles durante la modernización tecnológica les ayudará a salir del proceso con un modelo mejor y actualizado, a la altura de lo que exigen los entornos de TI de hoy.
Temas relacionados:
