Cuando el centro de distribución citó a la plantilla, las decisiones principales ya estaban tomadas. El contrato con el proveedor incluía el sistema de asignación, los indicadores de velocidad aparecían en una presentación y la fecha de activación estaba impresa en los calendarios. La invitación pedía “comentarios constructivos”. Aina, que conocía las rutas de frío y las zonas donde se cruzaban carretillas, levantó la mano para preguntar qué ocurría cuando una ruta rápida obligaba a repetir un trayecto por seguridad. La respuesta fue que el modelo ya había sido probado. Podía enviar una sugerencia para una futura versión.
Esa escena no es participación; es una consulta tardía sobre una decisión cerrada. Pide a quienes hacen el trabajo que aporten su experiencia cuando ya no hay presupuesto, calendario ni autoridad para cambiar el diseño. Después, si señalan un problema, la organización puede llamarlo resistencia al cambio. El resultado es injusto y además caro: la experiencia que habría evitado una mala regla vuelve como accidente, retraso, rotación o arreglo urgente.
La conversación que falta debe ocurrir antes de contratar, antes de fijar indicadores y antes de prometer una fecha. No consiste en votar cada detalle técnico ni en entregar a un grupo de trabajadores la responsabilidad de comprar software. Consiste en reconocer que un sistema reorganiza tareas, riesgos y posibilidades de decisión, y que quien conoce esa jornada tiene evidencia que ninguna demostración comercial contiene. Participar significa poder influir en la pregunta inicial, comparar alternativas y aceptar que “no adoptar” puede ser una respuesta responsable.
Abrir la pregunta antes de comprar la respuesta#
Un proceso de co-diseño empieza con el problema, no con la herramienta. El centro puede describir que hay retrasos en la preparación, accidentes en un cruce o dificultades para distribuir pedidos urgentes. Después debe preguntar qué evidencia sostiene ese diagnóstico y qué consecuencias no puede aceptar. Quizá el cuello de botella no sea la asignación, sino el etiquetado irregular, una zona de carga insuficiente o una política que cambia prioridades cada hora. Comprar un algoritmo antes de entender el atasco convierte una hipótesis del proveedor en una necesidad de la empresa.
Un proceso de co-diseño empieza con el problema, no con la herramienta. El centro puede describir que hay retrasos en la preparación, accidentes en un cruce o dificultades para distribuir pedidos urgentes.
La fase previa necesita personas de cada tarea afectada, representación laboral, prevención, mantenimiento, planificación y quien responderá por el presupuesto. También necesita tiempo reconocido. No puede convocarse al final de un turno ni depender de voluntariado. Quien participa debe recibir información entendible sobre datos, objetivos, cambios previsibles y límites del contrato. La experiencia de una persona no es una anécdota que haya que traducir a un informe técnico; es conocimiento sobre excepciones, peligros y reparaciones que el diseño debe considerar.
Una buena conversación separa lo que se sabe de lo que se supone. El equipo puede recorrer una jornada real, marcar dónde se decide una prioridad, qué información falta, qué actividad no aparece en los registros y qué alternativa manual existe. Puede preguntar quién pagará con tiempo si la recomendación falla y quién puede detenerla. Estas preguntas hacen visible si la propuesta libera trabajo o simplemente desplaza coordinación y riesgo hacia quienes tienen menos poder de modificarla.
Comparar alternativas de verdad#
Co-diseñar no termina en una lista de necesidades. Debe producir alternativas comparables. Una puede ser un piloto de asignación limitado a una zona; otra, mejorar el sistema de etiquetas; otra, añadir un turno de coordinación; otra, no automatizar mientras se corrigen datos básicos. Cada alternativa necesita coste, impacto previsto, datos requeridos, condiciones de seguridad, efecto sobre puestos y forma de retirada. La comparación evita que el contrato parezca inevitable solo porque llegó primero a la mesa.
El presupuesto es una prueba de sinceridad. Si todo el dinero está comprometido con licencias, no queda margen para cambiar una interfaz, añadir equipos, cubrir formación o prolongar un piloto. La organización debe reservar fondos para adaptaciones solicitadas durante el co-diseño y para una alternativa si la herramienta no funciona. No es un colchón decorativo. Es la capacidad material de convertir una observación en cambio, en vez de responder que el contrato no lo permite.
Las alternativas deben incluir costes que suelen quedar fuera de la compra: tiempo para aprender, revisión de incidencias, mantenimiento de una vía manual, carga emocional de resolver conflictos y posibles pérdidas de ingresos durante la transición. Si el sistema promete ahorrar diez minutos pero exige que dos personas reparen excepciones cada tarde, la comparación inicial era incompleta. Hacer visibles esas horas protege tanto a la plantilla como a la decisión de inversión.
Probar sin convertir el piloto en destino#
Un piloto es útil cuando se puede detener y cuando responde a preguntas acordadas antes de empezar. El centro puede elegir una zona, una duración limitada y casos que no pongan en riesgo la seguridad. Debe fijar qué señales harán continuar, qué señales exigirán cambiar y qué señales obligarán a parar. No basta con observar si aumenta la velocidad. Hay que revisar errores de ruta, casi accidentes, esfuerzo físico, distribución de carga, posibilidad de impugnar y tareas invisibles que aparezcan después.
El personal debe poder registrar una incidencia sin perder tiempo de producción ni exponerse a represalias. Si una asignación propone cruzar una zona saturada, Aina necesita una forma de rechazarla, explicar el motivo en pocas palabras y recibir una respuesta. Esos avisos no son ruido que el piloto deba filtrar; son la evidencia para evaluar si el sistema entiende el entorno. Un equipo que no informa porque teme quedar marcado ofrece datos falsamente tranquilizadores.
La prueba necesita una referencia. Antes de activar nada, se documentan tiempos, accidentes, cambios de turno, errores, reclamaciones y rutas que requieren coordinación. Después se compara por tipo de tarea y momento, no solo por una media global. También se entrevista a quienes ejecutan, supervisan y reciben el resultado. Los números detectan un patrón; las conversaciones muestran por qué una recomendación que parece eficiente puede ser impracticable en un pasillo estrecho o durante una descarga imprevista.
Decidir y dejar constancia#
Al final de la fase, la organización tiene tres decisiones reales: adoptar, modificar o no adoptar. Adoptar requiere explicar qué evidencia muestra una mejora y qué límites siguen vigentes. Modificar requiere nombrar cambios, presupuesto, responsables y nueva prueba. No adoptar requiere reconocer que el problema puede necesitar otra respuesta. Ninguna de estas opciones es un fracaso si está razonada. El fracaso sería mantener una herramienta dañina para defender una promesa hecha antes de conocer el trabajo.
La decisión debe quedar documentada en un formato breve y público para la plantilla: objetivo inicial, personas participantes, alternativas comparadas, resultados del piloto, incidencias relevantes, recursos aprobados, responsable y fecha de revisión. No debe revelar relatos personales ni secretos comerciales innecesarios. Debe permitir que alguien comprenda por qué se eligió un camino y cómo cuestionarlo. La transparencia evita que una consulta se convierta después en un recuerdo manipulable de que “todo el mundo estuvo de acuerdo”.
Incluso tras adoptar, el co-diseño continúa. Cambian pedidos, personal, espacios y datos; una regla adecuada en junio puede causar daño en diciembre. Debe existir un comité con facultad de pausar una función, revisar indicadores y ordenar una modificación. La representación de las tareas no puede desaparecer cuando termina el piloto. La participación solo es creíble si conserva una puerta de vuelta cuando la realidad contradice la previsión.
La conversación que falta no empieza con una demostración ni termina con una encuesta. Empieza cuando el problema todavía admite varias respuestas y termina con una decisión que puede cambiarse. Aina no necesitaba que la empresa aceptara toda propuesta; necesitaba que su conocimiento sobre rutas y seguridad tuviera lugar antes de fijar contrato, indicadores y fecha. Una automatización digna no usa la experiencia para legitimar lo ya decidido. La usa para decidir mejor, reservar recursos para corregir y conservar la libertad de no adoptar aquello que no mejora el trabajo.
