Gap: qué se decide antes de automatizar un horario

Un horario puede cuadrar en la pantalla y fallar en la tienda.

Imaginemos una sucursal que ajusta sus turnos cada vez que cambia la previsión de visitas. El cálculo respeta el presupuesto y cubre las horas de apertura. Pero cada modificación obliga a alguien a reorganizar un traslado, una clase o el cuidado de otra persona. Si después cuesta cubrir el turno, el encargado vuelve a corregir el plan. El sistema registra la última versión; el coste de llegar hasta ella puede quedar fuera.

Es un ejemplo hipotético. La pregunta que contiene es concreta: ¿qué estamos optimizando cuando decimos que un horario es eficiente?

Un experimento realizado con Gap permite examinar esa pregunta con algo más que intuición. También obliga a tener cuidado con una explicación tentadora: atribuir una mejora empresarial al software que formó parte de ella.

En un ensayo aleatorizado con 28 tiendas de Gap en Chicago y San Francisco, realizado entre noviembre de 2015 y agosto de 2016, se evaluó un conjunto de prácticas de programación responsable. El artículo académico de 2022 reportó un aumento del 5,1% en productividad y del 3,3% en ventas en su análisis por asignación al tratamiento. Son resultados de ese experimento, no una previsión para otra empresa. Management Science.

La intervención adicional incluía mayor regularidad de turnos, un núcleo con horas más estables, dotación adicional focalizada y una app para intercambiarlos. El aviso con dos semanas de anticipación y la eliminación de turnos sujetos a cancelación ya se aplicaban tanto al grupo tratado como al de control. Descripción del equipo investigador.

Esa combinación importa. El diseño evaluó un paquete; no aisló el efecto de la aplicación. Tampoco permite atribuir la diferencia entre grupos únicamente a las prácticas que ambos compartían.

La lectura útil para quien decide sobre tecnología empieza ahí: había reglas de trabajo, capacidad y participación de las personas dentro de la intervención. Reducirla a una compra de software borraría parte de lo que se estaba probando.

El informe inicial de 2018 recogió otras fuentes de inestabilidad señaladas por gerentes: información inexacta de envíos, promociones modificadas tarde y visitas de responsables corporativos. Es evidencia de ese contexto, no un diagnóstico de todo el comercio minorista. Informe original, sección sobre fuentes de inestabilidad.

Conviene distinguir esas causas porque llevan a decisiones distintas. Si llega más trabajo del previsto, quizá haga falta capacidad adicional. Si una promoción se comunica tarde, un mejor pronóstico de visitas puede dejar intacto el problema de coordinación. Y si una persona solicita cambiar un turno, tratar su petición como un error del plan puede ocultar una necesidad legítima.

No hace falta presumir cuál de esas situaciones domina. Hace falta conservar la diferencia mientras se investiga.

Volvamos a la sucursal hipotética. El gerente observa cambios frecuentes y solicita una herramienta que regenere los horarios automáticamente. Antes de diseñarla, el equipo podría revisar una muestra de modificaciones: qué cambió, quién lo pidió, con cuánto aviso y qué consecuencia tuvo. Si se mezclan todas bajo la etiqueta «variación de demanda», el futuro sistema heredará una explicación que todavía no se ha comprobado.

«Recalcular el horario» parece una funcionalidad precisa. Le faltan, sin embargo, decisiones que el código no puede resolver por sí solo.

¿Puede modificar un turno que la persona ya había aceptado? ¿Debe conservar una cantidad mínima de horas? ¿Qué tareas requieren experiencia específica? ¿Cómo se considera una preferencia de disponibilidad? ¿Quién resuelve una excepción cuando cumplir una regla impide satisfacer otra?

Las respuestas cambian la solución. También reparten consecuencias entre la empresa y quienes trabajan en ella. Dejarlas implícitas no las elimina: alguien terminará decidiendo mediante una configuración, una fórmula o una corrección manual.

La contribución técnica puede comenzar haciendo visibles esas decisiones. Por ejemplo, una versión del horario podría conservar su motivo de cambio y permitir comparar lo publicado con lo efectivamente trabajado. Esa capacidad sería útil si ayuda a explicar una desviación y elegir una respuesta; producir otro informe que nadie utiliza no completa ese trabajo.

La tecnología adecuada depende de lo que falte. Una configuración existente puede bastar. Otra situación puede requerir integrar registros que ya existen. Un desarrollo propio necesita una razón adicional: una restricción importante que las opciones disponibles no resuelvan de forma suficiente.

La siguiente tabla es una propuesta para conversar sobre el ejemplo. No es el protocolo del estudio de Gap ni una metodología validada de Vertex Dynamics.

La muestra debe ser proporcionada a la decisión. Para comprobar si falta un motivo de cambio no hace falta construir una plataforma de datos. Para decidir una inversión relevante tampoco alcanza con una anécdota conveniente.

Habría que conversar con quienes preparan el plan y con quienes lo ejecutan. Un registro puede mostrar cuándo se modificó un turno; la persona afectada puede explicar por qué una alternativa aparentemente equivalente era inviable. Ambas evidencias responden preguntas distintas.

Supongamos que una mejora reduce el tiempo dedicado a confeccionar horarios. Ese ahorro puede ser valioso aunque no aumenten las ventas. Conviene identificar quién recupera ese tiempo y qué deja de hacer: llamadas, correcciones, comprobaciones o preparación del calendario.

Si además se quiere afirmar una mejora comercial, hace falta otra evaluación. Comparar dos semanas con promociones, tráfico o disponibilidad diferentes no basta para atribuir la diferencia al nuevo sistema. Una comparación razonable debe explicitar qué más cambió y qué incertidumbre permanece.

También pueden aparecer resultados contradictorios. La preparación se vuelve más rápida, pero aumentan las modificaciones posteriores. Mejora la cobertura de una franja, pero otra queda expuesta. Se reduce la intervención del gerente mientras los empleados dedican más tiempo a conseguir sustitutos. Esas posibilidades son preguntas para medir, no efectos que debamos asumir de antemano.

No conviene trasladar el porcentaje de Gap a un presupuesto propio. El estudio aporta evidencia de que una intervención organizativa y tecnológica puede mejorar resultados en un contexto definido. Una empresa diferente tendrá que establecer su problema, sus restricciones y una forma de comprobar el efecto de lo que cambie.

Un equipo de ingeniería que entra en esta conversación necesita escuchar a Operaciones y a las personas afectadas. Su capacidad para modelar reglas, estados y excepciones puede ayudar a convertir un problema ambiguo en decisiones implementables. Eso no demuestra que ingeniería deba dirigir la política de turnos ni que este trabajo siempre tenga más valor que otra prioridad del producto.

Sí ofrece una pregunta más exigente para decidir qué construir: ¿qué parte del funcionamiento de la tienda debería mejorar cuando esta funcionalidad esté en uso?

Una respuesta defendible podría ser reducir cambios evitables, hacer posible una cobertura que hoy no se consigue o liberar tiempo de coordinación sin trasladárselo a otro grupo. El mecanismo y su comprobación tendrían que quedar claros antes de prometer el resultado.

La próxima vez que llegue la solicitud de «automatizar los horarios», puede ser útil abrir la última modificación real. Revisar qué la originó, qué tuvo que hacer cada persona y qué regla permitiría resolverla mejor. Ese recorrido puede cambiar bastante lo que termine escrito en el primer ticket.