El día que te pidieron la evidencia

2015. Todavía éramos una startup pequeña, pero ya habíamos llegado al punto donde "cada quien hace las cosas a su manera" dejó de ser una virtud ágil y se convirtió en un riesgo. Necesitábamos definir procesos. Necesitábamos que lo que hacíamos fuera repetible, sin importar quién estuviera detrás del teclado ese día.

Tuvimos la fortuna de tener un auditor líder con un conocimiento de procesos muy alto, que nos acompañó cuestionando, todo el tiempo, si lo que estábamos definiendo realmente tenía sentido. Y ahí me topé, de frente, con una resistencia muy típica del espíritu emprendedor SaaS en Latinoamérica: la idea de que definir procesos es, automáticamente, volverse burocrático y lento.

Un marco de procesos no te dice cómo hacer esa definición. Cada dueño de proceso arma su propio traje a la medida con las piezas de Lego que tiene disponibles. Y ahí vi de todo: procesos descritos punto y coma, con un detalle tan alto que no dejaba ningún espacio para las excepciones naturales de la operación diaria. Y en el otro extremo, procesos completamente planos, que solo describían el happy path, como si nada pudiera salir distinto a lo esperado.

Y entonces llega el momento que de verdad da terror: tu primera verificación. El proceso que tú mismo definiste, junto con tu líder, ahora te pide mostrar evidencia de que en efecto se está siguiendo. Y ahí, sin que nadie te lo diga explícitamente, te pones nervioso. Le das a esa solicitud un enfoque completamente equivocado: sientes que estás en peligro, que tu trabajo está en riesgo.

Cuando en realidad, una auditoría no se trata sobre las personas. Se trata sobre los procesos, y sobre las actividades que las personas realizan dentro de ellos.

Para que un operador de proceso realmente lo adopte, es clave que haya participado en su definición. Un proceso impuesto desde arriba, sin esa participación, nunca genera el mismo nivel de apropiación. Y con el tiempo, con nuevas herramientas, con nuevos alcances del rol, la definición versión uno de cualquier proceso deja de ser 100% funcional. Para que el proceso —y el sistema completo— adquiera madurez, se requiere que las personas se apropien de él, y que las salidas no conformes, en lugar de ocultarse o castigarse, se conviertan en insumo para que el sistema madure.

La experiencia ganada, con el tiempo, mostró algo todavía más incómodo: uno de los dolores más grandes de la operación era ganar eficiencia real al implementar sistemas y entregar tareas a tiempo y con calidad. El resultado técnico —salir a producción— se alcanzaba. Pero con desviaciones altas, y en algunos casos, con calidad baja. Lo que diferenciaba a un proyecto que arrancaba estable de uno que no lo era tanto no era solamente el seniority del manager a cargo, sino el manejo correcto de alcances, riesgos y desviaciones, y entender de verdad el valor que esa implementación le agregaba al cliente.

Un sistema de gestión de calidad no existe para asustar a nadie el día de la auditoría. Existe para que el conocimiento de cómo se hacen bien las cosas deje de vivir únicamente en la cabeza de quien las hace, y se vuelva algo que la organización completa puede repetir, mejorar y, cuando algo sale mal, corregir sin necesidad de señalar a una persona. El miedo a mostrar evidencia es, casi siempre, la señal más clara de que ese mensaje todavía no ha llegado a todo el equipo.

¿Tu equipo le teme a las auditorías, o las usa para madurar? Si no estás seguro de la respuesta, esa duda ya te está diciendo algo sobre el nivel de madurez real de tu sistema de gestión.