Cuando un error se repite, conviene separar la reparación inmediata de la revisión de sus causas. Reconstruí un episodio concreto con quienes participaron, observá qué información y condiciones tuvieron y probá un cambio acotado. Después verificá si disminuye la falla sin crear otro problema. Pedir más atención puede ser necesario, pero deja pendiente lo que el proceso necesita cambiar.
- Resolver el episodio no explica qué lo hizo posible.
- Reconstruir el recorrido aporta más que señalar al último que intervino.
- Un cambio necesita evidencia, no solamente una nueva instrucción.
- La revisión también debe mirar la carga y los riesgos que agrega el control.
Imaginá esta escena: salió un pedido con una especificación vieja. El cliente reclama, alguien busca la versión correcta y el equipo reorganiza el trabajo para corregirlo. Se pide más atención. Todos están de acuerdo. Un tiempo después, ocurre algo parecido con otro pedido.
La escena es ilustrativa, pero la pregunta merece un lugar en cualquier empresa: ¿estamos frente a un descuido aislado o frente a una forma de trabajar que deja el mismo error abierto?
La diferencia importa. Un llamado de atención puede ser necesario. No alcanza para actualizar un archivo que nadie sabe dónde encontrar, aclarar una instrucción contradictoria o cambiar un control que llega cuando el producto ya salió.
Antes de pedir más cuidado, conviene mirar qué información recibió la persona, qué podía verificar y qué pasaba alrededor de esa tarea.
Arreglar lo que salió mal no es cerrar el problema
Cuando hay un cliente esperando, lo primero es contener la situación. Frenar un envío, corregir una entrega, informar un desvío o proteger a las personas puede ser urgente. No hace falta terminar una investigación para actuar sobre un riesgo evidente.
Pero esa respuesta tiene otro propósito: reducir el daño de este episodio. Todavía no explica por qué ocurrió ni qué habría que cambiar para que no se repita.
La American Society for Quality distingue el análisis de causas de la mera atención de síntomas. Su enfoque propone identificar qué origina un problema para orientar acciones correctivas, no quedarse únicamente con su manifestación. No implica que siempre exista una sola causa ni que una herramienta permita encontrarla automáticamente. ASQ: análisis de causas.
En una PyME, una forma práctica de separar ambas conversaciones es preguntar: ¿qué hicimos para resolver lo de hoy y qué falta averiguar sobre lo que lo hizo posible?
Si ambas respuestas quedan mezcladas, el esfuerzo de reparación puede dar una sensación de cierre prematura. El cliente recibió el reemplazo. La falla en el traspaso de información sigue ahí.
Reconstruir el recorrido, no buscar al último que tocó el trabajo
Volvamos al ejemplo. Quien preparó el pedido utilizó una ficha. ¿De dónde salió? ¿Había otra versión? ¿Quién conocía el cambio? ¿La actualización llegó antes de que empezara el trabajo o mientras ya estaba en marcha?
No son preguntas para exculpar a nadie. Son preguntas para distinguir qué corresponde a una conducta individual y qué depende del proceso.
Podés reconstruir un episodio concreto con la gente que participó, mirando documentos y momentos, no recuerdos generales. Qué se pidió, qué se entendió, qué se ejecutó y dónde apareció la primera diferencia. Si hay varias versiones, conservarlas ayuda más que reemplazarlas de inmediato y perder el rastro.
También conviene escuchar a quien recibe el trabajo siguiente. A veces el problema se vuelve visible en administración o en atención al cliente, aunque haya empezado mucho antes.
Una advertencia: preguntar por qué varias veces no convierte una suposición en evidencia. Si la explicación es que alguien estaba apurado, todavía falta saber qué permite sostenerlo. Y aunque lo estuviera, sigue pendiente entender por qué ese apuro terminó en una falla que nadie detectó.
Buscar la condición que se puede modificar
Pedir compromiso es amplio. Definir qué versión se usa para trabajar es concreto. Pedir orden es amplio. Acordar quién confirma un cambio y dónde queda registrado permite probar otra manera de hacer las cosas.
Algunas condiciones para revisar son la disponibilidad de información, las interrupciones, la secuencia de tareas, las capacidades necesarias y los criterios de aceptación. No hay que suponer que todas fallan. Se trata de encontrar cuáles intervinieron en ese problema particular.
En el ejemplo del pedido, una hipótesis sería que conviven dos archivos válidos para personas distintas. Otra, que el cambio llega por un mensaje privado a alguien que no tiene cómo modificar la orden. La respuesta a cada situación es diferente.
El control tampoco debería agregarse por reflejo. Si toda falla termina en una firma adicional del dueño, podrías estar cambiando un error por una espera. Antes de sumar una revisión, preguntá dónde conviene hacerla, qué detectaría y quién puede actuar cuando encuentre una diferencia.
En actividades con consecuencias para la seguridad, la salud o el cumplimiento legal, esta revisión general no reemplaza los procedimientos obligatorios ni a los especialistas. Allí no corresponde improvisar controles ni retirar los existentes por considerarlos incómodos.
Probar un cambio que se pueda observar
No hace falta rediseñar toda la empresa para empezar. Se puede elegir un tipo de trabajo y probar una modificación acotada, con un responsable y una fecha de revisión.
Por ejemplo, en una situación ilustrativa de servicios, el equipo podría acordar que todo cambio de alcance quede confirmado en la orden vigente antes de asignar la tarea siguiente. La iniciativa es modificar esa confirmación. La evidencia será lo que ocurra con los trabajos que pasan por ella.
Conviene mirar cuántos necesitaron rehacerse por una instrucción desactualizada y sobre cuántos trabajos se está contando. También cuánto tiempo agrega el nuevo paso y si genera otra demora. Contar únicamente errores puede engañar si el volumen de trabajo cambió mucho entre una semana y otra.
Si el problema justifica una prioridad compartida durante un ciclo, los OKRs pueden ayudar a expresar el cambio buscado y qué señales mostrarían progreso. El objetivo podría ser volver confiable el traspaso de pedidos a operación. Los resultados clave tendrían que apoyarse en una base conocida y una mejora acordada, no en un porcentaje atractivo elegido sin datos.
Hacer una capacitación o crear una plantilla serían acciones posibles. No son, por sí solas, prueba de que el traspaso mejoró.
En el pedido con una especificación vieja, el cambio que importa aparece cuando la versión correcta llega al trabajo y evita una repetición.
Un OKR para volver confiable el traspaso de especificaciones
Ejemplo ilustrativo para un ciclo de hasta 90 días: ajustá cifras y condiciones a la línea de base de tu empresa.
Objetivo: Volver confiable el traspaso de especificaciones a la operación.
Resultado clave 1: Reducir de 8 a 2 por cada 100 pedidos los que requieren retrabajo por utilizar una especificación desactualizada, durante el último mes.
Resultado clave 2: Pasar de 6 a 9 de cada 10 cambios de especificación recibidos a tiempo que se ejecutan correctamente en el pedido afectado.
Iniciativa posible: Probar una única referencia vigente y una confirmación del cambio antes de asignar la tarea.
Evidencia y revisión: Conservá el historial de versiones y contá también fallas detectadas antes del envío. Revisá el tiempo de traspaso: una mejora que agrega esperas importantes necesita ajuste.
Cerrar también lo que aprendimos
La revisión no debería preguntar solamente si hubo otro reclamo. Puede haber errores que el equipo corrigió a tiempo y que nunca llegaron al cliente. Si ocultarlos ayuda a mostrar un indicador más lindo, el aprendizaje pierde información.
Una conversación útil admite tres respuestas: el cambio funcionó, no funcionó o todavía no tenemos evidencia suficiente. La tercera no es un fracaso. Es una razón para seguir observando sin vender certeza antes de tiempo.
También vale revisar si la explicación inicial era incompleta. Quizás se ordenó el archivo, pero siguen llegando modificaciones sin confirmación. Entonces no corresponde insistir con la misma solución por haber invertido tiempo en ella.
Cuando un cambio resulta útil, dejalo disponible para quien hace el trabajo y para quien se incorpora después. No en un documento que nadie abre: en el lugar donde se consulta la instrucción real.
El próximo error repetido puede ser una oportunidad para cambiar la conversación. Además de preguntar quién se hace cargo de corregirlo, preguntá qué necesitamos entender para no volver a depender de la misma reparación.
Preguntas frecuentes
¿Qué hago primero cuando se repite un error?
Contené el daño o riesgo inmediato y después reconstruí lo ocurrido. Son conversaciones relacionadas, pero conviene distinguir la solución del episodio de la revisión de sus causas.
¿Analizar el proceso significa dejar de pedir responsabilidad?
No. Permite distinguir conductas individuales, información disponible y condiciones del trabajo. Con esa claridad se puede pedir un cambio concreto y ofrecer el apoyo que corresponda.
¿Cómo sé si el cambio funcionó?
Compará lo ocurrido antes y después con una medida adecuada al volumen y tipo de trabajo. Observá también demoras o carga adicional; una instrucción nueva no demuestra una mejora.
