Hace dos semanas, un cliente me llamó con una noticia que sonaba casi rutinaria: Marta —no es su nombre real— había presentado su renuncia. Ella había manejado devoluciones y reclamos a proveedores durante seis años, y se iba en tres semanas. Al principio nadie entró en pánico. Después alguien intentó encontrar dónde vivía realmente "el proceso", para poder entregárselo a quien viniera después, y resultó que no había ningún "dónde". Había tres hilos de correos, la mitad de un cuaderno espiralado y un papelito con el teléfono directo de un proveedor al que nadie más había llamado jamás.
Nadie había hecho nada mal. El proceso de devoluciones había funcionado, todas las semanas, durante seis años. Funcionaba porque Marta lo llevaba en la cabeza, y solo Marta.
Esto es lo que se conoce como conocimiento tribal, y es mucho más común de lo que la mayoría de los dueños de negocio está dispuesto a admitir.
El proceso nunca se escribió, porque nunca tuvo que escribirse
En un negocio que funciona con cuadernos, correos y grupos de WhatsApp, no existe un momento en el que alguien decide "dejemos esto sin documentar". Simplemente pasa, en silencio, durante años. Alguien toma una tarea porque está disponible o porque es bueno en eso. Resuelve algunas excepciones que nadie más vio. Toma pequeñas decisiones —a qué proveedor llamar primero, qué cliente siempre necesita un recordatorio, qué excepción se puede pasar por alto— y esas decisiones nunca quedan registradas en ningún lado, porque anotarlas nunca fue parte del trabajo de nadie.
Seis años después, esa persona no solo hace una tarea. Es la única documentación que esa tarea tiene.
No es negligencia. Es estructura
Quiero ser claro con esto, porque es tentador leer una historia como la de Marta y pensar que la empresa fue descuidada. No lo fue. Casi nunca hay una partida de presupuesto para "anotar cómo hacemos las cosas", y casi nunca hay una semana tranquila en la que alguien dice "paremos y documentemos esto". El trabajo que paga las cuentas siempre le gana al trabajo que solo rinde si alguien renuncia. Entonces el conocimiento sigue viviendo en una sola cabeza, porque ese es el camino de menor resistencia, semana tras semana, hasta la semana en que deja de serlo.
El costo real aparece en el peor momento posible
La parte cara de perder conocimiento tribal casi nunca es el conocimiento en sí. Es el momento en que se pierde.
Nadie pierde a un empleado clave en un mes tranquilo. El problema aparece con una devolución que hay que procesar hoy, un reclamo a un proveedor con una fecha límite, o un cliente enojado que no puede esperar a que "alguien lo resuelva". La empresa no tiene el lujo de reconstruir el proceso con calma. Tiene que hacer ingeniería inversa en vivo, bajo presión, y generalmente mientras también capacita a quien va a ocupar el puesto.
He visto esto convertirse en semanas de adivinar: buscar en viejos hilos de correo para tener contexto, llamar a proveedores para preguntar "¿cómo es que funciona esto de su lado?", y rehacer trabajo porque el primer intento de reconstruir "el proceso" resultó estar equivocado. Nada de eso aparece como una línea en ningún reporte. Aparece como semanas lentas, clientes molestos y un empleado nuevo que parece más lento de lo que realmente es, porque está reconstruyendo un proceso a partir de fragmentos, en lugar de aprender uno que alguna vez estuvo escrito.
Lo que realmente soluciona esto no es un sistema enorme
Esta es la parte que sorprende a la gente: la solución al conocimiento tribal casi nunca requiere "un ERP" ni la implementación de una plataforma gigante. Lo que requiere es mucho más pequeño y mucho más específico: registros de lo que realmente pasó (qué proveedor, qué decisión, qué excepción, y por qué), una forma de buscar ese historial en segundos en lugar de adivinar, y un proceso definido que viva fuera de la memoria de una sola persona.
Eso es todo. No un sistema que haga de todo. Un sistema que contenga lo que hoy una sola persona sostiene sola.
Construí algo así para un cliente que maneja una galería de arte —registrando inventario, ventas y los detalles de consignación de obras con artistas que antes vivían repartidos entre la memoria de un par de personas y una pila de papeles. El objetivo no era digitalizar todo lo que hace el negocio. Era asegurarse de que si cualquier persona de ese equipo se iba al día siguiente, la próxima persona pudiera abrir el sistema y ver realmente qué pasó con una obra determinada: quién la consignó, qué se acordó, qué se vendió, qué se debe. El conocimiento dejó de pertenecerle a una persona y empezó a pertenecerle al negocio.
Esta es la misma idea detrás de un sistema de back-office bien hecho: no intenta reemplazar cómo piensa su equipo. Empieza con el proceso donde el conocimiento corre más riesgo —la única persona, el único cuaderno, el único hilo de correo que nadie más puede leer— y le da a ese proceso un registro, una búsqueda y una forma definida de hacer las cosas que sobrevive a una carta de renuncia.
Capturá el conocimiento antes de que alguien renuncie, no después
El consejo honesto acá no es "construyas un sistema para todo lo que hace su negocio". Es más puntual: encontrá el proceso de su negocio que hoy vive en la cabeza de una sola persona, y dale un hogar antes de que el preaviso de esa persona te obligue a resolverlo de urgencia.
Probablemente ya sabés cuál es ese proceso. Es aquel en el que, siendo honesto, solo un nombre te viene a la cabeza cuando alguien pregunta "¿quién maneja esto?". Ese es el que vale la pena empezar a resolver —no porque todos los procesos necesiten esto, sino porque ese en particular está a una carta de renuncia de distancia de convertirse en una crisis en lugar de una simple transición.
El último día de Marta llegó y pasó. La empresa lo superó, pero le costó tres semanas del preaviso dedicadas a documentar frenéticamente cosas que debieron haber tenido un registro años antes, y un primer mes complicado para quien vino después. No tenía por qué ser tan caro. Casi nunca tiene que serlo.