Método Doc: cinco pasos, cada uno con su entregable

Por qué empiezo por la persona que ejecuta el proceso

Porque es la única que sabe cómo funciona de verdad, con todas sus excepciones. La gerencia conoce el proceso que debería ocurrir; quien lo hace cada día conoce el que ocurre, incluido el apaño de los viernes y el cliente al que se le factura distinto desde 2019.

Automatizar el proceso teórico produce un sistema que falla la primera semana. Por eso esa conversación es la primera y no la última.

Por qué simplifico antes de automatizar

Automatizar un paso que sobra es hacer más deprisa algo que no hacía falta. Por eso, antes de tocar un programa, miro el proceso buscando lo que sobra, con un método que viene de las fábricas y se llama Lean: esperas, búsquedas, datos que se teclean dos veces, papeles que viajan de una mesa a otra, errores que se corrigen a mano. Lo que sobra se quita, no se automatiza.

Lo dibujo en un mapa de proceso estándar, BPMN, que es un dibujo con reglas fijas que entiende cualquier otro consultor o programador: así lo que te dejo no depende de mí. Y a veces, quitando pasos, el problema desaparece y no queda nada que automatizar. Entonces te lo digo y paramos ahí. Lo cuento con más detalle en mejora de procesos.

Cómo mido las horas

Antes de cambiar nada, mido el proceso con quien lo hace, en su sitio y con el trabajo real de ese día: cuánto tarda, cuántas veces pasa a la semana y cuántos errores hay que corregir al mes. De ahí salen tres cifras de partida —horas, errores y euros—, y son tuyas: te las llevas aunque no sigamos. Para pasar las horas a euros uso lo que cuesta una hora de trabajo administrativo, y te enseño de dónde sale la cuenta.

Cuando lo nuevo funciona, se mide igual, con la misma persona y la misma cuenta. La diferencia es lo que te ha devuelto, no una estimación mía. Si lo mantengo yo, te mando un informe con las horas que se lleva ahora el proceso, y si lo que te devuelve baja, sale en el informe y lo miramos. Sin cifras de partida no hay antes y después: sólo la impresión de que va mejor.

Qué pasa si tu equipo se resiste

Es la causa más común de que un sistema se abandone a los tres meses, y es razonable: nadie colabora entusiasmado en algo que cree que va a dejarle sin trabajo.

Lo que hago es decirlo el primer día y en voz alta: el objetivo es quitarles la parte tonta del trabajo, no el trabajo. Si el objetivo real fuera reducir plantilla, no es un proyecto que acepte, entre otras cosas porque saldría mal.

Qué pasa cuando algo falla en producción

Se nota. Cada proceso lleva registro de lo que ha hecho y una alerta cuando algo no sale, a tu correo o a tu WhatsApp. Una automatización que se rompe en silencio es peor que no tenerla, porque durante semanas crees que el trabajo está hecho.

Después, algo cambia fuera aunque tú no toques nada: los proveedores de IA retiran modelos y cambian tarifas varias veces al año, con semanas de aviso, y un programa que usas puede cambiar cómo se conecta. Por eso hay que sostenerlo. Si lleva algo que hay que vigilar siempre, como un modelo de IA, conviene el mantenimiento desde el primer mes, porque el modelo hay que cuidarlo; en el resto, si prefieres llevarlo tú, te dejo la documentación y te explico qué vigilar.

Qué pasa si desaparezco

Trabajo solo, así que es una pregunta razonable y prefiero responderla antes de que la hagas.

En lo que monto a medida, el código está en un repositorio a tu nombre desde el primer día, no al final. Lo que monto queda documentado. Los servidores y las cuentas de terceros están a tu nombre, con tus claves. Y uso herramientas estándar y aburridas a propósito —n8n, Python, Postgres— para que cualquier desarrollador pueda continuar sin aprender nada mío.

Así que, en eso, si te vas, no tienes que pedirme nada. En Pedidos sin teclear y Partes y albaranes digitales, en cambio, qué queda a tu nombre lo hablamos antes de empezar.