Mejorar un proceso con datos reales y un piloto

El gerente de operaciones de una distribuidora le pide a Claude “un proceso de devoluciones mejor”. Claude devuelve un plan impecable: un sector exclusivo de devoluciones, tres puestos de control, reposición en el día. El supervisor del depósito lo lee y se ríe: no hay lugar para un sector nuevo, las devoluciones llegan en picos después de cada promoción y los reembolsos los aprueba finanzas.

El plan no estaba mal escrito. Estaba hecho para un depósito que no existe, porque el pedido no decía nada del depósito real.

Claude mejora el proceso que le describís

Para la mejora de procesos (process optimization), Claude es tan bueno como los datos que recibe. Si le pedís “las buenas prácticas del rubro”, te da un promedio de empresas que no son la tuya. Si le das tu operación, puede analizarla.

Lo que conviene pasarle:

• los pasos actuales, en orden, con quién hace cada uno;
• los volúmenes y tiempos: cuántos casos por mes, cuánto tarda cada etapa (una exportación con fechas de cada etapa vale oro);
• las restricciones (constraints): espacio, personal, sistemas que no se pueden cambiar, aprobaciones que exige una política;
• las quejas más frecuentes de quienes sufren el proceso.

Del mapa a las opciones

Con eso, el trabajo tiene tres pasos:

1. Armar el mapa del proceso (process map). Pedile a Claude que ordene los pasos y calcule cuánto tiempo se va en cada uno, incluida la espera entre pasos, que suele ser donde más se pierde.
2. Encontrar el cuello de botella (bottleneck). En un proceso de compras de 300 pedidos por mes, puede resultar que la aprobación tarda una hora y el pedido pasa cinco días esperando en una bandeja de entrada.
3. Pedir opciones con sus ventajas y desventajas (trade-offs), no una única respuesta. “Dame tres formas de resolver la espera en aprobaciones, con lo que gana y lo que arriesga cada una, respetando que finanzas revisa todo pedido de más de cierto monto.”

Después, validá el análisis con quienes hacen el trabajo. Claude ve los datos; el equipo sabe que los martes el sistema se cae o que un proveedor siempre manda las facturas por mail aparte. Si el mapa no coincide con lo que viven, falta un dato.

Probar antes de cambiar todo

La mejor opción no se implanta en toda la empresa el lunes. Se prueba en una prueba piloto (pilot) acotada: una sucursal, una categoría de compras, un mes. Antes de empezar, definí qué vas a medir (días de punta a punta, pedidos devueltos, horas del equipo) y medilo también en el proceso actual, para tener contra qué comparar.

Pedido flojo	Pedido que sirve
“Dame el proceso ideal de compras”	“Estos son los pasos, los tiempos de cada etapa del último mes y las quejas; marcá dónde se pierde el tiempo”
“Investigá qué hacen los líderes del rubro”	“Con estas restricciones de espacio y aprobación, proponé tres opciones con sus pros y contras”
“Adoptemos el plan de Claude”	“Probemos la opción B en una sucursal un mes y comparemos con el proceso actual”

Las trampas típicas

• Adoptar tal cual un “proceso de buenas prácticas” que no conoce tu operación.
• Pedir más investigación sobre otras empresas cuando lo que falta son tus propias restricciones.
• Descartar a Claude porque el primer plan salió genérico: el pedido era genérico.
• Usarlo solo para redactar el mail que explica por qué el proceso tarda, en lugar de arreglarlo.
• Saltar a comparar software nuevo antes de saber dónde se va el tiempo.

En el examen

Si el escenario muestra un plan genérico que choca con la realidad, buscá la opción que le da a Claude las restricciones reales, pide opciones con trade-offs y prueba la mejor en un piloto. Si el escenario tiene datos disponibles (procedimiento, tiempos, quejas), la respuesta los usa para mapear el proceso y después lo valida con el equipo. Descartá las que adoptan sin adaptar, las que abandonan a Claude y las que solo comunican el problema.