En los primeros cien días tras una operación, el problema parece a menudo una falta de decisiones. Con más frecuencia, el problema es el orden. Una decisión sobre el sistema ERP común bloquea la configuración de las líneas de reporte. Una decisión sobre quién recibe el mandato comercial bloquea toda conversación con clientes compartidos. Mientras nadie identifique esa dependencia, dos equipos esperan simultáneamente el uno al otro, sin que nadie lo note.
No toda decisión pendiente es un problema. Algunos asuntos pueden esperar sin que el resto se paralice — cuáles son y quién puede determinarlo se describe en la página sobre qué puede esperar hasta después del Day 100. Una decisión bloqueada es otra cosa: es una decisión de la que dependen otras decisiones, y que retiene demostrablemente a esas otras decisiones. La diferencia no siempre es visible desde un solo equipo. El departamento financiero no ve que su espera por una elección de sistema también retrasa la integración de RR. HH., porque las nóminas dependen del mismo sistema. Esas conexiones solo se hacen visibles cuando alguien las mapea explícitamente, al margen del departamento al que le toca actuar en último lugar por casualidad.
El coste de una decisión bloqueada rara vez es una cantidad fija por semana. Depende de lo que quede paralizado: un acuerdo de precios que no puede revisarse mientras no se haya fusionado la cartera de productos, un empleado clave que se marcha porque nadie le da claridad sobre su rol, un cliente que se pasa a la competencia porque dos equipos de cuenta se contradicen entre sí. No son cifras que puedan calcularse de antemano. Sí pueden ordenarse: qué decisión afecta a cuántas otras decisiones, y cuál es la naturaleza del daño si se prolonga. Ese ordenamiento —según incertidumbre y consecuencia, no según quién grite más fuerte— se aborda en la página sobre cómo clasificar las decisiones según el coste de la incertidumbre.
Al mapear las decisiones bloqueantes hay una pregunta que no debe omitirse: si este componente realmente debe integrarse. Resolver una dependencia fusionando dos sistemas no es automáticamente mejor que dejarlos coexistir. A veces la forma más rápida de eliminar un bloqueo es decidir que la integración en ese punto no añade valor. Esa decisión no debe tomarse en silencio porque nadie planteó la pregunta; debe quedar explícitamente sobre la mesa, junto a la pregunta de cuándo y en qué orden.
Una lista de decisiones bloqueantes ya está incompleta el primer día de la integración, y lo está cada vez más a medida que se toman más decisiones. Surgen nuevas dependencias en cuanto se resuelven las antiguas: se ha elegido el sistema, y ahora resulta que la implementación depende de un contrato con proveedor que todavía está vigente. Alguien debe mantener actualizado ese mapa, no como ejercicio único de la primera semana, sino como tarea continua — de lo contrario, el bloqueo solo cambia de lugar. Quién desempeña ese papel y cómo evita esa persona que el propio mapa se convierta en una burocracia que retrasa las cosas, se explica en la página sobre cómo mantener operativa la oficina de integración.
Las decisiones bloqueadas son a menudo la razón por la que no se alcanza un plan de Day 100, no porque el plan estuviera mal concebido, sino porque se subestimó una dependencia. Qué decisiones corresponden en todo caso a los primeros cien días y quién vela por que efectivamente se tomen, se explica en la página sobre las decisiones de los primeros cien días. Qué hacer si, a pesar de todo, no se cumple el plazo —qué decisiones se reprioritizan entonces y quién lo decide— se describe en la página sobre no alcanzar el Day 100. Señalar un bloqueo no es lo mismo que resolverlo, pero sin señalización el retraso permanece invisible hasta el momento en que hay que entregar el informe.
Los generadores y la oficina de integración de mergerintegration.net estructuran estas dependencias: mapean qué decisión espera a qué otra decisión, y qué parte de la organización queda paralizada por ello. Esto no es un historial de servicios — no hay ningún proceso ejecutado en el que esta herramienta se apoye, y aquí no se sugiere lo contrario. Es una manera de plantear la pregunta con precisión antes de que el retraso se haga visible en cifras que ya nadie puede corregir. Quien quiera trabajar con esto puede inscribirse en la lista de espera; la herramienta está en construcción.
Parte del tiempo que se pierde en decisiones bloqueadas se dedica a trabajo que las personas hacen manualmente cuando también podría hacerse de forma automática: fusionar listas de clientes, comparar condiciones contractuales, mantener un mapa de dependencias que cambia después de cada reunión. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte de ella puede asumir la IA, y hace así visible dónde se libera capacidad que de otro modo podría haberse dedicado a la propia 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.