Imaginemos que en una empresa aprobar una solicitud tarda varios días. Para acortar ese plazo, le piden a tecnología que mejore el formulario: menos campos, datos precargados, una interfaz más sencilla.
El formulario mejora. La solicitud sigue esperando.
¿Por qué? Porque solo una persona puede aprobarla, y revisa los pendientes una vez por semana.
Es un ejemplo hipotético, pero muestra un error de gestión muy concreto: intervenir una actividad sin entender qué limita el resultado que queremos mejorar.
#.Primero hay que entender el trabajo
Que algo se pueda automatizar no justifica hacerlo. Primero hay que saber qué objetivo cumple, qué problema tiene y qué beneficio esperamos.
Yo empezaría por conversar con quienes hacen el trabajo y ver cómo lo resuelven:
- ¿Dónde esperan?
- ¿Qué información les falta?
- ¿Qué decisiones dependen de otra persona?
- ¿Cuántas veces tienen que devolver una solicitud?
Eso ayuda a separar síntomas de posibles causas. Después lo contrastaría con datos: tiempos de espera, trabajo acumulado, errores y capacidad disponible.
Una cola te dice dónde investigar. No te dice por sí sola cuál es la causa.
Y la tarea más larga no siempre es el cuello de botella. Si hablamos de cuánto trabajo sale, lo que importa es la capacidad frente a la demanda. Si hablamos de cuánto espera cada solicitud, también importa cada cuánto se revisa. Alguien que aprueba una vez por semana puede tener tiempo de sobra y aun así sumar días a cada respuesta.
Conviene medir el tiempo desde que llega la solicitud hasta que se responde, y separar cuánto es espera y cuánto es trabajo.
Con eso a mano, una prueba simple para empezar. Si en cada revisión se resuelve lo que llegó, y la mayor parte de la espera pasa entre una revisión y la siguiente, probaría revisar más seguido. Si durante varias semanas entran más solicitudes de las que salen, investigaría qué frena las salidas: el tiempo que tiene el aprobador, información que falta o solicitudes que vuelven porque llegaron incompletas.
Es una pista, no un diagnóstico. Según lo que aparezca, tocará dedicarle más tiempo, delegar, cambiar los criterios o reducir lo que llega incompleto.
#.Lo que Toyota plantea antes de poner una máquina
Lean viene del sistema de producción de Toyota. Como yo lo entiendo, propone mirar cómo se entrega valor y reducir el desperdicio en todo el recorrido. Acelerar una actividad aislada puede dejar intacta la espera de quien necesita el resultado.
El Toyota Production System tiene dos pilares:
- Just-in-Time: producir lo necesario, cuando se necesita y en la cantidad requerida. No es esperar al último momento; exige coordinar las etapas.
- Jidoka (automatización con un toque humano): detectar anomalías y detener el trabajo para que los defectos no sigan avanzando.
Al explicar jidoka, Toyota dice que, en vez de empezar con una máquina, primero hay que hacer el trabajo a mano, bien y sin tropiezos. Mejorarlo, eliminar el desperdicio y lograr que cualquiera pueda hacerlo. Solo después la máquina toma ese trabajo, con la detección de anomalías incorporada.
Toyota habla de máquinas, no de software. Y la analogía tiene un límite: si podemos probar una automatización pequeña, de bajo riesgo y con efectos que se puedan deshacer, puede ser justamente lo que nos da los datos para entender el flujo. La diferencia está en saber qué queremos aprender con eso.
Eso sí, revertir el código no revierte lo que la automatización ya hizo. Si aprobó solicitudes, envió información o cambió datos, eso queda.
Llevado por analogía a nuestro formulario: primero entender qué solicitudes llegan incompletas y por qué. Después automatizar su paso al siguiente departamento.
Una integración puede transmitir la información perfectamente. Eso no nos dice si es la información que hacía falta.
#.Kanban: decidir cuándo entra más trabajo
La Kanban Guide pide definir y visualizar el flujo, gestionar activamente lo que está en curso y mejorar cómo circula. También pide controlar explícitamente cuánto trabajo en curso hay, el famoso WIP.
Por eso llenar un tablero de tarjetas es apenas el comienzo. Falta decidir qué entra, cuándo y bajo qué condiciones.
Volvamos a las aprobaciones. Si seguimos empezando solicitudes mientras las anteriores esperan aprobación, podemos acumular trabajo abierto sin resolver más.
Limitar el WIP no le da más tiempo al aprobador. Puede evitar que sigamos empezando trabajo que todavía no podemos terminar. Pero tampoco cambia por sí solo la frecuencia de aprobación: los pendientes pueden quedarse esperando antes de entrar al tablero.
Por eso importa medir desde que llega la solicitud, no desde que empezamos a trabajarla.
Qué salida toca lo dice lo que encontremos en la bandeja. Una herramienta puede ayudar a aplicarla, pero no la elige por nosotros. Son decisiones de gestión.
#.No todo proceso merece la misma inversión
Lean y Kanban ayudan a mirar el flujo. Pero también hay que decidir qué resultados priorizar, qué riesgos aceptar y dónde invertir.
COBIT 2019, por ejemplo, plantea adaptar el gobierno de la información y la tecnología al contexto de cada organización. Y un artículo de ISACA propone ir más allá: fijar el nivel de capacidad objetivo proceso por proceso, porque no todos son igual de críticos.
Mi lectura práctica: llevar todos los procesos al mismo nivel no tiene sentido si sus consecuencias son distintas.
Un proceso de recuperación de datos puede merecer inversión aunque casi nunca se use. Una tarea diaria puede funcionar suficientemente bien, y perfeccionarla aporta poco.
La frecuencia, la velocidad y lo fácil que sea automatizar son datos para decidir. Ninguno reemplaza entender el valor, el riesgo y el costo del cambio.
Investigar también tiene un costo. No pediría el mismo análisis para simplificar un campo opcional que para cambiar quién puede aprobar una solicitud. Lo que sí pediría en ambos casos es tener claro qué queremos mejorar y cómo vamos a comprobarlo.
#.Mejorar y volver a mirar
En el ejemplo, yo probaría un cambio pequeño dirigido a la espera de aprobación, que podamos revertir si no funciona. Si la espera depende de varias cosas a la vez (quién aprueba, con qué criterios y cada cuánto se revisa), un solo cambio puede no mover el plazo, y eso también es un resultado.
Después seguiría las solicitudes:
- ¿Se resuelven antes?
- ¿Aumentaron los errores?
- ¿La carga terminó en otro equipo?
El formulario también puede merecer mejoras: menos errores, menos esfuerzo, más accesible. Eso vale por sí mismo. Pero si lo que queremos es responder antes, quiero entender dónde se van los días de quien espera la respuesta.