En la mayoría de los sectores, el valor de una empresa reside en activos: edificios, existencias, contratos con una duración determinada. En TIC, el valor reside en gran medida en las personas y en el código que esas personas han escrito y comprenden. Los clientes a menudo no compran un producto, sino una relación con un equipo de cuentas o un socio de implementación. Eso desplaza el equilibrio al que una integración debe prestar atención: mientras que en una empresa de producción la mayor parte de la atención puede dirigirse a sistemas y compras, en una empresa TIC el punto central está en la retención del personal clave y en si los contratos de clientes sobreviven a la transición sin renegociación.
Esa diferencia no es una cuestión de grado, sino de naturaleza. Un almacén puede esperar a un momento de calma para fusionarse. Un desarrollador que quiere marcharse se habrá ido en unas semanas, y con él a menudo el conocimiento de un sistema que no está documentado en ningún sitio. La sinergia sobre el papel —una plataforma compartida, un equipo de ventas combinado— no tiene ningún valor si las personas que deben ejecutarla ya se han marchado antes de que se dé el primer paso.
También en TIC es cierto que integrar no es evidente por sí mismo. Dos unidades de software con productos superpuestos pueden, precisamente por la fusión, perder clientes que estaban con una de ellas por una función que la otra no tiene. Dos equipos de ingeniería con una forma de trabajar distinta —ciclos de sprint distintos, convenciones de código distintas, herramientas distintas— pierden tiempo alineando algo que operativamente no genera sinergia, solo fricción. El valor en una estrategia de buy-and-build no debería, por tanto, asociarse automáticamente a integrar; a veces el valor está precisamente en dejar funcionar por separado a los equipos que ya funcionan bien tal como están.
La línea base de sinergia ayuda a formular esa pregunta con precisión por componente: qué parte del equipo de ingeniería, qué parte de la cartera de clientes, qué parte de los sistemas. No como suposición previa, sino como algo que debe demostrarse antes de contabilizarse como sinergia.
El primer punto crítico es la retención. Un earn-out o un bono de retención para desarrolladores clave suena a un detalle de la estructura del acuerdo, pero sin una señal concreta del Día 1 —quién se queda, en qué condiciones y cuándo se comunica— se abre espacio para la incertidumbre que hace que las propias personas decidan marcharse. Esperar hasta el Día 100 para resolver esto suele llegar tarde en la práctica.
El segundo punto crítico es la comunicación con los clientes. Los clientes de TIC a menudo tienen un contrato con un momento de cancelación o una fecha de renovación, y una adquisición es para ellos un motivo para mirar alternativas. Quien posterga el mensaje a los grandes clientes hasta después del cierre corre el riesgo de que el cliente se entere de la noticia por terceros y la interprete de manera distinta a la prevista.
El tercer punto crítico es técnico: fusionar dos stacks tecnológicos rara vez es cuestión de la misma semana. Algunas integraciones —un módulo de facturación compartido, un CRM central— pueden hacerse con impacto limitado. Otras —la fusión de plataformas centrales sobre las que operan los clientes a diario— requieren un enfoque más prolongado precisamente porque un error ahí se hace visible de inmediato para el usuario final. El plan del Día 1 y el plan del Día 100 sirven para hacer esa distinción de antemano, en lugar de descubrirla sobre la marcha.
La dependencia entre tareas es un patrón que también se da en otros sectores, solo que con otros puntos críticos. En una adquisición en la construcción son los permisos y las relaciones con subcontratistas los que determinan qué puede hacerse cuándo; en una adquisición en el sector inmobiliario suele ser la estructura de los contratos de gestión. En TIC es la combinación de personas que pueden marcharse y clientes que pueden cancelar —ambos más rápido de lo que puede ajustarse un proceso físico. La oficina de integración documenta esas dependencias para que quede claro qué paso bloquea a otro paso, independientemente del sector en el que se encuentre ese punto crítico.
En las adquisiciones de software, la sinergia suele atribuirse al negociador que concibió la cifra, mientras que el responsable operativo que debe hacerla realidad se incorpora más tarde. Esa misma tensión se da en los servicios financieros y en el sector energético, y la pregunta de quién es propietario de una cifra de sinergia debería responderse antes del cierre, no después.
Los tres generadores y la oficina de integración construyen estructura: una línea base de sinergia por componente, un plan del Día 1 con primeros pasos concretos, un plan del Día 100 con dependencias y una lista de decisiones sobre qué se integra y qué no. No se hace referencia a ningún proceso ya ejecutado y no se promete nada sobre el resultado. El instrumento formula las preguntas y ordena las respuestas; la evaluación sigue correspondiendo al equipo de la operación.
La herramienta está en desarrollo. Quien desee utilizarla en cuanto esté disponible puede inscribirse en la lista de espera.
Una línea base de sinergia y un plan del Día 100 se componen de un gran número de tareas individuales: revisar contratos, comparar listas de clientes, mapear dependencias. Algunas de esas tareas se pueden automatizar en gran medida, otras requieren un juicio que no se puede delegar. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo puede asumir la IA, de modo que quede claro dónde se ahorra tiempo y dónde sigue siendo necesario el juicio humano.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.