Cuando el trabajo se hace, pero nunca se cierra

A veces el problema no es que el trabajo esté mal hecho. Es que nunca se acordó cuándo termina. Esa diferencia parece menor, pero en la operación diaria suele convertirse en una fuente constante de fricción. Hoy hablaba con un amigo que lleva meses empujando su negocio y me dijo algo que se me quedó dando vueltas. Más tarde, revisando notas de proyectos anteriores y conversaciones con dueños de empresas técnicas, apareció otra vez el mismo patrón de siempre.

Directores y gerentes frustrados porque “el equipo no cierra bien”, “no documenta” o “depende demasiado de dos personas clave”. La sensación general es que el trabajo se hace, pero nunca queda del todo terminado. Y esa percepción termina erosionando la confianza interna, incluso cuando el equipo en campo está haciendo bien su parte.

Cuando cada área decide sola qué significa “terminar”

En una empresa de instalaciones con la que trabajé, el problema se expresaba exactamente así. Había técnicos muy buenos resolviendo en campo, ajustando sobre la marcha y dejando al cliente satisfecho en el momento. Desde su punto de vista, el trabajo estaba hecho cuando el equipo funcionaba y el cliente asentía. Desde dirección y administración, la sensación era completamente distinta.

Después aparecían los problemas. Faltaba información para facturar, justificar cambios o explicar por qué un servicio había costado más de lo previsto. No existía un sistema que definiera con claridad cuándo un trabajo estaba realmente completo. Cada área operaba con su propia definición de cierre, y todas parecían razonables desde su lugar.

Cuando lo analizamos con calma, apareció algo incómodo. No había una definición compartida de qué significaba cerrar un servicio. Para los técnicos, terminar era resolver el problema. Para administración, el trabajo no terminaba nunca porque siempre faltaban datos o evidencias. Ambos tenían razón, precisamente porque el flujo no estaba sostenido por una arquitectura común.

El costo de dejar el cierre en manos de las personas

Esa ambigüedad tenía efectos directos en el negocio. Facturas que salían tarde o mal, discusiones internas que se repetían cada mes y una dependencia creciente de los técnicos senior para reconstruir lo que ya había pasado. La ausencia de trazabilidad convertía cada cierre en una negociación posterior, con desgaste acumulado para todos.

El equipo no estaba fallando. Estaba operando dentro de un diseño que dejaba todo el peso del cierre en las personas. Eso deterioraba la eficiencia operativa y agotaba especialmente a quienes siempre tenían que explicar, justificar o recordar lo que ya no estaba documentado. El problema no era de actitud, sino de estructura.

La solución no pasó por exigir más ni por repetir el mantra de “hay que documentar mejor”. El primer paso fue mirar desde dirección y aceptar algo básico: nunca se había definido un estándar mínimo de cierre. Qué información debía quedar, qué evidencias eran obligatorias y en qué momento un servicio podía darse por terminado de verdad, apoyándose en una plataforma común.

Cuando eso se aclaró y se integró al flujo de trabajo, el cambio fue evidente. Los técnicos dejaron de cargar con la presión de decidir solos qué era suficiente. Administración dejó de reconstruir servicios a posteriori. La empresa empezó a depender menos de héroes y más de una forma compartida de trabajar, reforzada por un ERP bien definido y una mínima integración de sistemas.

Antes de señalar a tu equipo por no cerrar bien, conviene hacerse una pregunta sencilla pero incómoda. ¿Les dimos realmente una definición clara de qué significa cerrar un servicio en esta empresa, desde el liderazgo ejecutivo? Si te ha pasado algo parecido, desde dirección, administración o campo, me interesa leer cómo lo viven ustedes.