Conectar herramientas antes de sustituirlas

Cuando algo no funciona, la conversación deriva rápido hacia cambiar de programa. Es una conversación cómoda porque tiene una respuesta clara y un presupuesto. Suele ser también la más cara.

Dónde está el problema realmente

Merece la pena separar dos cosas distintas:

• Un programa se ha quedado corto. No hace algo que hoy se necesita, y no lo va a hacer. Aquí sí toca plantearse sustituirlo.
• Dos programas no se hablan. Cada uno hace bien su parte, pero alguien tiene que pasar la información de uno a otro. Aquí el problema no está dentro de ninguno de los dos: está en el hueco.

El segundo caso es mucho más frecuente que el primero, y se arregla de otra manera.

Lo que cuesta migrar, aunque no se diga

Una migración no es sólo el coste del programa nuevo. Es el histórico que hay que mover, la formación, los meses en los que se trabaja peor mientras todo el mundo se acostumbra, y los procesos que había alrededor del programa viejo y que hay que rehacer.

Nada de eso es un argumento para no migrar nunca. Es un argumento para estar seguros antes.

Conectar como forma de comprobarlo

Conectar dos sistemas que ya existen suele ser un trabajo acotado: se define qué información pasa, en qué dirección y cada cuánto. Y tiene una ventaja que una migración no tiene — si no resuelve el problema, se ha descubierto barato.

Si después de conectarlos el trabajo manual desaparece y las quejas también, el programa nunca fue el problema. Y si las quejas siguen, ahora sabes exactamente cuáles son, con lo que la decisión de sustituir se toma con información en lugar de con intuición.

El orden que suele funcionar

Entender el proceso completo. Localizar dónde se corta. Conectar ese corte. Mirar qué queda. Y sólo entonces, si sigue quedando algo, decidir si hay que cambiar una pieza.