Un plan de integración de un acuerdo anterior a menudo sigue disponible. La estructura funcionó, la división en funciones y sistemas era correcta, y resulta tentador volver a usarlo. Pero reutilizar un plan es distinto de repetir un resultado. La pregunta no es si el plan estaba completo, sino si los supuestos que contiene siguen siendo válidos para este acuerdo, estas dos organizaciones y este mercado.
La reutilización funciona a nivel de la pregunta, no a nivel de la respuesta. Un plan anterior tenía un orden para los sistemas, una división de funciones que se combinaban o no, y una lista de dependencias. Ese orden es útil como lista de verificación para no olvidar nada. No es útil como resultado a copiar, porque la razón por la que algo se combinó la vez anterior dice poco sobre si debe hacerse también esta vez.
Hay algunas señales que conviene comprobar antes de usar un plan antiguo como base.
En primer lugar: ¿eran las dos organizaciones anteriores comparables con las dos actuales, en tamaño, en panorama de sistemas, en la medida en que los clientes notan la diferencia? Un plan para dos partes equivalentes no se ajusta a una adquisición en la que una de las partes es un pequeño equipo complementario.
En segundo lugar: ¿se sabe por qué determinados componentes se mantuvieron entonces separados? Si esa razón no está documentada, no se puede valorar si ahora sí deben combinarse. Un plan que solo muestra lo que se fusionó, sin la ponderación de por qué algo se mantuvo separado, vale para la reutilización menos de lo que parece.
En tercer lugar: ¿es comparable el panorama de sistemas subyacente? Fusionar dos sistemas ERP es una tarea distinta de dejar coexistir dos herramientas de planificación. Lo que la vez anterior fue uno de los primeros pasos, esta vez puede ser mejor dejarlo aparcado porque los sistemas en sí no son comparables.
Independientemente de si un plan es nuevo o reutilizado: en cada componente debe plantearse la pregunta de si fusionar aporta valor en absoluto. No es una pregunta de excepción para casos dudosos. Es un paso fijo, incluso en componentes que a primera vista parecen naturalmente destinados a combinarse.
La razón es que integrar conlleva costes que no siempre son visibles de antemano: tiempo de personas que de otro modo trabajarían para clientes o en crecimiento, sistemas que temporalmente son menos fiables, equipos que se vuelven inseguros sobre su función. Si frente a eso no hay un beneficio demostrable, fusionar es una partida de coste sin compensación. Cuándo integrar destruye valor no es entonces un caso excepcional, sino un riesgo estructural en cada plan que se adopta sin este examen.
Hay componentes que en general es mejor mantener separados: una marca con relación propia con el cliente, un equipo con una cultura que fue la razón de la adquisición, un sistema que se acaba de sustituir y no necesita ajustarse de nuevo. Lo que usted decide mantener separado deliberadamente no es una lista de tareas pendientes sino una decisión con su propia razón, y esa razón debe documentarse tan bien como la razón para fusionar algo. Véase lo que usted mantiene separado deliberadamente para ver cómo se presenta esa elección.
Rara vez ocurre que toda una adquisición deba integrarse o no en su totalidad. Por lo general, el resultado es una mezcla: centralizar los informes financieros, mantener separados los sistemas de clientes, fusionar parcialmente la política de RR. HH. Cada componente exige su propia ponderación, con su propio calendario y su propio riesgo. Cómo decide, por componente, integrar o no es, por tanto, menos un plan de pasos que una pregunta fija que se plantea por separado en cada componente, con su propia respuesta.
Esta ponderación también difiere según el sector. En la construcción, una integración a menudo se estanca en la administración de proyectos y las relaciones con subcontratistas que no pasan sin más a otro sistema; véase dónde se estanca una integración en la construcción. En el sector de instalaciones son con más frecuencia los sistemas de planificación y los contratos de servicio los que no se combinan directamente; véase dónde se estanca una integración en el sector de instalaciones. Un plan reutilizado que ignora estas diferencias pasa por alto precisamente el componente donde antes surgió el problema.
Los generadores de línea base de sinergias, plan del Día 1 y plan del Día 100 no se construyen sobre una plantilla del acuerdo anterior, sino sobre la situación que se introduce: qué componentes hay, cuáles son las dependencias, y qué razón existe por componente para fusionar o no. La oficina de integración registra a continuación qué beneficios se han identificado, qué dependencias están pendientes y qué componentes se han mantenido deliberadamente separados. Eso no es prueba de que funcione —no hay ningún proceso ejecutado al que referirse—, pero sí es una estructura que obliga a plantear la pregunta por componente en lugar de omitirla.
Mergerintegration.net está en construcción. Quien desee trabajar con esto en cuanto esté disponible puede inscribirse en la lista de espera.
La pregunta de qué parte de este trabajo cuesta tiempo propio y qué parte puede asumirse de otro modo no se plantea únicamente en la planificación de integraciones. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo puede asumir la IA, y ofrece así una imagen de dónde se libera capacidad antes de que arranque un proceso de integración.
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.