Modernización del core llave en mano: ¿Qué significa y cuáles son las preguntas clave para hacer antes de firmar?
Modernizar un sistema core implica intervenir sobre una infraestructura que sostiene procesos críticos del negocio y que puede llevar décadas evolucionando junto con la organización.
La complejidad de esa transformación hace que la decisión no termine al definir qué modernizar o qué estrategia seguir. También es necesario resolver bajo qué modelo se va a ejecutar el proyecto y qué responsabilidad asumirá el partner tecnológico.
Lo interesante es que existe un contexto de mercado proclive a la modernización del core, inmerso en una dinámica de cambios de orientación. Como destaca el informe Kyndryl 2025 State of Mainframe Modernization Survey Report, el 80 % de las compañías consultadas modificaron su estrategia de modernización y el 88 % está implementando o planeando sumar GenAI en el mainframe.
En ese contexto aparece la modernización del core llave en mano, un modelo que debería establecer con claridad qué responsabilidades asume el partner sobre el alcance, las entregas y la dimensión financiera del proyecto.
Sin embargo, utilizar la expresión “llave en mano” no alcanza para determinar cómo se distribuirán las responsabilidades, qué sucederá frente a los desvíos, o de qué manera se medirá el avance. Antes de firmar, es necesario entender exactamente qué hay detrás de esa promesa.
Con ese objetivo, analizamos qué implica para nosotros un proyecto de modernización llave en mano, por qué los primeros meses de assessment son determinantes y cómo se distribuyen las responsabilidades entre la organización y su partner tecnológico. Además, compartimos el rol que cumplen los hitos y el modelo de facturación, y cuáles son las preguntas que conviene hacer antes de elegir un proveedor y comenzar la transformación.
“Llave en mano” significa cosas distintas según el proveedor
En un proyecto tecnológico convencional puede existir una delimitación relativamente sencilla entre las tareas del proveedor y las del cliente. En la modernización del core, esa frontera es mucho más compleja.
El proyecto interviene sobre sistemas que continúan funcionando, que soportan procesos críticos y mantienen múltiples dependencias construidas a lo largo de los años. Lo que debemos tener en cuenta es que muchas de esas relaciones recién se vuelven completamente visibles cuando comienza el trabajo de assessment.
Por eso, hablar de un proyecto llave en mano debería implicar mucho más que comprometer determinados perfiles, horas de trabajo o actividades. Desde nuestra mirada, supone asumir responsabilidad sobre el alcance, la entrega y la dimensión financiera del proyecto, trabajando bajo una lógica de partnership.
Esto no elimina la participación del cliente. Por el contrario, requiere una relación estrecha entre ambas partes. La diferencia está en que el partner no se limita a aportar capacidad técnica: asume responsabilidad sobre el recorrido acordado y sus resultados. En una transformación que puede extenderse durante años, esa diferencia resulta fundamental.
Primeros 90-120 días: por qué no vas a ver resultados en este periodo
Uno de los momentos más difíciles puede producirse, paradójicamente, al comienzo. Durante los primeros 90 a 120 días, una parte importante del trabajo está concentrada en el assessment, con entrevistas, análisis de información, relevamientos, revisión de programas y dependencias, evaluación de procesos y construcción del roadmap.
Desde afuera puede parecer que el proyecto avanza lentamente porque todavía no existen grandes resultados productivos para mostrar. Pero esa etapa es precisamente la que permite reducir la incertidumbre y construir bases sólidas para el desarrollo del proyecto.
En entornos legacy es habitual encontrarse con programas que llevan muchos años sin modificarse, configuraciones cuyo origen resulta difícil de reconstruir, procesos batch que consumen recursos sin suficiente visibilidad o dependencias que no estaban documentadas.
Intentar acelerar artificialmente esta instancia puede significar trasladar esa incertidumbre hacia la ejecución.
El análisis inicial permite reemplazar supuestos por evidencia y construir una hoja de ruta para los meses o años siguientes. En este sentido, una de las primeras cuestiones de gestión de expectativas que deberían resolverse antes de comenzar es muy concreta: los primeros meses pueden producir mucho conocimiento y pocos resultados visibles, pero ese conocimiento es parte esencial del resultado futuro.
Qué implica ser responsables de alcance, entrega y finanzas
Una modernización del core llave en mano no debería evaluarse únicamente por la cantidad de código migrado, programas que volvieron a compilarse o componentes intervenidos. El objetivo final está en el impacto que esa transformación genera sobre el negocio.
Esto obliga a establecer desde el comienzo qué se quiere mejorar y cómo se comprobará. Consumo, performance, costos, tiempos de procesamiento, velocidad de entrega o capacidad para evolucionar determinados servicios pueden formar parte de esa ecuación, dependiendo del proyecto.
Entonces tenemos tres tipos de responsabilidades:
- La responsabilidad sobre el alcance del proyecto supone establecer qué se va a transformar y bajo qué criterios.
- La responsabilidad sobre la entrega implica acordar resultados e hitos verificables, en lugar de medir solamente esfuerzo.
- La responsabilidad financiera exige establecer un marco económico que permita administrar un proyecto de largo plazo con mayor previsibilidad.
Las tres dimensiones están relacionadas. Un alcance ambiguo dificulta evaluar las entregas, que si están poco definidas vuelven más difícil controlar la inversión. Mientras que un esquema financiero completamente desacoplado de los resultados puede generar incentivos que no necesariamente coincidan con los objetivos del negocio. Un modelo llave en mano necesita conectar esas variables.
Facturación semi-fija con hitos: cómo funciona en la práctica
Los proyectos de modernización tienen una particularidad: necesitan previsibilidad, pero se desarrollan sobre entornos donde no todo puede conocerse antes de comenzar. A partir de allí, el desafío consiste en evitar dos extremos: pretender cerrar de antemano cada detalle de una transformación de varios años o trabajar sin suficiente certeza sobre costos y resultados esperados.
El modelo que planteamos busca resolver esa tensión mediante una facturación semi-fija asociada a hitos de entrega y pasos previamente acordados. De esta manera, el proyecto establece un marco de alcance, responsabilidades y objetivos, mientras el avance se organiza mediante entregas que permiten verificar progresivamente los resultados.
Esta dinámica cobra especial importancia cuando la modernización se realiza de manera gradual. En lugar de transformar todo el core en una única intervención, pueden modernizarse componentes, probarse, llevarse a producción y mantener durante un período la convivencia entre el entorno anterior y el nuevo. Cada etapa aporta además información para las siguientes.
El modelo contractual y el modelo tecnológico, por lo tanto, no deberían pensarse de manera independiente: si la transformación es progresiva, la facturación por hitos y la forma de comprometer entregas también necesitan acompañar esa lógica.
El cliente también tiene responsabilidades
Llave en mano no significa delegar el proyecto y esperar el resultado final. Una de las condiciones centrales que Pablo Reitano, Head of Delivery de IT Patagonia, identifica para que funcione una modernización reside en que la organización cliente realmente tenga disponible a su equipo.
Eso significa asignar personas capaces de tomar decisiones, brindar conocimiento sobre el negocio y asumir ownership sobre la transformación. También requiere sponsorship en diferentes niveles.
El respaldo del C-level permite sostener la prioridad estratégica y destrabar decisiones. Pero la transformación ocurre todos los días en la operación, por lo que también necesita referentes capaces de gobernar el proyecto en ese nivel.
Comités ejecutivos, instancias tácticas y equipos operativos permiten seguir diferentes dimensiones y horizontes del programa. Un buen modelo de partnership, entonces, no diluye responsabilidades. Las hace explícitas. La responsabilidad compartida implica saber desde el comienzo qué compromisos asume el partner y cuáles necesita asumir la propia organización para que el proyecto pueda avanzar.
Preguntas para hacerle a un proveedor antes de firmar
Antes de aceptar una propuesta de modernización del core llave en mano, conviene convertir las promesas generales en respuestas concretas.
Compartimos una serie de preguntas clave que aportarán mayor claridad al proyecto:
1. ¿Qué significa exactamente “llave en mano” para el proveedor? Hay que entender qué responsabilidades asume y cuáles permanecerán en manos del cliente.
2. ¿Cómo se define y eventualmente se revisa el alcance? En sistemas con décadas de historia aparecerán descubrimientos durante el assessment. El proyecto debería contemplar cómo se gestionan.
3. ¿Qué sucede durante los primeros 90-120 días? Es importante conocer qué entregables tendrá el assessment y cómo se traducirán en un roadmap ejecutable.
4. ¿Cómo se establecen los hitos? Deberían representar avances verificables y no simplemente tiempo transcurrido.
5. ¿Cómo se mide el resultado? Además de métricas técnicas, deberían existir indicadores tácticos y estratégicos que permitan observar el impacto global de la modernización.
6. ¿Qué ocurre si aparece un desvío? Un proyecto de largo plazo necesita mecanismos de revisión, decisión y escalamiento.
7. ¿Qué participación necesitará el equipo interno? Hay que conocer perfiles, dedicación esperada y decisiones que permanecerán bajo responsabilidad de la organización.
8. ¿Quién gobierna el proyecto? Conviene definir desde el comienzo responsables operativos, tácticos y ejecutivos, frecuencia de seguimiento y mecanismos para destrabar problemas.
9. ¿Cómo se relaciona la facturación con las entregas? Entender esta relación permite evaluar qué parte del riesgo asume efectivamente cada participante.
10. ¿Qué sucede mientras el core sigue funcionando? La estrategia debe contemplar explícitamente continuidad operativa, pruebas, convivencia entre componentes y mecanismos para reducir riesgos.
Un contrato no reemplaza al partnership
La modernización del core puede extenderse durante periodos de tiempo extensos, en los que surgirán descubrimientos, cambios de contexto, decisiones técnicas y necesidades del negocio que todavía no existen al momento de iniciar el proyecto.
Ningún contrato puede anticipar todas esas variables, lo cual lleva a evaluar que una propuesta de modernización del core llave en mano no consiste solamente en comparar alcance, precio y cronograma. También implica comprender cómo se distribuirán las responsabilidades cuando aparezca aquello que hoy no puede preverse. Ahí es donde el concepto de partnership adquiere verdadero sentido.
Modernizar el core no es simplemente ejecutar un proyecto tecnológico, se trata de una transformación de negocio con un gran componente tecnológico, que debe avanzar mientras la organización continúa funcionando.
Antes de elegir quién va a acompañar ese recorrido, entonces, hay una pregunta que vale la pena responder con precisión: si algo cambia o se desvía en el camino, ¿quién se hace responsable de llevar el proyecto nuevamente hacia el objetivo?
Checklist para evaluar una propuesta de modernización
Antes de tomar una decisión y si tu organización todavía necesita determinar el punto de partida, agendá un assessment con nuestro equipo para analizar el estado actual de tu core y construir un plan de modernización.
