El error de procesamiento había afectado a seiscientas doce cuentas. El CEO lo sabía al final del primer día. Al final del segundo día el CEO también sabía lo siguiente: que el error se había originado en una actualización rutinaria del sistema de facturación, que la actualización había sido probada según el protocolo acordado, que las pruebas no habían detectado el error porque la combinación específica de tipos de cuenta afectados no estaba incluida en los casos de prueba, y que los casos de prueba habían sido diseñados por el proveedor usando documentación proporcionada durante la fase de transferencia de conocimiento. El CEO le preguntó a Joel sobre los casos de prueba. Joel sacó el framework de pruebas original que la empresa había usado antes de la transición y lo comparó con la versión del proveedor. La diferencia no era dramática. Era el tipo de diferencia que solo es visible para alguien que sabe por qué el framework original fue construido de la manera en que fue construido, es decir, alguien que había estado presente para el incidente específico, dieciocho meses antes de la transición, que había causado que el framework original incluyera la combinación específica de tipos de cuenta que la versión del proveedor no incluía. "Este caso de prueba existe en nuestro framework original por algo que sucedió antes de que llegaras," dijo Joel. "Un error de facturación, más pequeño que este, que afectó a un subconjunto de cuentas con una combinación específica de configuraciones heredadas. El incidente fue resuelto y luego el framework fue actualizado para incluir esa combinación de tipo de cuenta en todas las pruebas futuras del sistema de facturación. La actualización estaba documentada en el propio framework de pruebas. Pero la razón de la actualización, el incidente que la produjo, no estaba documentada. Era memoria institucional." "¿Y el equipo del proveedor?" dijo el CEO. "El equipo del proveedor revisó la documentación durante la fase de transferencia de conocimiento," dijo Joel. "Vieron los casos de prueba. No vieron la razón de este específico. Cuando construyeron su propio framework hicieron un juicio razonable sobre qué casos de prueba incluir basándose en la documentación. Este no llegó a su versión porque sin el contexto parecía un caso límite en lugar de una lección aprendida." "¿Está esto documentado en algún lugar?" dijo el CEO. "En los archivos de Sandra," dijo Joel. "Ella mantenía registros de incidentes desde el principio. Detallados. Fueron incluidos en los materiales de transferencia de conocimiento." "¿Y el equipo de Diane?" dijo el CEO. "Los recibieron," dijo Joel. "Los revisaron. No tenían a Sandra para explicarlos. Y no sabían qué preguntar." "Porque no sabían lo que no sabían," dijo el CEO. "Correcto," dijo Joel.

Esta es la manera específica en que el conocimiento abandona una organización. No a través de la salida dramática. No a través de la carta de renuncia o la fiesta de jubilación o el anuncio de reestructuración. A través de la acumulación silenciosa de contexto no documentado que existe solo en el entendimiento de las personas que estuvieron presentes cuando el contexto fue creado, y que desaparece, de manera incremental e invisible, cada vez que una de esas personas se va sin transmitirlo. Los cuadernos verdes habían sido el intento de Maya de ralentizar este proceso. De hacer visible lo invisible. De crear un registro no solo de lo que era el conocimiento sino de por qué existía y qué lo había producido y qué sucedería si no se aplicara. Maya había entendido, instintivamente, que el conocimiento sin contexto es información, y la información sin contexto es datos, y los datos sin contexto son ruido, y que la diferencia entre una organización que aprende de su experiencia y una organización que sigue repitiendo los mismos errores está determinada casi en su totalidad por cuánto del contexto sobrevive a las transiciones. Los cuadernos verdes habían sobrevivido a la transición. Estaban en un armario en el área de soporte. Habían sido indexados y anotados y hechos tan transferibles como un documento puede ser hecho. Lo que no había sobrevivido era Maya. En el lado del proveedor, Gil había identificado la brecha del caso de prueba tres semanas antes de que ocurriera el error de procesamiento. No la había identificado específicamente como una brecha del caso de prueba. La había identificado como un patrón en las llamadas que recibía su equipo, un subconjunto de tipos de cuenta que estaban produciendo vías de resolución inusuales que el guión no cubría completamente y que sus agentes estaban manejando a través de la improvisación en lugar de a través del proceso definido. Lo había planteado a su manager. Su manager había dicho que era una cuestión para el equipo operacional del cliente. Gil lo escribió en sus propias notas. Escribía cosas en un pequeño cuaderno marrón con páginas cuadriculadas que guardaba en el cajón izquierdo de su escritorio. El actual era el noveno. Escribió: combinación de tipo de cuenta, interacción de configuraciones heredadas, vía de resolución poco clara, riesgo potencial de error. Subrayó riesgo potencial de error y dibujó una pequeña flecha apuntando al margen izquierdo, donde escribió: escalar. Escaló. La escalada fue a Jonathan. Jonathan la reenvió al enlace de cuenta del cliente. El enlace de cuenta la registró como una consulta de proceso. La consulta de proceso quedó en la cola. Tres semanas después ocurrió el error de procesamiento. Gil leyó el informe del incidente y encontró la combinación de tipo de cuenta en el tercer párrafo. Lo había escalado. La escalada había sido procesada correctamente y había quedado en la cola. La cola no había sido revisada antes de que se implementara la actualización. La actualización había producido el error. Había hecho todo lo que la estructura le permitía hacer. La estructura no había sido construida para detectar lo que él había visto.

