Coste de la interrupción: lo que el cronómetro no ve
El pedido suelto cuesta más que el tiempo de atenderlo. En un estudio con 27 empleados, volver al trabajo interrumpido tardó, de media, entre 11 y 17 minutos según el canal. Quien cronometra solo la ejecución subestima el coste. El ajuste es de arquitectura: cambiar por dónde entra el pedido.
¿Por qué cronometrar solo la ejecución subestima el coste?
Porque el pedido suelto tiene dos partes, y el cronómetro suele captar una. La primera es hacer lo que se pidió. La segunda es volver a lo que la persona estaba haciendo, y esa suele quedar fuera de la hoja de tiempos.
En un estudio de campo presentado en CHI 2007, Shamsi Iqbal y Eric Horvitz siguieron durante dos semanas a 27 empleados de Microsoft Research, con 2.267 horas de actividad registradas. Midieron la fase de retomada: el intervalo entre la señal de que la persona quiere volver a la tarea y el regreso al estado en que estaba antes de salir de ella. Tras un correo respondido al momento, la retomada promedió 16 minutos y 33 segundos. Tras un mensaje instantáneo respondido al momento, 10 minutos y 58 segundos. En las respuestas aplazadas, fueron 15 minutos y 50 segundos y 12 minutos y 2 segundos.
La dispersión pesa tanto como la media. La desviación estándar de la retomada tras un correo aplazado fue de 25 minutos, lo que indica casos cortos junto a casos muy largos. Según los autores, el 27% de las suspensiones de tarea tardó más de dos horas en retomarse. El estudio mide el intervalo y no afirma que todo él sea tiempo parado.
El mecanismo tiene nombre. Sophie Leroy, de la University of Washington Bothell, describe en su página el residuo de atención: al cambiar de tarea, parte de la atención se queda con la anterior, y eso ocurre con facilidad cuando la tarea se dejó inacabada o interrumpida. Según ella, el rendimiento en la tarea siguiente tiende a empeorar, sobre todo si es exigente.
¿Qué cambia cuando el coste no aparece en el tiempo?
El indicador de tiempo puede mejorar mientras el coste sube en otro lugar. En un experimento presentado en CHI 2008, Gloria Mark, Daniela Gudith y Ulrich Klocke compararon a 48 participantes que, en el papel de responsable de RR. HH. de una empresa simulada, respondían correos, con y sin interrupciones cada dos minutos.
Quienes fueron interrumpidos terminaron antes: 22,77 minutos sin interrupción, frente a 20,31 con una interrupción del mismo tema y 20,60 con un tema distinto, sin contar el tiempo de la interrupción en sí. El precio apareció en las respuestas de los participantes. El estrés pasó de 6,92 a 9,46 y 9,13, en una escala de 1 a 20. El esfuerzo pasó de 9,50 a 11,04 y 11,52. La frustración y la presión de tiempo también subieron.
La lectura de los autores es que las personas compensan trabajando más rápido y escribiendo menos, a costa de estrés y esfuerzo. Para una operación, la hipótesis que hay que probar es esta: el tiempo por tarea puede mejorar en una semana en que el equipo está peor.
¿Qué no demuestran estos estudios?
Muestran el orden de magnitud del problema, no su tamaño en su empresa. Algunos límites importan para quien decide.
Ninguno de los dos mide una operación de pyme. El estudio de Iqbal y Horvitz viene de una sola organización de investigación, y los autores reconocen que no pueden probar que la alerta causó el cambio de tarea: los vincularon con una regla de 15 segundos. El de Mark es de laboratorio, con un 81% de estudiantes universitarios alemanes y unos 20 minutos de trabajo. Los autores dicen no saber si las personas se adaptarían con el tiempo y tratan la explicación de la aceleración como una interpretación, no como un mecanismo probado.
Además, una alerta de correo no es un pedido de operación. Quien recibe "mándame la copia de la factura" la ejecuta y la registra, y eso es otra tarea. Por eso la medición propia va antes de cualquier cuenta.
¿Cómo aparece esto en la operación de una pyme?
Como una cifra que suele quedar sin registro. El ejemplo siguiente es una hipótesis ilustrativa, no una medición.
Imagine la administración de una distribuidora con seis personas. Los pedidos de copia de factura, estado de entrega y corrección de datos llegan por mensaje directo a quien esté más cerca. Suponga que un operador recibe 24 pedidos al día y tarda 4 minutos en ejecutar cada uno. Son 96 minutos, el 20% de una jornada de 8 horas. Es lo que muestra la hoja de tiempos.
Ahora suponga, sin ninguna medición, que cada interrupción cuesta 6 minutos de retomada. Son 144 minutos más, y el total llega a 240 minutos, la mitad de la jornada. Si la retomada costara 2 minutos, serían 48 más y 144 en total, el 30%. En esta hipótesis, el rango va del 30% al 50% de la jornada. Lo que decide dónde cae la operación dentro de él es un dato que suele quedar fuera de la hoja de cálculo: cuánto tarda el operador en volver a lo que hacía.
Los pedidos así entran con frecuencia en la lista de tareas repetitivas por automatizar. Si la automatización llega antes de cambiar cómo entra el pedido, hereda el diseño de la interrupción. Sobre cómo localizar dónde se acumula la espera, vea 7 formas de mapear cuellos de botella ocultos.
¿Qué hacer antes de automatizar el pedido suelto?
Esta parte es lectura nuestra, no resultado de los estudios: el problema aquí rara vez es la herramienta que ejecutará el pedido, y sí el diseño de cómo llega. Cuatro pasos, en este orden.
Primero, dé al pedido una puerta única, con registro: un formulario corto o una cola con tipo, solicitante, responsable y plazo. El pedido deja de ser un mensaje que interrumpe y pasa a ser un elemento que espera. El formulario no puede pedir más de lo que el mensaje ya traía, o el equipo vuelve al atajo.
Segundo, separe lo urgente de lo rutinario con una regla escrita. Lo urgente interrumpe, y la regla dice qué es urgente. Lo rutinario se atiende en franjas acordadas, por ejemplo dos al día.
Tercero, mida durante dos semanas, con cuatro datos por pedido: tipo, hora de llegada, hora de inicio y tiempo de ejecución. La diferencia entre llegada e inicio es la espera. Añada una pregunta al operador al final del día: ¿en qué pedidos perdió el hilo de lo que estaba haciendo?
Cuarto, solo entonces automatice, empezando por el tipo que más se repite. Para los pedidos de estado, una automatización que suele funcionar es dejar que el solicitante consulte el estado sin tener que pedirlo.
El camino opuesto al pedido por mensaje aparece en el caso Reatop: los recolectores registran pesajes y cumplimiento en la propia aplicación, incluso sin señal, y el dato se sincroniza después. El registro nace donde ocurre el trabajo.
Preguntas frecuentes
Mi equipo no acepta cambiar la forma de pedir. ¿La cola no se convierte en más burocracia?
Puede convertirse, si pide más de lo que pedía el mensaje. Empiece por un único tipo de pedido, con pocos campos, y muestre al solicitante el estado de su pedido, que es lo que él gana. Si la cola es más lenta que preguntar a alguien, el equipo la esquivará, y ese rodeo es información sobre el diseño.
¿Cómo medir el resultado sin un sistema terminado?
Con una hoja de cálculo de dos semanas y los cuatro datos del tercer paso. No prueba una ganancia de productividad, pero muestra el volumen por tipo y qué pedidos rompen el trabajo de alguien. Basta para decidir qué cambiar primero y da una línea base para comparar después.
¿Y si la cola solo traslada el cuello de botella?
Puede trasladarlo. Siga la espera entre llegada e inicio: si crece, la franja de atención es demasiado larga o ese tipo de pedido debería ser urgente. El ajuste está en la regla de la cola, no en volver a la interrupción.
El siguiente paso
Si los pedidos sueltos consumen su operación y no sabe cuánto, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, sirve para mapear por dónde entran: hable con Yowpi.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico