La mejora operativa que sí se sostuvo: qué hizo distinto Hidromóvil

Una operación de campo con 40 servicios diarios dependía de capturas manuales y folios impresos. La mejora no se degradó: se sostuvo porque el proceso dejó de vivir en la memoria y pasó a un sistema.

En esta serie insisto en una idea incómoda: la mayoría de las mejoras operativas no fallan al diagnosticarse, fallan al sostenerse. Se implementan, funcionan unos meses y regresan a como estaban, porque dependían de que las personas hicieran algo distinto, de forma consistente, para siempre. Vale la pena, entonces, mirar una que no regresó.

Hidromóvil recolecta y trata aguas y materiales residuales de restaurantes e industrias: 40 servicios diarios con 15 camiones cisterna. Es una operación de campo intensa, del tipo donde una mejora mal sostenida se erosiona en semanas. La suya se sostuvo. Este es el porqué —contado desde la operación, no desde el software.

El proceso que no aguantaba

Antes, la operación diaria dependía de capturas manuales y folios impresos. Sobre el papel, el proceso existía y la gente lo seguía. En la práctica, cargaba cuatro debilidades que lo condenaban a degradarse:

1

Capturas manuales después del servicio

Cada orden se anotaba en papel en campo y se recapturaba en oficina. Doble trabajo, doble oportunidad de error y un desfase entre lo que pasó y lo que quedó registrado.

2

La facturación tardaba hasta 24 horas

El ciclo de cobro dependía de que la información llegara, se leyera y se volviera a teclear. El dinero se movía al ritmo del papel, no del servicio.

3

Sin visibilidad en tiempo real

Ni el equipo operativo ni administración veían el estado de la operación al momento. Las decisiones se tomaban sobre datos de ayer.

4

Todo dependía de que alguien recapturara

El proceso ’nuevo’ seguía viviendo en la disciplina de las personas: mientras alguien recapturara bien y a tiempo, funcionaba. Ese es justo el tipo de mejora que se degrada.

Ninguna de estas debilidades era falta de voluntad del equipo. Eran estructurales: el proceso vivía en el papel y en la memoria de quien recapturaba. Un buen diagnóstico podía ordenarlo, pero para sostenerlo hacía falta que dejara de depender de eso.

Qué cambió realmente

El cambio de fondo no fue "digitalizar por digitalizar": fue mover el proceso de la memoria a un sistema. Se construyeron una plataforma web para la operación administrativa y una app móvil para los operadores en campo, con un principio simple: que hacer el proceso bien fuera el camino natural, no una tarea extra al final del día.

  • La captura ocurre donde ocurre el servicio. El operador registra en la app, en campo, en el momento. Se acabó la recaptura posterior en oficina.
  • Las órdenes se asignan y se siguen en tiempo real. Campo y oficina ven el mismo estado, no versiones desfasadas.
  • Los datos del servicio alimentan la facturación solos. El ciclo de cobro deja de esperar a que alguien vuelva a teclear.
Operador capturando un servicio en campo desde una app móvil, sin recapturas posteriores

Por qué esta vez se sostuvo

El resultado más citable es el número: 75% menos tiempo de captura y facturación. Pero para el argumento de esta serie, lo importante no es el número —es por qué no se degradó con el tiempo.

Y la prueba de que no se degradó es el tiempo mismo: en tres años se han gestionado más de 49 mil servicios en el sistema —capturados en campo, sin recapturas ni papel—. No fue un pico inicial que se apagó; se volvió la forma de operar.

Se sostuvo porque la mejora dejó de depender de que alguien recordara hacerla. El nuevo flujo quedó embebido en la forma de trabajar: capturar en campo no es un paso extra que se pueda saltar, es cómo se hace el servicio. La rotación deja de borrar el proceso, porque quien entra opera dentro del sistema desde el primer día. Y la degradación, si aparece, es visible —no una sorpresa a fin de mes.

La mejora no se sostuvo por disciplina; se sostuvo porque ya no dependía de ella.

Una operación de campo que fluye ordenada porque el proceso vive en un sistema

Qué mediría un consultor aquí

Si tú hubieras diagnosticado esta operación, el diagnóstico habría sido tuyo: el cuello de botella estaba en el ciclo captura–recaptura–facturación, y el rediseño consistía en eliminar la recaptura y acercar el registro al momento del servicio. Ese criterio es la parte difícil, y es consultoría, no software.

Lo que la tecnología aportó fue sostener ese rediseño y volverlo medible: el 75% de reducción en el ciclo, la visibilidad en tiempo real, la facturación que dejó de esperar al papel. El diagnóstico definió el qué; el sistema garantizó el que siguiera pasando. Esa es exactamente la división de trabajo que proponemos a los consultores con quienes colaboramos.

Puedes ver la ficha completa de este proyecto en el caso de Hidromóvil.

Resumen

  • Hidromóvil opera 40 servicios diarios con 15 camiones; su proceso manual estaba condenado a degradarse.
  • El problema no era voluntad: el proceso vivía en capturas manuales, folios y recaptura en oficina.
  • La mejora movió el proceso de la memoria a un sistema: captura en campo, sin recapturas, facturación automática.
  • Se sostuvo porque dejó de depender de disciplina; el resultado fue 75% menos tiempo de captura y facturación.
  • La prueba de que se sostuvo es el tiempo: en tres años, más de 49 mil servicios gestionados en el sistema.
  • El diagnóstico define el qué (consultoría); el sistema garantiza que siga pasando (tecnología).

Preguntas frecuentes

¿El mérito es del software o del rediseño?
De ambos, en su orden. Sin un buen rediseño del ciclo captura–facturación, automatizar solo habría acelerado el desorden. El software no inventó la mejora: la sostuvo y la volvió medible.

¿El 75% se mantiene o fue un pico inicial?
Se mantiene porque no depende de que la gente "se acuerde" de trabajar distinto. La captura en campo es la forma de operar, no un esfuerzo adicional; por eso el resultado no se erosiona con el tiempo ni con la rotación. La prueba: tres años y más de 49 mil servicios después, sigue siendo la forma de operar.

Soy consultor de operaciones. ¿Dónde entro yo en un caso así?
En la parte que más pesa: leer la operación y diseñar el rediseño. La ejecución tecnológica que lo sostiene la puede llevar un socio técnico, sin que tú tengas que construir ni mantener el sistema.

¿Diagnosticas mejoras que necesitan sostenerse?

Si ordenas operaciones como esta y el rediseño necesita tecnología para no degradarse, en Toracom somos el brazo de ejecución: tú diagnosticas, nosotros construimos, automatizamos y mantenemos. Tú te quedas con el criterio y la relación.

Una mejora que se sostiene no es la que más disciplina exige, sino la que dejó de necesitarla.