El CEO llamó a Maya. No para pedirle que volviera. Todavía no. Para hacerle una pregunta. "El error de procesamiento," dijo el CEO. "La actualización del sistema de facturación. Los casos de prueba." "Me enteré," dijo Maya. "Dom me envió un mensaje." "Joel ha identificado la brecha. El framework del proveedor tenía un caso de prueba que faltaba que existía en el nuestro debido a un incidente de hace dieciocho meses. El incidente estaba en los archivos de Sandra. El contexto no." "Sé a qué incidente te refieres," dijo Maya. "Lo pensé," dijo el CEO. "Era antes de mi tiempo aquí pero Sandra me habló de él cuando estaba construyendo la base de conocimiento," dijo Maya. "Añadí una entrada. Pensé que había dejado el contexto claro pero es posible que lo hiciera claro para alguien que ya conocía la historia y no claro para alguien que lo leía sin ese antecedente." "¿Puedes mirar la entrada y decirme lo que piensas?" dijo el CEO. "Sí. Dame un día," dijo Maya. Llamó de vuelta a la mañana siguiente. "La entrada describe el incidente y la lección," dijo Maya. "No describe por qué la lección importa. Alguien que la lea sin contexto entendería qué sucedió y qué se cambió. No necesariamente entendería que el mismo tipo de fallo volvería a ocurrir si el cambio no se mantenía en futuros frameworks de prueba. Lo escribí para alguien que entendía el sistema. No para alguien que aprendía el sistema desde cero." "¿Es ese un problema común con la documentación?" dijo el CEO. Maya estuvo en silencio por un momento. "Sí," dijo Maya. "No porque la documentación sea mala. Porque la documentación siempre es escrita por alguien que ya entiende la cosa que se está documentando, para alguien que imagina que también la entiende. La brecha entre ese lector imaginado y el lector real es donde vive el contexto y donde se pierde." "¿Estarías dispuesta a hacer eso?" dijo el CEO. "¿Te refieres a revisar toda la base de conocimiento en busca de brechas de contexto?" dijo Maya. "Sí," dijo el CEO. "Eso llevaría meses," dijo Maya. "Lo sé," dijo el CEO. "Y el equipo del proveedor tendría que estar involucrado," dijo Maya. "No tiene sentido identificar las brechas si las personas que necesitan llenarlas no son parte del proceso." "¿Puedo preguntar hacia dónde lleva esto?" dijo Maya. "No estoy listo para responder esa pregunta todavía," dijo el CEO. "Pero me gustaría saber que estarías dispuesta a ser parte de lo que lleve a." Maya estuvo en silencio de nuevo. Más tiempo esta vez. "Querría saber más antes de comprometerme a algo," dijo Maya. "Es justo," dijo el CEO. "Pero sí," dijo Maya. "En principio. Si lleva hacia algo que creo que vale la pena." "Gracias Maya," dijo el CEO. "¿Puedo preguntar una cosa más?" dijo Maya. "Sí," dijo el CEO. "¿Estás pensando específicamente en la base de conocimiento o estás pensando en todo?" dijo Maya. "En todo," dijo el CEO. "Bien," dijo Maya. Nora había estado en tratamiento durante tres meses. Seguía viniendo. No todos los días. Tres días a la semana en las semanas en que el tratamiento lo permitía, dos días en las semanas en que no, y una vez, en el segundo mes, no del todo durante una semana completa cuando los efectos secundarios habían producido un cansancio que estaba más allá de lo que la palabra cansancio suele describir. La empresa se había ajustado a su alrededor sin que se lo pidieran. Owen había sido el primero en organizar esto. No como un acuerdo formal. Como una conversación que tuvo con tres personas en reuniones breves separadas durante una mañana de martes. No le había dicho a nadie por encima de él que había hecho esto. No se le había ocurrido reportarlo. Era algo que había que hacer y lo había hecho. El CEO se enteró por Nora. "Owen lo organizó," dijo Nora. "No lo convirtió en un proyecto. Simplemente lo hizo posible." El CEO pensó en esto. Luego fue a ver a Owen. "Me enteré de lo que hiciste por Nora," dijo el CEO. Owen miró hacia arriba. "Es simplemente lo que haces," dijo Owen. El CEO se quedó allí por un momento. "Eso es exactamente lo que dijo Priya," dijo el CEO. "¿Qué?" preguntó Owen. "Nada," dijo el CEO. "Gracias Owen." El CEO pensó: cuántas veces ha hecho este tipo de cosas que nadie por encima de él conoce.

