Las semanas posteriores al arranque deciden el proyecto. Casi nadie las dota de gente.

Lee cualquier plan de implementación y vas a notar la misma forma. Detalle enorme hasta el arranque: pasos de migración, ventanas de corte, capacitaciones, un procedimiento de reversa, una junta de continuar o no con asistentes por nombre.

Después del día del arranque, tres palabras. Soporte y estabilización.

Ese es el periodo que determina si el proyecto funcionó. Es de forma consistente la parte menos planeada, menos dotada de personal y menos presupuestada de todo el proyecto, y la razón es estructural más que descuidada: el arranque es cuando se acaba el presupuesto del equipo de entrega y empieza el riesgo del cliente.

Hemos corrido este periodo las veces suficientes para decir con claridad que ahí se ganan y se pierden los proyectos, y que casi todo lo que sale mal es predecible.

Qué está pasando realmente en esas semanas

El sistema está vivo. Funciona. Las pruebas pasaron y los datos migraron. Y tu organización está ahora en el estado menos productivo en el que ha estado en años, por razones que no tienen nada que ver con la calidad del software.

Todos son más lentos, incluida la gente que quería esto. El personal que se sabía el proceso viejo de memoria ahora anda buscando cosas. Una tarea de cuatro minutos toma once. Es normal y temporal, y para quien lo está viviendo se siente como prueba de que el sistema nuevo es peor. Esa impresión se forma en unos nueve días y después es muy difícil de revertir.

Llegan las excepciones. Las pruebas cubren lo que la gente se acordó de describir. La semana tres trae el caso de la aseguradora que hace las cosas distinto, el expediente con treinta años de historia, la autorización que siempre se ha hecho por teléfono. Nada de esto estaba oculto; a nadie se le ocurrió mencionarlo, porque es simplemente un martes.

Hay dos sistemas corriendo. En la práctica, no en el plan. Alguien mantiene actualizada la hoja de cálculo vieja "nada más por si acaso", lo cual es completamente razonable y también la cosa más peligrosa que ocurre en este periodo.

Nadie quiere reportar problemas. El proyecto fue caro y lo patrocinó alguien de alto nivel. Levantar la mano en la semana dos se siente como criticar una decisión ya tomada, así que la gente inventa rodeos y no dice nada. La información que más necesitas es la que menos probablemente te va a llegar.

Las tres formas en que fracasa

El rodeo silencioso. Un equipo topa con fricción, inventa un paso manual y no le dice a nadie. Seis meses después está institucionalizado, sin documentar, y los números reportados se están ajustando a mano en algún punto entre el sistema y la presentación al consejo.

El sistema paralelo que nunca muere. La hoja de cálculo paralela iba a durar dos semanas. En la semana diez sigue existiendo, y ahora contradice al sistema. Una vez que dos registros no coinciden, la gente confía en el que mantiene ella misma, y la plataforma nueva se vuelve un lugar caro para volver a capturar datos que ya existen en otro lado.

La reversa que se presenta como prudencia. Rara, cara y casi siempre el desenlace de las dos anteriores, no la respuesta a una falla técnica. El sistema normalmente funcionaba. La adopción no.

Nota que ninguna de estas es un defecto de software. Todas son fallas operativas, que es exactamente por qué un contrato de soporte es el instrumento equivocado para ellas.

Por qué un ticket de soporte no puede detectar nada de esto

El soporte es reactivo por diseño. Espera a que le avisen.

Las fallas de arriba comparten una propiedad: nadie las reporta. Un rodeo no es un bug. La persona que lo inventó cree que resolvió un problema, y lo resolvió. Una hoja de cálculo paralela no es un incidente. La adopción lenta de un área no genera un ticket; genera una opinión callada que se expresa en una junta cuatro meses después.

Así que una fila de tickets vacía en la semana tres no es evidencia de que el arranque salió bien. Es la señal más común que precede a las fallas que sí ocurren, y la única forma de verlas es ir a mirar.

Qué hacemos en su lugar

Tratamos el periodo posterior al arranque como una fase de entrega con su propio plan, no como una garantía. Cuatro cosas, todas deliberadamente poco vistosas.

Estamos en la operación, no en una línea de soporte. Alguien se sienta con la gente que usa el sistema, viendo trabajo real, durante las primeras semanas. Noventa minutos viendo a un ajustador procesar expedientes reales revelan más que un mes de tickets, porque ves las dudas que a nadie se le ocurriría reportar.

Matamos el sistema paralelo en una fecha, a propósito. No por decreto: haciendo que el sistema nuevo haga el trabajo que la hoja de cálculo seguía haciendo, y luego poniendo una fecha con un nombre asignado. Correr dos sistemas indefinidamente no es cautela. Es la falla, en curso.

Vemos uso, no disponibilidad. Qué funciones nadie toca, qué registros se editan inmediatamente después de crearse, qué área tiene números distintos a todas las demás. La funcionalidad sin usar o es innecesaria o no se entendió, y ambas cosas conviene saberlas en semanas y no en la renovación.

Esperamos cambiar el sistema, y lo presupuestamos. No es crecimiento de alcance: es contacto con la realidad. La excepción que nadie documentó no es una solicitud de cambio; es el requisito que siempre estuvo ahí. Tratar los hallazgos de la semana cuatro como fuera de alcance es cómo un equipo de entrega protege su margen y pierde la operación del cliente.

Para la plataforma de siniestros que construimos, por eso sigue siendo nuestra para operar y no algo que entregamos. Alrededor de 25,000 casos al año en 28 entidades legales no se vuelve estable porque un corte haya salido bien; se vuelve estable porque alguien siguió poniendo atención después.

Qué poner en el contrato

Si estás contratando este trabajo, esta es la parte práctica. Pide cuatro cosas antes de firmar, porque son baratas de acordar antes e imposibles de agregar después.

1. Personas con nombre, en sitio o en la operación, por un periodo definido después del arranque, no un SLA, no un buzón compartido. Una persona, un número de días, una fecha.
2. Una fecha de baja para lo que el sistema nuevo reemplaza, acordada por adelantado y con dueño de tu lado.
3. Un presupuesto de cambios para los primeros sesenta días, apartado y con una ruta de aprobación ligera. Asume que el requisito estaba incompleto, porque lo estaba.
4. Adopción reportada al patrocinador, no disponibilidad. La disponibilidad va a estar bien. La disponibilidad no es la pregunta.

Cualquier socio que se resista a las cuatro te está diciendo dónde termina de verdad su compromiso, y conviene saberlo durante la negociación y no en la semana cinco.

En resumen

Un sistema que arranca no es un proyecto que salió bien. Es un proyecto que llegó a la parte donde se decide si salió bien.

Las organizaciones que obtienen el valor que pagaron no son las del corte más limpio. Son las que trataron las seis semanas siguientes como trabajo real con gente real asignada, y que entendieron que el silencio en la fila de tickets no era una buena noticia.

Por eso quedarnos después del arranque es uno de los cuatro compromisos que asumimos y no un servicio que vendemos aparte. No es generosidad. Es el único periodo en el que alguien puede saber si el trabajo sirvió, y preferimos estar ahí.