Proyectos de gestión del conocimiento

Una organización puede tener una doctrina de gestión del conocimiento muy bien escrita y, aun así, no producir ningún cambio. La doctrina existe en el papel; el proyecto es lo que mueve personas, dispositivos y presupuesto durante un tiempo acotado. La distinción importa porque, en la práctica, muchas clínicas y universidades contratan consultoras para que les "hagan un proyecto KM" sin haber decidido antes qué quieren cambiar.

Un programa de KM es permanente y estratégico: acompaña a la organización en el tiempo y mantiene la doctrina vigente. Un proyecto KM es temporal y operativo: tiene fecha de inicio, fecha de cierre y entregables verificables. El proyecto ejecuta una porción acotada de la doctrina; el programa sostiene esa doctrina entre proyectos.

Cuándo sí se justifica abrir un proyecto

Conviene abrir un proyecto cuando el problema tiene tres condiciones: (a) es identificable, (b) tiene un cierre razonable y (c) produce un cambio observable en una práctica. Tres escenarios típicos cumplen las tres:

• Riesgo de pérdida identificable. En un servicio de terapia intensiva hay tres profesionales con más de veinte años de experiencia que se jubilan en los próximos dieciocho meses. El saber que concentran no está documentado. Si la organización no actúa, ese saber se va con ellos.
• Disparidad entre unidades. Dos sedes aplican el mismo protocolo de admisión de pacientes con métodos distintos y resultados distintos. La organización necesita converger y necesita que la convergencia se sostenga.
• Sistema nuevo que requiere transferencia. Se implementó un sistema de registro clínico digital y los profesionales senior saben lo que el sistema no les dice. Sin un proyecto, la gente aprende a fuerza de errores.

Toda iniciativa de KM que llega a buen puerto recorre cinco fases, en este orden, aunque no de manera lineal. Las fases las ordenó la práctica de consultoras como Arthur Andersen a inicios de los noventa, cuando Karl Wiig estructuró los primeros proyectos a gran escala, y luego Thomas Davenport las formalizó tras años de trabajo en empresas como McKinsey, la División de Conocimiento de la OECD y Ernst & Young.

1. Diagnóstico. Antes de mover una sola persona, se mide qué conocimiento existe, dónde reside, qué tan crítico es y qué tan vulnerable es. Sin diagnóstico, el proyecto captura lo que el equipo de turno sabe que existe, no lo que la organización realmente necesita. El producto típico de esta fase es un mapa de saberes críticos por sede y por rol, con prioridades explícitas y una estimación de pérdida si no se interviene.
2. Diseño. Se decide qué se captura, en qué formato, con qué dispositivos, en qué plazo y con qué equipo. El diseño baja el diagnóstico a entregables concretos: una lista priorizada de saberes a capturar, un cronograma con hitos verificables, un presupuesto por partida y un padrino nombrado. Si esta fase se salta, el equipo pasa a ejecutar sin saber qué entregar y termina haciendo lo que le parece.
3. Ejecución. Aquí se captura el saber, se codifica en formatos revisables, se comparte con quienes lo van a usar y se pone en práctica en casos reales. Es la fase más visible y, al mismo tiempo, la más subestimada: la mayoría de los proyectos fracasan porque la ejecución se reduce a "subir documentos a una intranet" sin un plan de adopción, sin sesiones de transferencia y sin acompañamiento a los usuarios.
4. Evaluación. Se mide si los dispositivos producen el resultado esperado. ¿La gente usa el repositorio? ¿Disminuyeron los errores que motivaron el proyecto? ¿Las nuevas contrataciones se incorporan más rápido? ¿Los profesionales senior sienten que su aporte quedó bien registrado? Sin evaluación, el equipo cree que funciona porque se esforzó mucho, y eso no es lo mismo.
5. Sostenimiento. Lo que se construyó durante la ejecución se transfiere a la operación corriente o se entrega a un próximo proyecto. La sostenibilidad no es una fase opcional: si el proyecto termina sin una persona a cargo, lo capturado se vuelve obsoleto en seis meses, los enlaces se rompen, los documentos pierden vigencia y la organización aprende que "el KM no sirve".

