Muchos proyectos de gestión del conocimiento fallan porque exigen a las personas hacer más cosas en su día a día. La implantación de cualquier iniciativa de GC exige unos conocimientos básicos de Gestión del Cambio y de mejora de procesos.
La gestión del conocimiento está llena de carísimos cadáveres: sistemas documentales que nadie usa, procedimientos que nadie aplica, intranets que sólo sirven para enseñar en conferencias y un largo etcétera.
En este tipo de proyectos (y en sus primos hermanos de gestión de la calidad) hay un error de base: fallan porque exigen a las personas hacer más cosas en su día a día (rellenar una ficha, codificar un documento, documentar un hecho). Fallan además porque no tienen en cuenta la primera pregunta que todos nos hacemos ante una iniciativa cualquiera: “¿y esto a mí que me aporta?”.
Si la respuesta de los usuarios es “más trabajo” el proyecto fracasará con toda seguridad.
Es un error de bulto pensar que esta actitud se puede contrarrestar con comunicación sobre las bondades del nuevo sistema, con formación sobre cómo se usa o con incentivos a la participación.
Los especialistas nos dirán que aquí estamos tratando un problema típico de gestión del cambio: “¿Cómo consigo que la gente haga su trabajo de forma diferente y/o que haga más cosas?”.
Se entiende que si estamos promocionando o “vendiendo” en nuestra organización la aplicación de un procedimiento o sistema que afecta a un proceso de trabajo es porque con anterioridad nos hemos hecho las 2 preguntas mágicas:
- ¿Cuáles son los procesos clave que aportan valor a mi organización?
- ¿Cómo puedo mejorarlos?
Esto implica que nos hemos replanteado, analizado, repensado y simplificado cualquier proceso antes de plantear un procedimiento que le afecte. También significa que hemos seleccionado algunos de entre todos los procesos posibles.
Cuantos menos sean mejor.
Pregunta de no retorno 01: ¿Es así? ¿el nuevo procedimiento o sistema responde a una “reingeniería” o análisis previo de la adecuación del proceso?
- Si la respuesta es “NO”, aquello que se esté intentando implantar fracasará con toda seguridad al suponer más tareas a lo que ya hago. Vuelta a la casilla de salida.
- Si la respuesta es “SI” (es decir, hemos replanteado y simplificado el proceso antes de desarrollar y vender el sistema), sólo conseguiremos que se utilice en el caso de que hayamos involucrado a los usuarios, clientes y sufridores finales en ese análisis. Avanzamos dos casillas.
Ya tenemos pues un proceso clave más simple, más efectivo y en teoría más rentable para la organización. Ahora toca desarrollar el sistema que lo soporte o lo apoye para obtener una ventaja real. Por supuesto nos habremos hecho más preguntas:
- ¿Qué coocimiento es necesario?
- ¿Qué conocimiento se genera?
- ¿Cómo puedo gestionarlo?
- ¿Cuánto me va a costar?
- ¿Es rentable?
Supongamos que hemos contestado a todas estas preguntas y hemos decidido (con la aprobación de los de arriba) seguir adelante. Tiro porque me toca. Caemos en el pozo y nos encontramos con que el sistema falla.
Pregunta de no retorno 02: ¿hemos involucrado a los usuarios finales (en número suficiente y de diferentes perfiles) en todo el proceso de diseño de la solución (sea un procedimiento, sea un sistema de gestión documental, o cualquier otra iniciativa de gestión de conocimiento)?
- Si la respuesta es “NO”, el procedimiento encontrará una resistencia que no se vencerá ni con formación, ni con incentivos, ni con amenazas. Exigirá “dar marcha atrás” y revisarlo paso por paso con un grupo seleccionado de usuarios del mismo. Esto ralentizará el proyecto e incrementará su coste. Atrás diez casillas.
- Si la respuesta es “SI” (es decir, no sólo hemos simplificado el proceso con la ayuda de quienes lo aplican, sino que además hemos contado con los destinatarios finales del sistema en su diseño) nos encontraremos con un producto ganador en nuestras manos. Avance hasta la Oca.
No olvidar que…
- A nadie le gusta que le digan que su forma de actuar o de trabajar no sirve o es errónea. Por eso, cualquier proyecto de cambio deberá fundamentarse en razones externas (necesidades del mercado, llegada de nuevas tecnologías, etc.) para que la gente entienda la necesidad de un cambio.
- Tampoco es de recibo que te digan que tienes que cambiar varias o muchas cosas de las que haces. Por eso es mejor empezar únicamente por aquellos aspectos críticos del proceso que haya que cambiar. Cuantos menos mejor. Una vez estos cambios hayan sido interiorizados ya podremos ir a por otros.
- Es indispensable que el cambio esté esponsorizado por “los de arriba”. Pero es igualmente indispensable que no sea percibido como una imposición, sino como una necesidad fundamentada en factores muy claros (rentabilidad, necesidades del cliente, etc.) y bien comunicados.
- Una de las premisas fundamentales para que un sistema funcione es que los usuarios del mismo hayan participado desde el principio en todo el proceso de diseño y desarrollo. Nadie sabe más sobre algo que quien lo tenga que utilizar.
