No hace falta reemplazarlo todo: por dónde se empieza
Resumen:
- Reemplazar el sistema entero es el planteamiento que más proyectos mata antes de empezar.
- La primera pieza se elige por dolor diario y baja dependencia, no por importancia teórica.
- La convivencia entre sistemas funciona si cada dato tiene un dueño explícito.
- Por piezas se puede parar en cualquier punto con lo construido en producción.
La conversación empieza casi siempre igual: «queremos cambiar todo el sistema». Y termina casi siempre igual también: en un presupuesto grande, un calendario largo y una decisión que se aplaza otro año.
El planteamiento de reemplazarlo todo tiene tres problemas. Es caro, es lento y concentra el riesgo en un único momento de corte. Además obliga a especificar hoy cosas que solo se entenderán dentro de seis meses.
La alternativa: una pieza cada vez
La estrategia que funciona consiste en identificar una parte concreta, construirla bien, conectarla a lo que ya existe y dejar el resto intacto. Cuando esa pieza está estable, se elige la siguiente.
No es una idea nueva ni sofisticada. Lo difícil es resistir la tentación de aprovechar el proyecto para arreglar de paso otras cinco cosas.
Cómo se elige la primera pieza
| Criterio | Por qué importa |
|---|---|
| Dolor diario | Algo que moleste todos los días, no una vez al trimestre. El retorno se nota antes y el equipo lo agradece antes. |
| Poca dependencia | Que necesite pocos datos de otros sistemas. Cuantas más conexiones, más se parece a reemplazarlo todo. |
| Frontera clara | Que se pueda decir con precisión dónde empieza y dónde acaba. Si no se puede delimitar, no está lista para construirse. |
| Usuarios identificables | Un grupo concreto que la va a usar y con quien se puede hablar. Sin eso se construye sobre suposiciones. |
Nótese que «lo más importante del negocio» no está en la lista. El núcleo suele ser la pieza con más dependencias y la peor candidata para empezar.
La convivencia: la parte que se subestima
Durante meses, o años, van a funcionar dos sistemas a la vez. Eso es normal y solo funciona si se decide algo antes de escribir código: para cada dato, cuál de los dos manda.
El cliente vive en el sistema antiguo y el nuevo lo consulta. El pedido nace en el nuevo y el antiguo recibe copia. Cada regla escrita, sin excepciones informales.
Cuando esa frontera se respeta, la convivencia es aburrida, que es exactamente lo que se busca. Cuando se rompe «solo por esta vez», empiezan las discrepancias que nadie sabe reconciliar.
Qué conviene conservar del sistema actual
Antes de sustituir nada, merece la pena inventariar lo que funciona bien. Casi siempre hay más de lo que se piensa.
- Informes que alguien mira de verdad y que costó años afinar.
- Reglas de negocio implementadas correctamente, aunque estén mal escritas.
- Datos históricos limpios, que valen más que cualquier funcionalidad.
- Automatismos que nadie recuerda haber pedido y que evitan trabajo cada día.
Ese inventario también sirve para lo contrario: descubrir funciones que llevan años sin usarse y que nadie va a echar de menos. Es habitual que un tercio de las pantallas de un sistema veterano no las abra nadie.
Preguntas frecuentes
¿Se puede tener software propio y plataformas a la vez?
Sí, y es lo normal. Casi ninguna empresa necesita construir su correo, su contabilidad o su almacenamiento. Lo que se construye es la pieza que constituye su diferencia; el resto se contrata y se conecta.
¿Cuál es la primera pieza que conviene construir?
La de mayor dolor diario y menor dependencia del resto. Un módulo que se usa a diario y que puede funcionar con datos que ya existen entrega valor rápido; empezar por el núcleo del sistema arrastra todo lo demás.
¿Cómo conviven el sistema nuevo y el antiguo?
Con una frontera clara: cada dato tiene un sistema que manda y el otro recibe copia. Mientras esa frontera esté escrita y respetada, la convivencia puede durar años sin problemas.
¿Cuánto tarda en verse el retorno?
Si la primera pieza está bien elegida, semanas: menos captura manual, menos errores o información que antes no existía. Si el primer entregable tarda seis meses en aportar algo visible, la elección de la pieza fue mala.
¿Y si a mitad de camino cambia la prioridad del negocio?
Es una de las ventajas del enfoque por piezas: se puede parar después de cualquier módulo con lo construido funcionando. Un proyecto monolítico solo aporta valor al final, así que interrumpirlo significa perderlo todo.
El efecto que nadie anticipa
Hay un beneficio secundario del enfoque por piezas que aparece siempre y que no está en ningún presupuesto: la empresa aprende a especificar.
El primer módulo se especifica mal, porque nadie tiene práctica. El segundo se especifica bastante mejor, porque ya se ha visto qué preguntas había que haber hecho. Para el tercero, el equipo del cliente sabe describir lo que necesita en términos que un desarrollador puede construir.
Ese aprendizaje no ocurre en un proyecto monolítico, donde toda la especificación se hace de una vez y al principio, que es justamente el momento en que menos se sabe.
Cómo se decide cuándo parar
Un proyecto por piezas no tiene un final evidente, y eso desconcierta a quien está acostumbrado a proyectos con fecha de entrega.
La regla que aplicamos es sencilla: se sigue construyendo mientras la siguiente pieza tenga un retorno claro y se para cuando la lista de candidatas empieza a llenarse de cosas que estaría bien tener. Ese cambio de tono en las reuniones de prioridades es la señal.
Parar no significa abandonar. Significa pasar a un modo de mantenimiento y mejora continua, con un presupuesto menor y estable, en lugar de seguir en modo proyecto por inercia.
Los errores más comunes al empezar
- Elegir la pieza por importancia y no por dolor. Lo más crítico suele ser lo más conectado, y por tanto la peor primera pieza.
- No nombrar un responsable interno. Sin alguien del cliente que decida, cada duda tarda días y el proyecto se alarga sin que nadie sepa por qué.
- Aprovechar para rediseñar el proceso. Cambiar la herramienta y el proceso a la vez multiplica la resistencia y hace imposible saber qué falló.
- Dejar la frontera de datos sin escribir. Funciona las primeras semanas y luego produce discrepancias que nadie sabe resolver.
Los cuatro se evitan con decisiones previas, no con más presupuesto.