El conocimiento que se fue no estaba solo en la documentación. Esto era lo que el CEO estaba comenzando a entender en las semanas después del error de procesamiento, sentándose con el problema de la manera en que el CEO había aprendido, temprano en una carrera que había incluido muchos problemas que parecían simples y no lo eran, a sentarse con los problemas antes de decidir qué hacer con ellos. La documentación era la parte visible. Los cuadernos verdes. Los registros de incidentes. Los frameworks de prueba. Los artículos de conocimiento del producto. La parte invisible era más difícil. La parte invisible era el conocimiento que nunca había estado en ningún documento. El conocimiento que había vivido completamente en el entendimiento de personas específicas y que había sido aplicado, inconscientemente, en cada decisión que esas personas tomaban sobre cómo manejar una situación que la documentación no cubría. El conocimiento de Priya de cuándo quedarse en una llamada y cuándo un cliente necesitaba algo más allá de lo que el guión podía ofrecer. El conocimiento de Sandra de qué agentes estaban listos para más responsabilidad. El conocimiento de Maya de por qué la base de conocimiento estaba organizada de la manera en que estaba. El conocimiento de Owen de cuándo un equipo necesitaba organizarse antes de que la necesidad fuera visible en cualquier informe. Nada de esto había estado en ningún documento. Todo se había ido, o se estaba yendo, o estaba presente e invisible, que era su propio tipo de pérdida. El CEO pensó en la teoría de Joel sobre dos tipos de distancia. La parte en la documentación que podías ver, identificar y abordar. La parte que había vivido en Priya y Sandra y Maya no podías verla, no podías identificarla completamente y no podías abordarla completamente, no desde donde estaba la empresa ahora. Solo podías reconstruirla. Y reconstruirla requería las condiciones que la habían producido en primer lugar. La sala. La proximidad. La experiencia acumulada de personas que estaban presentes para las cosas que producían el conocimiento y que se quedaban lo suficiente para transmitirlo a las personas que venían después de ellas. El CEO se sentó con esta comprensión durante varios días. No actuando sobre ella. Todavía no. Después de varios días la comprensión era suficientemente clara. El CEO convocó una reunión con Joel. No una reunión formal. Una conversación en la sala de reuniones con la pizarra y las cuatro sillas. "Quiero hablar sobre lo que realmente significaría volver," dijo el CEO. "¿En términos de?" dijo Joel. "En términos de lo que requeriría," dijo el CEO. "La junta. El contrato. El cronograma. Las personas." "Has tomado la decisión," dijo Joel. "La estoy tomando ahora," dijo el CEO. "Mientras hablamos. Quiero entender lo que requiere antes de terminar de tomarla." "Requiere terminar el contrato con el proveedor," dijo Joel. "Habrá penalizaciones. Puedo mirar las cláusulas de salida pero debemos asumir que es costoso." "Lo sé," dijo el CEO. "Requiere reconstruir la función de soporte internamente," dijo Joel. "Eso significa contratar. Formar. Reconstruir la base de conocimiento a un estado en el que pueda apoyar realmente al equipo. Eso lleva tiempo. Probablemente un año para llegar a un estado funcional. Dos años para llegar a donde estábamos antes." "Dos años," dijo el CEO. "Como mínimo," dijo Joel. "Y las personas," dijo el CEO. "Esa es la pregunta más difícil," dijo Joel. "Algunas volverán," dijo Joel. "No todas. Maya podría. Sandra podría. Los otros, los que tomaron la indemnización o las posiciones con el proveedor, algunos habrán seguido adelante de maneras que son reales y no pueden revertirse fácilmente. Y Priya." "Priya," dijo el CEO. "Priya está en una empresa pequeña haciendo exactamente lo que se supone que debe hacer," dijo Joel. "No sé si volvería." "Me gustaría preguntárselo," dijo el CEO. "Pensé que dirías eso," dijo Joel. "¿Qué más?" dijo el CEO. "La junta," dijo Joel. "Marcus querrá entender el caso financiero. Las penalizaciones por salir del contrato con el proveedor más el costo de reconstruir internamente más el período de transición donde estás ejecutando dos operaciones simultáneamente o ejecutando una operación por debajo del estándar anterior. Ese es un número significativo." "Lo sé," dijo el CEO. "Necesitarás un número diferente que poner frente a él," dijo Joel. "Elena," dijo el CEO. "El error de procesamiento. La tendencia de abandono. Las seiscientas doce cuentas. La distancia entre tres punto seis y cuatro punto dos en una escala de cinco puntos y lo que esa distancia cuesta en valor de vida del cliente durante tres años." "Ese es el caso," dijo Joel. "¿Puedes construirlo?" dijo el CEO. "Sí," dijo Joel. "Tomará dos semanas hacerlo bien." "Hazlo bien," dijo el CEO. "¿Y mientras lo construyo?" dijo Joel. "Voy a llamar a algunas personas," dijo el CEO.

Fin del Capítulo 10

Pensamiento del escritor:

¿Estás pensando en la base de conocimiento específicamente o estás pensando en todo? dijo Maya. En todo, dijo el CEO. Me alegré de que alguien finalmente lo preguntara.

Aquí Está Lo Que Está Roto. El CEO. El Conocimiento Que Se Fue.

MarvinPro | Marzo 2026

marvinpro.com

Piensa Simple.