Kennisbank

Cuando no se alcanza el Day 100

Day 100 es una fecha que los equipos de integración se imponen a sí mismos, no una ley de la naturaleza. Cuando esa fecha se acerca y el plan no está terminado, suele surgir inquietud: ¿ha salido algo mal, hay que acelerar, tiene alguien que rendir cuentas? Esas preguntas son comprensibles pero a menudo no son las correctas. La primera pregunta es más precisa: qué parte del plan no se ha alcanzado, y qué significa eso para el resto.

No todos los elementos no alcanzados pesan igual

Un plan de Day 100 consta de decisiones que dependen entre sí y decisiones que no lo hacen. Si una migración de TI se retrasa pero el resto de la organización no está esperando a eso, es un problema distinto de cuando se retrasa una decisión de personal mientras otros cinco equipos esperan a esa decisión para poder continuar. Antes de concluir que el Day 100 ha fracasado, tiene sentido revisar cuáles de las decisiones originales realmente estaban en la ruta crítica y quién lo vigilaba. Un plazo no cumplido en una decisión que no bloqueaba nada no es una crisis. Un plazo no cumplido en una decisión de la que todo dependía, sí lo es.

Esta distinción rara vez se hace con claridad de antemano. Los planes se escriben como una lista de fechas, no como una red de dependencias. Quien tiene que averiguar a posteriori qué cuesta realmente un retraso, descubre a menudo que las dependencias nunca se documentaron de forma explícita. Por eso vale la pena determinar de antemano qué dependencias bloquean el resto del proceso y quién lo vigila. Sin ese mapa, cada retraso es una sorpresa en lugar del resultado previsible de un riesgo conocido.

Los costes de esperar rara vez se distribuyen de forma equitativa

No todas las decisiones postergadas cuestan lo mismo. Una decisión sobre un sistema CRM conjunto puede esperar sin que se pierda mucho, mientras que una decisión sobre quién gestiona la relación con el cliente influye desde el primer día, y el retraso ahí se percibe de inmediato entre clientes y empleados. La distinción entre lo que puede esperar y lo que no, no es fija: depende del sector, del grado de solapamiento entre las organizaciones, y de cuánta incertidumbre genera una espera más larga entre quienes esperan una decisión.

Para hacer esa distinción, ayuda ordenar las decisiones según lo que realmente cuesta la incertidumbre, no según lo que resulte más fácil abordar primero. Algunos equipos abordan primero las decisiones más rápidas de tomar, mientras que la incertidumbre más costosa está en otro lugar. Una forma de evitarlo es ordenar las decisiones en función de lo que cuesta la incertidumbre por cada día que una decisión se demora. Eso genera un orden distinto al de una planificación que simplemente busca cerrarlo todo en cien días.

También existe otra cara: no todas las decisiones deben tomarse dentro de los cien días, y forzarlas puede causar más daño que postergarlas. Algunas decisiones de integración se toman mejor tras un período de observación, cuando queda más claro cómo colaboran realmente las dos organizaciones. Por tanto, es igual de importante saber qué puede esperar después del Day 100 sin que el proceso se estanque como saber qué no puede esperar. Un plazo no cumplido en una decisión que, de todos modos, era mejor tomar más adelante, no es un fracaso: es una corrección.

Lo que realmente dice un Day 100 no alcanzado sobre la oficina de integración

Cuando no se alcanza el Day 100, la pregunta a menudo no recae en la decisión en sí, sino en la estructura que debía vigilar las decisiones. Una oficina de integración que solo mantiene fechas en una lista, ve un plazo incumplido únicamente cuando ya se ha incumplido. Una oficina de integración que sigue las dependencias y los costes de la incertidumbre, ve venir un retraso y puede determinar a tiempo si hace falta corregir el rumbo o si el retraso es aceptable.

Esto toca una pregunta más amplia sobre cómo está organizada la propia oficina de integración. Una oficina saturada de actualizaciones de estado e informes pierde precisamente la visión de conjunto en el momento en que más la necesita. Por eso conviene reflexionar sobre cómo mantener manejable la oficina de integración y quién lo vigila, de modo que un plazo incumplido se convierta en una señal en lugar de ruido en una bandeja de entrada desbordada.

Tampoco existe una única respuesta a qué hacer cuando no se alcanza el Day 100: la respuesta depende de qué decisión se trate, qué depende de ella, y si el retraso realmente cuesta valor o, por el contrario, protege valor al evitar una decisión precipitada. Quien busque estructura en este punto en lugar de una respuesta hecha, encontrará un enfoque detallado en la página que trata específicamente qué hacer cuando no se alcanza el Day 100 y quién vigila ese proceso.

Integrar no siempre es la decisión correcta

Con cada elemento no alcanzado de un plan de Day 100 también surge la pregunta subyacente de si realmente era necesario fusionar ese elemento. Algunos sistemas, equipos o procesos no ganan nada con la integración y sí pierden tiempo y atención que se necesitan en otro lugar. Un plazo incumplido es un buen momento para volver a plantear esa pregunta, no solo para presionar con más fuerza hacia la fecha original.

Para determinar qué parte del trabajo en torno a un proceso de integración de este tipo debe realizar personas y qué parte puede apoyarse con IA, FTE TO AI ofrece un escaneo de trabajo que calcula, por tarea, qué proporción puede transferirse. Para los equipos que, tras un Day 100 no alcanzado, quieren saber dónde se estanca la capacidad y dónde puede liberarse, ese es un punto de partida concreto.