Si tu proyecto de digitalización lleva dos años parado, no es porque tu equipo sea lento

Hay una conversación que se repite en casi todas las empresas de alimentación que conozco. La tiene el dueño, o el director general, normalmente con cierto cansancio en la voz: "Tenemos un equipo de sistemas, nos cuesta un dinero y llevamos dos años hablando del mismo proyecto sin que arranque”.

La primera explicación que a uno le viene a la cabeza es la más injusta: son lentos, les falta ambición, quizá necesitamos gente nueva. Casi nunca es eso. Después de muchos años dirigiendo equipos de tecnología en diferentes entornos, puedo decir que el problema rara vez está en las personas. Está en una confusión de fondo que casi nadie nombra.

Un departamento de sistemas hace, en realidad, dos trabajos que no se parecen en nada.

El primero es mantener lo que ya existe. Que el ERP no se caiga. Que la línea de envasado siga imprimiendo etiquetas. Que el sistema de trazabilidad registre cada lote. Que la integración con la plataforma logística del cliente que te factura el 30% no se rompa un viernes por la tarde, en plena expedición. Es un trabajo reactivo, urgente, sin final, y absolutamente crítico. Si falla, para el negocio.

El segundo es construir lo que todavía no existe. El proyecto de trazabilidad unitaria. El sistema que te da el coste real por producto. La automatización del almacén de producto terminado. La captura de datos de planta para saber por qué esa línea rinde un 12% menos que la de al lado. Es un trabajo lento, que exige concentración, que no da resultados en una semana y que nadie echa de menos si no se hace. Al menos, no de inmediato.

En la jerga esto se llama mantener y evolucionar, o en inglés ‘run’ y ‘change’. Y ahora viene lo importante: cuando las mismas personas hacen los dos trabajos, el primero siempre se come al segundo. Siempre. No a veces, no cuando hay una crisis. Siempre.

Imagina a tu responsable de sistemas un martes por la mañana. Tiene el día bloqueado para avanzar en el proyecto que tú le has pedido. A las 8:10 llama el jefe de producción: la línea 3 se

ha parado porque la etiquetadora no lee los códigos y hay una expedición esperando. A las 11 h, calidad necesita un informe de trazabilidad para una auditoría del IFS que es pasado mañana. A las 16:30 h, el operador de un almacén reporta que un lote se ha quedado bloqueado en el sistema y no puede expedirse.

Ninguna de esas tres cosas puede esperar a mañana. Todas tienen a alguien delante, molesto, con un problema real, y algunas con producto perecedero de por medio. El proyecto, en cambio, no protesta. El proyecto espera en silencio.

Multiplica ese martes por doscientos días al año. Ese es tu proyecto de dos años.

Y aquí está lo perverso: tu equipo tiene razón cada uno de esos días. Cada decisión individual fue correcta. Atender la línea parada era lo correcto. Sacar el informe para la auditoría era lo correcto. Desbloquear el lote era lo correcto. Nadie hizo nada mal. Y, sin embargo, al final del año, el proyecto no ha avanzado.

No tienes un problema de personas. Tienes un problema de diseño.

Antes de contarte lo que sí funciona, déjame quitarte de encima tres soluciones que parecen razonables y no lo son.

Contratar a una persona más. Si esa persona entra en el mismo equipo, con el mismo teléfono, la absorberá el día a día en tres semanas. Habrás aumentado el coste y la capacidad de mantenimiento, no la de construir.

Pedirle al equipo que se organice mejor. Ya lo intentan. El problema no es de agenda, es de estructura. Nadie puede protegerse solo de una línea parada cuando hay producto esperando.

Externalizar el proyecto entero a una consultora. Puede funcionar, pero si nadie de dentro lo acompaña, acabas con un sistema que nadie de tu casa entiende y que se convierte en el próximo problema que no puedes tocar. Has comprado tiempo y has vendido conocimiento.

Sobre este último punto, quiero decir, que no es mala práctica si mantienes el control. Sacar el desarrollo de una solución que sea usable a mínimos, es una buena opción (el famoso producto mínimo viable), pero espero que tengas una buena definición de lo que se necesita.

La solución no es tecnológica. Es organizativa, y es más simple de lo que parece, aunque cueste sostenerla.

Separa a las personas, no las tareas. Alguien tiene que estar protegido del día a día. Puede ser una persona, un día y medio a la semana, un equipo pequeño, alguien de fuera. Lo importante no es el tamaño, es que esa capacidad tenga una barrera real: no coge el teléfono de las incidencias, no está en la rotación de guardias, no es quien corre a la línea cuando se para la etiquetadora.

Si esa barrera depende de la buena voluntad, no existe. Tiene que decidirla la dirección, y tiene que doler un poco. Sé que es fácil decirlo, pero lo he hecho.

Acepta que el mantenimiento tiene un coste, y hay que pagarlo. El día a día no es un residuo del trabajo bueno. Es el trabajo. Si lo tratas como una molestia que la gente debe atender “en sus ratos”, se comerá todo lo demás y encima quemará al equipo.

Mide lo que se construye, no solo lo que se mantiene. Casi todas las empresas miden a su equipo de sistemas por disponibilidad: cuántas incidencias, cuánto tiempo ha caído un sistema. Muchas veces nadie le pregunta al equipo qué construyó este trimestre. Lo que no se mide, no se protege (ni se puede evolucionar).

Y haz que el proyecto tenga un dueño de negocio, no de sistemas. Si el proyecto de trazabilidad es “cosa de informática”, tiene muchas cartas para morir, soy informático, puedo decirlo. Si es del director de operaciones, que lo necesita para pasar la próxima auditoría sin sustos y para dejar de perder margen en mermas, la cosa cambia.

No es "¿por qué mi equipo de sistemas no avanza?"; es "¿cuánta capacidad de mi equipo está protegida del día a día?".

Si la respuesta es ninguna, ya sabes por qué llevas dos años con el mismo proyecto. Y también sabes que no es culpa de ellos.