Mnemónico en limpio: D, D, E, E, S. La sigla no es elegante, pero el orden funciona porque organiza el proyecto de manera cronológica y evita el error frecuente de saltar de la primera conversación directa a la ejecución.

Un proyecto KM sin personas nombradas queda en buenas intenciones. La estructura mínima viable tiene cuatro roles. Más roles generan burocracia y reuniones vacías; menos roles dejan el proyecto sin respaldo o sin ejecución.

El CKO del proyecto no es lo mismo que el responsable de la doctrina. El responsable de la doctrina cuida la constitución del KM en la organización: los principios, los dispositivos de largo plazo, la coherencia entre lo que se dice y lo que se hace. El CKO del proyecto ejecuta una operación concreta con presupuesto, cronograma y entregables. En una clínica pequeña, la misma persona puede ocupar los dos roles. En una universidad con varias facultades, conviene separarlos para que la doctrina no quede absorbida por la urgencia del proyecto.

La comunidad de práctica merece un párrafo aparte. Es el grupo más difícil de sostener, porque sus integrantes ya tienen trabajo cotidiano y la participación en la comunidad se percibe como una carga adicional. La solución la vía no pasa por exigir más horas, sino por reducir la fricción. Sesiones cortas, agendas concretas, decisiones que se llevan a la práctica. Una comunidad de práctica que no produce decisiones en tres meses consecutivos se disuelve sola.

Los indicadores se dividen en tres capas, en orden de utilidad para la dirección. Davenport, en sus proyectos con Ernst & Young, insistió en que el error más caro de un proyecto KM es medir solo la capa de actividad y olvidar la capa de resultado.

Capa 1: actividad

Mide el esfuerzo del equipo: horas invertidas, documentos capturados, sesiones realizadas, entrevistas completadas. Es útil para el trabajo interno del proyecto. Engañoso si se presenta como resultado a la dirección, porque una organización puede tener mucha actividad y nada de impacto.

Capa 2: adopción

Mide si los dispositivos se usan. Visitas distintas al repositorio, tasa de descarga por documento, cobertura (porcentaje de profesionales que consultaron al menos una vez al mes), puntaje de satisfacción del usuario interno. Mide si la oferta existe y es utilizada.

Capa 3: resultado

Mide el cambio en la práctica. Tiempo de incorporación de nuevos profesionales. Reducción de incidentes repetidos. Variación en la satisfacción del usuario final. Ahorro estimado por reutilización de conocimiento. Es la capa que más importa a la dirección, y también la más difícil de medir porque requiere línea base previa y aislamiento de otras variables.

Una buena práctica es fijar un tablero de tres indicadores (uno por capa) desde el primer mes del proyecto. Los indicadores de actividad sirven para eloperación interno. Los de adopción sirven para detectar a tiempo si la gente no está usando los dispositivos. Los de resultado sirven para la conversación con la dirección.

Karl Wiig, en sus trabajos con Arthur Andersen a inicios de los años noventa, identificó un patrón que se ha repetido desde entonces: los proyectos KM fracasan por un grupo pequeño de causas previsibles. La lista siguiente no es exhaustiva, pero cubre los seis riesgos que aparecen en dos de cada tres proyectos.

Los seis riesgos que más se repiten

1. Confundir gestión documental con gestión del conocimiento. La organización compra una plataforma, sube PDFs y cree que ya "hace KM". El problema es que la plataforma es la herramienta, no el método. Contramedida: dedicar al menos el 40% del presupuesto del proyecto a trabajo de campo (entrevistas, observaciones, mentorías) y no a licencias o infraestructura.

2. Medir la satisfacción del sistema y no la del usuario. Si el único indicador es "cantidad de documentos en el repositorio", el equipo optimiza para subir documentos. Los indicadores de actividad desplazan a los de resultado. Contramedida: combinar capa 1 con capa 3 desde el primer mes, y publicar ambos en el mismo tablero.

