El síntoma
"Tenemos un equipo de sistemas. Nos cuesta un dinero. Y llevamos dos años hablando del mismo proyecto sin que arranque."
Esta conversación se repite en casi todas las empresas medianas. La tiene el dueño o el director general, normalmente con cierto cansancio en la voz. Y la primera explicación que viene a la cabeza es la más injusta: son lentos, les falta ambición, quizá hace falta gente nueva.
Casi nunca es eso.
Qué está pasando de verdad
Un departamento de sistemas hace 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 la integración con el cliente que te factura el 30% no se rompa un viernes por la tarde. Es reactivo, urgente, sin final y absolutamente crítico.
El segundo es construir lo que todavía no existe. El proyecto de trazabilidad. El sistema que te da el coste real por producto. La captura de datos de planta. Es lento, exige concentración, no da resultados en una semana y nadie lo echa de menos si no se hace. Al menos, no de inmediato.
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.
Y aquí está lo perverso: tu equipo tiene razón cada uno de esos días. Atender la línea parada era lo correcto. Sacar el informe para la auditoría era lo correcto. Nadie hizo nada mal. Y al final del año, el proyecto no ha avanzado.
No tienes un problema de personas. Tienes un problema de diseño.
Por qué las soluciones evidentes no funcionan
Antes de los pasos, tres salidas que parecen razonables y no lo son.
- Contratar a una persona más. Si entra en el mismo equipo, con el mismo teléfono, el día a día la absorbe en tres semanas. Habrás aumentado el coste y la capacidad de mantener, 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. Puede funcionar si alguien de dentro lo acompaña. Si no, 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.
Cómo plantearlo: siete pasos
Lo bueno es que esto no se arregla con un proyecto de dos años. Se arregla con decisiones que una dirección general puede tomar en una semana, aunque luego haya que sostenerlas.
- Pon un número al problema antes de tocarlo. Durante dos semanas, que el equipo anote a qué dedica el tiempo, separando mantener de construir. Sin medirlo es tu intuición contra la suya, y esa discusión no la gana nadie. Con el dato, la conversación cambia de tono en treinta segundos.
- Decide cuánta capacidad proteges y ponlo por escrito. Empieza por poco pero real: una persona día y medio a la semana es suficiente para arrancar. Lo importante no es el tamaño, es que exista.
- Define la barrera, y define qué la rompe. Esa capacidad protegida no coge el teléfono de incidencias, no está en la rotación de guardias y no es quien corre a la línea cuando se para la etiquetadora. Escribe la lista corta de lo que sí justifica romper la barrera. Si en esa lista cabe todo, no hay barrera.
- Dale al proyecto un dueño de negocio, con nombre y apellidos. Si el proyecto de trazabilidad es "cosa de informática", tiene muchas papeletas para morir. 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.
- Trocea hasta que haya una entrega cada tres o cuatro semanas. Un proyecto de dos años sin entregas intermedias es imposible de defender el día que llega la urgencia, porque no tiene nada que enseñar. Con entregas cortas, cada mes hay una razón para no pararlo.
- Cambia lo que se mira en el comité. Casi todas las empresas miden a sistemas por disponibilidad: cuántas incidencias, cuánto tiempo ha caído algo. Añade una línea de qué se ha construido este mes, al lado de la de incidencias. Lo que no se mide, no se protege.
- Revísalo a los noventa días, con dirección en la sala. No una reunión de sistemas, una revisión de dirección. Si la barrera se ha roto, hay que saber quién la rompió y por qué, y decidir si la decisión sigue en pie o fue un error.
Cómo saber a los noventa días si está funcionando
Cuatro señales, y ninguna es que el proyecto esté terminado.
- Ha habido al menos dos entregas, aunque sean pequeñas.
- Puedes nombrar a la persona protegida y ella sabe que lo está.
- La barrera se ha roto alguna vez, y esas veces están contadas. Cero roturas suele significar que nadie se la está tomando en serio, no que funcione.
- En el comité alguien que no es de sistemas pregunta por el avance del proyecto.
La objeción que te vas a encontrar
"No puedo permitirme sacar a nadie del día a día."
Es la respuesta honesta y entiendo de dónde viene. Pero conviene mirarla al revés: llevas dos años pagando un equipo completo y el proyecto está donde estaba. Ese coste ya lo has asumido, solo que repartido y sin que aparezca en ninguna partida. Proteger día y medio a la semana cuesta una fracción de lo que llevas gastado en no avanzar.
Y si de verdad no hay margen, esa es la conclusión: el proyecto no se va a hacer. Mejor decidirlo en el comité, por escrito y a la vista, que seguir dos años más hablando de él.
La pregunta que deberías hacerte
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.
Dónde se publicó la versión corta
Una versión más breve de esta idea, centrada en el sector de la alimentación, se publicó el 28 de julio de 2026 en Interempresas: Si tu proyecto de digitalización lleva dos años parado, no es porque tu equipo sea lento.