Transformación digital y cultural en organizaciones
Cuando trabajamos en la implementación o modernización de un sistema crítico, hay una condición que atraviesa todo el proyecto: mientras se construye o adapta la nueva solución, la organización tiene que seguir funcionando.
Las operaciones continúan, la información sigue cambiando y los usuarios necesitan trabajar todos los días. Por eso, pasar de un sistema a otro no es solamente un desafío tecnológico. También implica planificar cómo hacer esa transición sin perder información, continuidad ni control.
En proyectos de este tipo, llegar a producción requiere coordinar distintos frentes que avanzan en paralelo y tomar decisiones sobre qué tiene que estar listo para salir, quiénes deben participar y qué puede evolucionar después.
Dos subproyectos que tienen que llegar juntos
En una implementación de sistemas suelen convivir al menos dos grandes frentes de trabajo. Por un lado, construir o adaptar la nueva solución. Por otro, preparar y migrar correctamente la información que ya existe.
Los dos avanzan en paralelo, pero no de forma independiente porque tienen que converger en el momento de la puesta en producción y “llegar a la meta” juntos.
“Dividimos el problema fundamentalmente en dos: por un lado, las aplicaciones y las nuevas funcionalidades; por otro, la migración de datos”, comenta Fernando Marrazzo, socio de TDI.
Una nueva solución puede estar técnicamente lista, pero si los datos necesarios para operar no llegaron correctamente, la implementación todavía no está terminada. Lo mismo sucede al revés: migrar información sin tener preparado el sistema que la va a recibir tampoco resuelve el problema.
Parte de la gestión está justamente en coordinar ambos recorridos para que lleguen juntos al momento del “encendido”.
Migrar no es simplemente mover datos
La migración suele aparecer como una tarea más dentro de un proyecto, pero en sistemas críticos puede convertirse en uno de los puntos más sensibles de la implementación.
No se trata solamente de trasladar información de un lugar a otro. Hay que entender cómo está estructurada, transformarla cuando sea necesario, validar su consistencia y asegurarse de que la información se conserve y pueda seguir utilizándose correctamente en la nueva solución.
“Por eso, la ventana de migración tiene que ser un fin de semana o días no hábiles, porque si no se siguen generando datos”, agrega el director de nuevos negocios de TDI, Agustín Maglione, y explica que “no es solo apretar un botón”.
En este tipo de proyectos, una cuenta corriente, un historial académico o cualquier registro que una organización necesita para trabajar no puede simplemente desaparecer, duplicarse o cambiar de significado durante una transición.
Por eso, la migración tiene que pensarse desde el comienzo del proyecto. Esperar hasta el final para descubrir cómo trasladar años de información puede poner en riesgo una salida que, desde lo técnico, ya está lista.
Hay otra parte de la transición que no puede resolverse únicamente desde el desarrollo. “Las áreas usuarias y las áreas técnicas tienen que participar desde el minuto uno del proceso de transformación”, suma Marrazzo.
Son quienes pueden ayudar a validar si los circuitos representan lo que realmente sucede, detectar situaciones no contempladas y anticipar problemas antes de que aparezcan en producción.
Priorizar para poder salir
Existe una regla en el mundo del desarrollo de software conocida como “90-90”: el primer 90% del código ocupa el primer 90% del tiempo y el 10% restante, otro 90%. Más allá de la exageración, refleja algo habitual: cuando un proyecto parece estar cerca de terminar, todavía puede quedar una parte importante de la complejidad por resolver.
“Hay cosas que se excluyen de la implementación porque no impiden la operación. La realidad es que, si no, no salís nunca”, comenta Maglione.
No todas las funcionalidades tienen que estar resueltas en el día uno. Si una funcionalidad no compromete la operación, postergarla puede ser una mejor decisión que sumar alcance y poner en riesgo la salida.
El objetivo no es implementar “todo”. Es tener claro qué resulta indispensable para operar, qué riesgos no se pueden asumir y qué puede quedar en backlog para evolucionar después.
Por eso, en proyectos de este tipo, priorizar también forma parte de la gestión de la implementación: permite ordenar el alcance, sostener la operación y llegar a producción con una solución que pueda seguir evolucionando.