Proyecto TI parado en retail: por qué se paraliza y cómo retomarlo

Hay una conversación que tuve varias veces en el último año. Una empresa de retail especializado — calzado, ferretería, electrónica, decoración — con un proyecto TI que lleva entre uno y tres años en algún cajón, con algún grado de avance, con algo de código escrito, con el problema original todavía sin resolver.

El proyecto no murió. Está dormido.

Y despertarlo no es tan simple como retomarlo desde donde quedó.

Los patrones que se repiten

Después de ver varios proyectos TI parados en retail, hay causas que se repiten. No son únicas ni sorprendentes — pero entender cuál aplica cambia radicalmente la estrategia para destrabar.

El proyecto creció sin redefinirse

El problema original era concreto: el sistema de caja no se comunicaba con el sistema de stock, y la conciliación se hacía a mano dos veces por semana. Eso tenía solución en pocas semanas.

Durante el proceso, alguien propuso aprovechar y también resolver el sistema de fidelización. Luego apareció la necesidad de integrar con el proveedor de pagos nuevo. Y después el directorio pidió que el nuevo sistema soportara la apertura de tres locales adicionales que todavía no están confirmados.

El proyecto que empezó con un alcance de ocho semanas tiene ahora un alcance de ocho meses, con requerimientos que no son todos compatibles entre sí, algunos de los cuales corresponden a un negocio que todavía no existe.

El proyecto no avanza porque nadie se pone de acuerdo en qué incluye.

El proveedor entregó algo que nadie puede mantener

Hay muchas versiones de esta historia. La más común: una empresa de retail contrató a un proveedor para desarrollar un sistema de gestión de inventario a medida. El proveedor entregó. El sistema funciona, más o menos. El proveedor ya no está disponible o tiene otros clientes prioritarios.

Ahora hay que hacerle cambios — la operación lo necesita — y el equipo TI interno no entiende el código. No hay documentación. No hay tests. El proveedor hizo algo que funciona hoy pero que nadie más puede tocar sin riesgo alto.

El proyecto está "entregado" pero sigue siendo un problema abierto.

La operación no puede parar para el cambio

Retail tiene temporadas. Hay meses donde el volumen se multiplica y el margen para error es cero. Y hay meses de menor actividad donde hay espacio para cambios.

El problema es que los proyectos TI no siempre respetan ese calendario. O el proyecto se inició en el peor momento. O el equipo subestimó el tiempo que tomaría. O algo salió mal y el proyecto se corrió justo a la temporada alta.

La decisión correcta — no tocar los sistemas críticos en temporada alta — termina siendo la excusa para no retomarlo nunca, porque siempre hay una temporada próxima.

El equipo operacional no quiere el nuevo sistema

A veces el proyecto técnicamente funciona, pero la implementación fracasó. El equipo de tienda o de bodega no adoptó el sistema. Siguen usando los métodos anteriores, con el nuevo sistema activo en paralelo y generando el doble de trabajo.

Eso pasa cuando la implementación se hizo desde TI hacia operaciones, sin entender realmente cómo trabaja la gente en el día a día. El sistema resuelve el problema que TI vio, no el problema que operaciones tiene.

Cómo destrabar, según la causa

El diagnóstico de causa importa porque la estrategia de destrabe es distinta según de dónde viene el problema.

Si el problema es alcance no definido

El proyecto necesita un rediseño de alcance antes de una línea de código nueva. Eso significa sentarse con los stakeholders relevantes — no con todos, con los que tienen poder de decisión real — y definir qué entra y qué sale de esta fase.

La regla práctica: si no se puede comprometer en este proyecto, no entra. El sistema de fidelización futuro puede diseñarse para ser compatible, pero no tiene que construirse ahora.

Un alcance redefinido y congelado es la condición para que el proyecto avance. Sin eso, cada semana hay una nueva prioridad que entra.

Si el problema es código que nadie entiende

El primer paso es una auditoría técnica honesta: ¿qué hay, en qué estado, qué puede rescatarse y qué es mejor reescribir? Esa auditoría tiene que hacerla alguien sin historia con el proyecto — alguien que pueda ver el código sin el sesgo de haber tomado las decisiones que lo produjeron.

No todas las reescrituras son malas. A veces el código tiene tres años, es frágil, y reescribirlo con lo que se sabe ahora toma menos tiempo que entenderlo y parchearlo. Pero esa decisión hay que tomarla con datos, no con intuición.

Si el problema es timing operacional

El proyecto necesita un calendario explícito que respete el calendario de retail. Eso significa identificar las ventanas disponibles — habitualmente los meses de menor volumen — y construir el plan hacia atrás desde ahí.

Si la próxima ventana es de seis semanas, el proyecto tiene que dimensionarse para esa ventana. Lo que no cabe en seis semanas entra en la siguiente.

Parece obvio. Pero muchos proyectos de retail fracasan porque el plan se construyó hacia adelante desde el inicio, sin mirar cuándo no se puede implementar.

Si el problema es resistencia operacional

Este es el más difícil porque no es técnico. La solución técnica puede ser perfecta y el proyecto puede fracasar igual.

Lo que funciona en retail es involucrar al equipo operacional desde el diagnóstico del problema, no desde la presentación de la solución. Que el encargado de bodega, el jefe de tienda o el coordinador de despacho sean parte de definir qué está mal hoy — no solo de aprender el sistema nuevo.

Y demostrar valor rápido. Un cambio pequeño que resuelve un problema concreto que ese equipo tiene hoy construye más confianza que una implementación grande que promete resolver todo en seis meses.

Lo que no resuelve el problema

Cambiar de proveedor sin cambiar el proceso. Si el proceso de gestión del proyecto no cambia — alcance fijo, rol claro de cada stakeholder, criterios de éxito definidos — el nuevo proveedor tendrá los mismos problemas que el anterior.

Agregar más tecnología. El sistema que no funciona no se arregla añadiendo otro sistema encima. A veces la solución correcta es más simple de lo que parece — y más difícil de implementar que lo que promete una demo.

Esperar el momento perfecto. En retail siempre hay una razón para no hacer cambios ahora. El proyecto que espera el momento perfecto espera indefinidamente. La condición para avanzar no es ausencia de riesgo — es riesgo manejable.

Lo que hace la diferencia

Los proyectos TI en retail que avanzan tienen en común algunas cosas concretas:

Un decisor con autoridad real que no cambia durante el proyecto. Si el sponsor del proyecto cambia cada tres meses, el proyecto cambia con él.

Un alcance definido y congelado para la fase en curso. Lo que entra en la siguiente fase se captura, no se agrega ahora.

Un equipo operacional en el loop desde el inicio — no como destinatarios, como co-diseñadores del proceso.

Y alguien que sabe distinguir cuándo el problema es técnico, cuándo es político, y cuándo es los dos al mismo tiempo.

---

Si tienes un proyecto TI en retail que lleva tiempo parado, el primer paso es entender exactamente por qué se paró — no la versión oficial, sino la causa real. Eso es lo que determinará si se puede retomar, cómo, y en qué plazo.