Cuando el proceso vive solo en la cabeza de una persona y esa persona se va, no solo se va su tiempo. Se va el criterio para resolver excepciones, el orden de pasos que nadie escribió, y el motivo detrás de cada fórmula. Reconstruir eso desde cero cuesta más que haberlo documentado antes.
Lo primero que se nota es que el archivo sigue ahí, pero nadie más sabe usarlo del todo. Las celdas siguen calculando, pero nadie sabe por qué una fórmula tiene esa forma específica, o qué pasa si un dato entra distinto a lo habitual.
Lo segundo que se nota, más tarde y con más costo, es que el proceso empieza a fallar en los casos que no son el caso normal. Cualquiera puede seguir un flujo simple. Muy pocos pueden reconstruir, sin ayuda, qué hacer cuando el flujo se sale de lo esperado. Esa capacidad de resolver la excepción es lo que se va con la persona, no el archivo.
No es negligencia, es tiempo. Documentar un proceso completo toma horas. El día a día casi nunca da esas horas, porque siempre hay una tarea más urgente que escribir cómo se hace algo que, hasta ese momento, siempre ha funcionado.
El problema es que el costo de no documentar no se nota de inmediato. Se acumula en silencio mientras la persona sigue ahí, y aparece de golpe el día que deja de estarlo. Para entonces, ya es tarde para pedirle que escriba lo que sabe.
Hay una razón adicional, más incómoda de admitir. Muchas veces documentar el proceso significa exponer que ese proceso tiene atajos, excepciones improvisadas y decisiones que nunca se formalizaron. Nadie quiere ser quien pone eso por escrito, así que el conocimiento sigue viviendo donde siempre vivió: en la memoria de una sola persona.
La documentación de un proceso suele capturar el flujo normal, no las excepciones. Un manual describe los diez pasos que se siguen siempre. Rara vez describe qué hacer cuando el cliente pide algo fuera de catálogo, o cuando el sistema devuelve un error que no debería. Tampoco cubre qué hacer cuando dos reglas del negocio entran en conflicto. Y son justo esas excepciones las que exigen el criterio que solo tiene quien ha operado el proceso por años.
El primer paso no es documentar todo de una vez. Es identificar qué procesos dependen de una sola persona hoy, y priorizar los que tendrían mayor impacto si esa persona faltara mañana. No los procesos más fáciles de documentar, los que más dolerían si fallan.
Una vez identificados, la pregunta correcta no es "¿cómo escribo esto en un documento?", es "¿cómo hago que las reglas y las excepciones queden explícitas dentro del sistema que ya se usa a diario?". Un documento se puede no leer. Una regla dentro del sistema se aplica sola, aunque nadie la recuerde.
Es fácil pensar que esto solo pasa en empresas grandes, con procesos muy especializados y personal muy senior. Es al revés. La mediana de empleados entre las empresas que implementan HubSpot con Progresus es de 42, y en ese tamaño una sola persona suele concentrar procesos completos que en una empresa grande estarían repartidos entre varios roles.
La mediana de empleados entre las empresas que implementan HubSpot con Progresus es de 42, y en ese tamaño una sola persona suele concentrar procesos completos
En una empresa pequeña, quien factura también resuelve las excepciones de facturación. Quien coordina la operación también es quien sabe qué proveedor llamar cuando algo falla. La concentración no es un descuido, es consecuencia directa del tamaño. Y eso hace que el riesgo de depender de una sola persona sea, si acaso, más agudo mientras más pequeña es la empresa, no menos.
Esto tiene una implicación práctica para quien lee esto y piensa que su empresa es "muy pequeña para tener este problema": es justo al revés. Cuanto menos personas hay, menos redundancia hay también, y cada rol concentra más conocimiento que nadie más tiene a la mano.
Reconstruir un proceso sin documentación no es copiar los pasos visibles, es descubrir por prueba y error las excepciones que la persona anterior resolvía de memoria. Ese descubrimiento suele costar semanas, y en ese tiempo el proceso funciona peor de lo que funcionaba antes, con más errores y más quejas.
Reconstruir un proceso sin documentación no es copiar los pasos visibles, es descubrir por prueba y error las excepciones que la persona anterior resolvía de memoria.
Un sistema reduce el riesgo de verdad cuando obliga a que las reglas y las excepciones queden explícitas, no cuando solo automatiza lo que ya era visible. Pasar de una hoja de cálculo a otra hoja de cálculo, o a una herramienta genérica que tampoco pide declarar las excepciones, no cierra la dependencia. Solo la mueve de lugar.
La pregunta que conviene hacerse antes de que la persona clave se vaya es sencilla: si mañana faltara, ¿alguien más podría resolver el caso raro que solo ella sabe resolver? Si la respuesta es no, ahí está el punto exacto donde empezar. No hace falta resolver todos los procesos de la empresa a la vez, basta con empezar por el que más dolería perder.
Se pierde el criterio para resolver excepciones, el orden real de los pasos y el motivo detrás de cada fórmula o atajo, que casi nunca queda escrito en ningún lado.
Si quieres revisar cómo hacer ese cambio en la práctica, puedes leer opciones para dejar de depender de una persona. Para ordenar esa decisión, revisa cómo elegir una ruta para que el proceso no dependa de una sola persona. También puedes revisar qué pasa cuando el empleado que conoce el proceso se va, dentro de la guía completa que Progresus Apps armó sobre cómo dejar de operar a ciegas cuando el proceso vive en excel, papel o whatsapp.