3. Patrocinador nominal. El director firma el proyecto en la primera reunión pero no lo mira más. Sin patrocinador activo, los problemas se acumulan y no hay quien los resuelva. Contramedida: una reunión mensual fija entre el CKO del proyecto y el patrocinador, con un tablero de tres indicadores en la mesa.

4. Saber capturado sin contexto. Se documenta el protocolo pero se pierde el "por qué" y el "cuándo aplicarlo". Un protocolo sin contexto se aplica mal. Contramedida: exigir a cada captura una nota de contexto con tres preguntas respondidas: cuándo aplicar, cuándo no aplicar, qué hacer si falla.

5. Sobrecarga del equipo experto. Los profesionales más consultados terminan dedicando horas no remuneradas a entrevistas. La motivación baja y el proyecto se enlentece. Contramedida: incluir en el presupuesto horas pagadas para los expertos que aportan saber tácito, con tarifa pactada por entrevista o por sesión.

6. Cerrar el proyecto sin sostenimiento. El equipo se disuelve, los dispositivos quedan sin mantenimiento, los documentos se vuelven obsoletos, los enlaces se rompen. Contramedida: designar en la fase de diseño a la persona o equipo que recibirá el proyecto al cierre, con horas asignadas y un presupuesto de mantenimiento.

Dos autores marcaron el campo de la gestión del conocimiento con suficiente claridad como para que un proyecto serio los cite. No son los únicos, pero son los más operativos para quien tiene que montar un proyecto concreto.

Thomas Davenport y Larry Prusak

Publicaron Working Knowledge: How Organizations Manage What They Know en 1998, donde condensaron una década de proyectos reales en empresas como McKinsey, Microsoft y la OECD. Tres lecciones siguen vigentes para quien monta un proyecto KM:

• Un proyecto KM empieza con un problema de negocio concreto. No con una declaración filosófica sobre el valor del saber. La primera pregunta del proyecto no es "qué conocimiento queremos preservar" sino "qué decisión de negocio queremos mejorar". Si la primera respuesta no tiene un problema empíricamente identificable, el proyecto todavía no está listo.
• El valor se mide cuando alguien toma una decisión distinta. No cuando el documento se subió al repositorio. Esta distinción obliga al equipo a diseñar los dispositivos en función del usuario, no del archivo.
• Los proyectos exitosos tienen un patrocinador con poder. No un comité sin línea jerárquica. El comité genera recomendaciones; el patrocinador con poder genera decisiones.

Karl Wiig

Antes que Davenport, Wiig fundó la práctica de KM en Arthur Andersen a inicios de los años noventa y publicó Knowledge Management Foundations en 1993. Tres aportes centrales para quien monta un proyecto:

• El conocimiento tiene tres niveles. Tácito (en la cabeza de quien opera), implícito (en la práctica sin verbalizar) y explícito (documentado). Capturar solo explícito deja fuera la mayor parte del saber, porque el saber crítico de un profesional con veinte años de experiencia suele ser implícito. Por eso la entrevista en profundidad y la observación participante son métodos centrales del proyecto, no opcionales.
• Los proyectos se diseñan en torno a actividades, no en torno a plataformas. Una plataforma es un soporte para las actividades; si las actividades no están bien diseñadas, la plataforma solo multiplica el desorden. Por eso Wiig recomendaba arrancar los proyectos con un mapa de actividades y dejar la decisión de plataforma para el final.
• La organización que aprende necesita prácticas institucionalizadas. No iniciativas aisladas. Un proyecto KM que termina en un informe y desaparece no produjo aprendizaje organizacional, produjo un documento más. Por eso la fase de sostenimiento es la más decisiva: lo que se institucionaliza queda; lo que no, se va.

Hay un cuarto autor que conviene mencionar aunque no esté en la cabecera: Ikujiro Nonaka. Su modelo SECI (socialización, externalización, combinación, internalización) es el marco conceptual que sostiene la decisión de capturar saber tácito y convertirlo en explícito. Para los fines de este apunte, basta con saber que existe y que ya se trabajó en M128–M130. Si tu proyecto incluye un componente fuerte de creación de conocimiento nuevo (no solo preservación), vuelve a Nonaka antes de diseñar la fase de ejecución.