El lanzamiento exitoso no garantiza crecimiento sostenido

El error de tratar el go-live como un punto de llegada

Hay un momento, después de cada lanzamiento, en que el equipo puede decir con legitimidad que el trabajo fue bueno. El sitio funciona, los pedidos entran, las métricas arrancan a moverse. Nadie tiene razones para cuestionar lo que se construyó.

Ese momento es también, con frecuencia, el momento en que se instala el problema que va a aparecer dos años después.

El éxito de un lanzamiento mide una cosa: si el sistema resuelve lo que tenía que resolver en ese momento. No mide si el sistema está diseñado para lo que viene después. Son preguntas distintas, y casi nunca se formulan al mismo tiempo.

Lo que el éxito no revela

Mientras el negocio funciona dentro de los parámetros para los que fue construido el sistema, las limitaciones estructurales permanecen invisibles. Los equipos aprenden a trabajar con lo que tienen. Las ineficiencias se absorben. Los parches funcionan. Nadie tiene motivos para revisar lo que aparentemente no está roto.

El problema no aparece cuando algo falla. Aparece cuando el negocio necesita cambiar.

Un relevamiento anual de Gartner sobre más de 3.100 CIOs y ejecutivos de tecnología encontró que solo el 48% de las iniciativas digitales cumple o supera sus objetivos de negocio. La mayoría no falla por problemas de ejecución técnica, sino porque el sistema no fue diseñado con la capacidad de adaptación que el crecimiento iba a exigir. El lanzamiento fue exitoso. Lo que vino después, no.

Nuevo canal de ventas. Nueva condición comercial por segmento. Nuevo mercado. Cada uno de esos movimientos, razonables desde la estrategia de negocio, se convierte en un proyecto técnico cuando el sistema no fue pensado para admitirlos.

Por qué un proyecto bien ejecutado puede crear dependencia

Conviene ser preciso: no es un problema de ejecución técnica deficiente. Es la consecuencia natural de optimizar para el lanzamiento en lugar de para la evolución.

Cuando el foco está puesto en salir a tiempo y dentro del presupuesto, las decisiones se toman con ese criterio. La lógica del negocio queda configurada dentro del modelo de datos del proveedor elegido. Los flujos de información se construyen para resolver el caso de uso más inmediato. Las integraciones se diseñan para lo que existe, no para lo que puede existir. Cada una de esas decisiones es razonable en su contexto. El problema es que, en conjunto, producen un sistema que funciona pero no escala.

Hay un patrón que se repite: la empresa que lanzó su plataforma con éxito y, cuando quiso expandir su operación B2B, descubrió que la lógica de precios estaba enterrada en la configuración de la herramienta de e-commerce y que modificarla implicaba rehacer procesos que ya estaban en producción. El sistema no había sido diseñado para ese caso de uso porque, en el momento del lanzamiento, ese caso de uso no era prioritario. Después lo fue. Y el costo de adaptarlo fue desproporcionado respecto del costo que habría tenido diseñarlo bien desde el principio.

El éxito como punto ciego

La deuda técnica silenciosa es más difícil de gestionar que la deuda técnica visible. Cuando algo falla, hay una señal de alerta. Cuando algo funciona pero con limitaciones estructurales, la señal tarda en aparecer.

En ese intervalo, el sistema exitoso genera inercia. Es difícil justificar una revisión estructural de algo que, en los indicadores visibles, está funcionando. El negocio sigue operando, los proyectos siguen entregándose, los resultados de corto plazo siguen siendo positivos. La conversación sobre arquitectura se posterga porque no hay una urgencia que la fuerce.

Hasta que la hay.

Cuando el punto de quiebre llega, el diagnóstico suele ser el mismo: el sistema que construimos ya no es el sistema que necesitamos, y adaptarlo va a costar mucho más que haberlo diseñado bien desde el inicio. Esa frase se dice en retrospectiva. La dificultad está en que el momento de diseñarlo bien siempre es antes de que el problema sea evidente.

La diferencia entre ejecutar bien y diseñar para evolucionar

Ejecutar bien un proyecto digital resuelve el presente. Diseñar para evolucionar protege el futuro. Son objetivos distintos, y la confusión entre ambos es uno de los patrones más comunes en la evolución digital de empresas medianas.

Ejecutar bien implica entregar en tiempo, dentro del alcance, con la calidad técnica acordada. Es necesario y no es suficiente.

Diseñar para evolucionar implica responder, antes de implementar, las preguntas que el artículo anterior de esta serie describió en detalle: dónde reside la lógica del negocio, cómo fluye la información entre áreas, qué partes del sistema pueden cambiar sin afectar al resto y quién gobierna las reglas centrales. Cuando esas preguntas tienen respuesta antes de la primera línea de código, el sistema resultante puede crecer con el negocio. Cuando no las tienen, el crecimiento del negocio termina chocando contra la estructura del sistema.

La diferencia no está en la herramienta elegida ni en la calidad del equipo que ejecuta. Está en si el diseño del ecosistema precedió a la implementación o si la implementación fue definiendo el ecosistema por defecto.

El costo real no es el proyecto fallido

Es tentador pensar que el riesgo principal del crecimiento digital está en los proyectos que salen mal: los que se atrasaron, superaron el presupuesto o no cumplieron con las expectativas técnicas. Ese riesgo es visible y manejable.

El riesgo menos evidente es el del proyecto que salió bien pero no fue diseñado para lo que vendría después. El que fue un éxito en sus propios términos y, precisamente por eso, creó la ilusión de que el problema estaba resuelto. El que generó dependencia sin que nadie lo eligiera explícitamente.

Cuando ese sistema llega al límite de lo que puede sostener, el costo no es solo técnico. Es el costo de rehacer bajo presión lo que podría haberse diseñado con calma. Es el costo de un negocio que tuvo que frenar su expansión porque su operación digital no estaba preparada para acompañarlo.

La pregunta que distingue a un ecosistema diseñado para escalar de uno diseñado solo para funcionar no se responde en el lanzamiento. Se responde antes. Y sus consecuencias se ven, en uno u otro sentido, mucho después.

Esa es la discusión que cierra esta etapa de la serie: qué características estructurales permiten que un ecosistema crezca sin romperse y sin generar la deuda que, tarde o temprano, frena lo que el negocio necesita hacer.