procesos · operaciones
Por qué se saltan los procesos documentados (y no es por pereza)
Los equipos documentan el proceso y aun así se saltan el paso. Las razones son estructurales: distancia, momento, documentos obsoletos y cumplimiento invisible. Cómo se ve cada una en un ticket real y qué la soluciona.
Todo responsable de operaciones ha tenido esta conversación. A un cliente le dijeron algo incorrecto, una escalada rebotó desde ingeniería, una versión salió sin la aprobación. Alguien abre la página de Confluence y dice: pero si está aquí.
Está ahí. Y aun así se saltó. Tras unos cientos de estas conversaciones, el patrón es lo bastante claro como para ponerle nombre. La gente no se salta los pasos documentados por descuido. Se los salta por cuatro razones estructurales, y cada una tiene una solución distinta.
1. El documento está lejos del trabajo
El runbook vive en Confluence. El ticket vive en Freshdesk. La incidencia de ingeniería vive en Jira. La decisión que lo cambia todo se tomó el martes en un hilo de Slack. Quien trabaja el ticket necesitaría cinco pestañas y diez minutos para reunir lo que dice el proceso para este elemento.
Nadie tiene diez minutos por ticket. Así que hacen lo que hace la gente: actúan según lo que tienen delante, que es el ticket, y confían en la memoria para el resto. La memoria sirve para el camino habitual y es pésima para la excepción, y la excepción es justo donde el documento se gana su sitio.
Qué lo soluciona: llevar el proceso al trabajo. No un enlace: el paso. "Siguiente: dile al cliente que este es el comportamiento esperado y ejecuta Recalculate." El documento sigue siendo la fuente de verdad; simplemente se lee por la persona, para este ticket, con el contexto conectado.
2. El paso depende de un dato que nadie comprobó
La mayoría de los procesos se bifurcan. "Si el LP es crítico a efectos de cumplimiento, abre un P2." "Si el cliente está en la 4.12 o posterior, la corrección ya está en producción." "Si es un usuario, son datos; si son muchos, es configuración." La condición de la bifurcación es un dato sobre el elemento, y a menudo ese dato no está en el ticket.
Aquí está el fallo silencioso: la persona no conoce el dato, no sabe que el proceso depende de él y toma la rama por defecto. Se siguió el documento. Se tomó la rama equivocada. Nadie se entera hasta que se entera el cliente.
Qué lo soluciona: preguntar. La pregunta que el documento necesita que se responda, formulada en el momento en que importa, con las opciones del propio documento: ¿un usuario o muchos? ¿En qué entorno se probó? Un proceso que pregunta antes de suponer se sigue mucho más que uno que supone.
3. El documento era correcto el trimestre pasado
Los procesos se desvían. Ingeniería cambia la ruta de escalado, un nuevo squad se hace cargo de un área, se sustituye una herramienta. El documento se actualiza seis semanas después, si alguien se acuerda. Durante esas seis semanas, las personas con experiencia siguen el proceso real (estaban en la reunión) y las nuevas siguen el escrito. Ambas creen tener razón.
La versión cara de esto es la formación: una cohorte formada en marzo con un documento que cambió en abril, que en mayo lo hace con total seguridad a la manera antigua.
Qué lo soluciona: hacer que las correcciones fluyan de vuelta. Cuando alguien dice "eso está mal, ahora escalamos al squad de Aprender", esa corrección debería (a) aplicarse de inmediato a elementos similares y (b) convertirse en una propuesta de edición del documento, con el responsable decidiendo. Y cuando el documento cambia, las personas formadas con la versión anterior deberían saber qué ha cambiado, en un párrafo, no en un diff.
4. Nadie ve el cumplimiento hasta que es un análisis post mortem
Pregunta a un responsable de equipo qué porcentaje de tickets siguió el proceso de triaje el mes pasado. Nadie lo sabe. El cumplimiento es invisible hasta que algo falla lo bastante grave como para justificar una revisión, y para entonces la pregunta es "quién", no "dónde".
Sin visibilidad no hay feedback: un paso que se salta el 40 % de las veces se ve exactamente igual que uno que nunca se salta. El documento no puede mejorar porque nadie sabe dónde falla.
Qué lo soluciona: señales. Cada corrección, cada pregunta que el documento no supo responder, cada escenario de formación que la gente falla, agrupado por etapa. Una etapa que muchas personas fallan es un problema del documento, no de las personas, y ahora puedes verlo.
El hilo conductor
Ninguno de estos problemas se resuelve escribiendo un documento mejor, organizando una sesión de formación o enviando un recordatorio. Se resuelven acortando la distancia entre el documento y el momento de actuar, y dejando que el momento de actuar corrija el documento. Ese bucle —seguir, corregir, volver a formar— es lo que hemos construido en torno a Ovenbird. Pero incluso sin una herramienta, merece la pena hacerse estas cuatro preguntas sobre cualquier proceso que tu equipo se salte una y otra vez: ¿a qué distancia está el documento del trabajo? ¿De qué dato depende el paso? ¿Cuándo fue cierto por última vez? ¿Cómo sabríamos que se saltó?