Conseguir que los empleados adopten un nuevo sistema de gestión: un plan práctico

Un sistema de gestión que nadie usa no es un proyecto conseguido a medias: es un coste entero, con un segundo sistema más que mantener, porque el método antiguo sigue funcionando en paralelo. El momento en que se decide si esto va a pasar no es el día de la puesta en marcha. Son las semanas anteriores, cuando las personas que tendrán que usarlo son escuchadas o no lo son.

La adopción no es una cuestión de buena voluntad de los empleados. Es una cuestión de cuánto ayuda u obstaculiza el sistema nuevo el trabajo de cada uno en el momento en que lo está haciendo. Quien encuentre un atajo más rápido fuera del sistema lo usará, y tendrá razón.

A quién implicar, cuando todavía se puede cambiar de idea

Implicar no significa convocar una reunión de presentación con las decisiones ya tomadas. Significa sentar a la mesa, durante el mapeo, a las personas que conocen los casos que nadie más conoce.

• Quien ejecuta la operación más frecuente, la que se repite decenas de veces al día: es la persona que paga cada clic de más.
• Quien gestiona las excepciones, es decir, a quien todos preguntan cuando el caso es raro. Normalmente no es un responsable.
• Quien recibe el trabajo aguas abajo y sufre los errores cometidos aguas arriba.
• Quien habla con los clientes, porque sabe qué información se pide y en qué momento.

El proceso descrito por la dirección es el previsto. El que se ejecuta contiene excepciones, atajos y casos particulares que alguien resuelve de memoria desde hace años. La diferencia entre los dos es la medida del riesgo del proyecto.

Formar sobre las tareas, no sobre las funciones

La formación más habitual es una visita guiada por los menús: se muestra el sistema pantalla por pantalla a todos juntos. Es el formato que más rápido se olvida, porque ninguno de los presentes está aprendiendo su propio trabajo, sino el trabajo de todos.

La formación útil parte de las tareas reales de cada rol y usa datos reales, o al menos realistas. Debe hacerse cerca del momento en que se empezará a usar el sistema: si pasan tres semanas entre la formación y la puesta en marcha, hay que repetirla.

Cerrar las herramientas antiguas, no mantenerlas en paralelo

Mientras la hoja de cálculo antigua siga accesible y cómoda, una parte de las personas seguirá usándola. No por resistencia al cambio: porque funciona, la conocen y en ese momento tienen prisa.

1. Declarar una fecha a partir de la cual la herramienta antigua pasa a ser de solo lectura, y respetarla.
2. Traer el historial que hace falta de verdad para el trabajo diario, no todo el archivo: el resto queda consultable en otro sitio.
3. Eliminar los atajos que permiten seguir como antes, por ejemplo los formularios en papel todavía en circulación.
4. Sustituir, no sumar: si el sistema nuevo pide un dato más sin quitar ninguno, la adopción compite directamente con el tiempo de las personas.

La doble introducción «por seguridad» debe decidirse de forma explícita, con una duración declarada y una fecha de fin. Si queda indefinida se vuelve permanente, y en ese punto el sistema nuevo se percibe como trabajo añadido —cosa que, de hecho, se ha convertido.

Adónde van las dudas

Si la respuesta a una duda depende de quién está disponible en ese momento, las personas dejan de preguntar y vuelven a improvisar. Hace falta un canal único y conocido por todos.

• Un referente por departamento, elegido entre quienes participaron en el mapeo, con tiempo realmente asignado a esta tarea.
• Un único lugar donde se escriben los problemas: no los pasillos, no los mensajes privados al consultor, no los correos a personas distintas.
• Una regla declarada sobre qué se hace cuando el sistema no permite una operación urgente: a quién se llama, qué se anota, cómo se arregla después.
• Un tiempo de respuesta esperado, aunque sea amplio, siempre que sea conocido: saber que la respuesta llega mañana es mejor que no saberlo.

El registro de problemas, y qué hacer con él

El registro solo sirve si alguien lo lee con regularidad. Los campos útiles son pocos: quién, cuándo, qué estaba haciendo, qué esperaba, qué ha pasado, cómo lo ha resuelto mientras tanto.

En la lectura semanal cada entrada va a una de tres categorías: defecto del sistema, que se corrige; conocimiento que falta, que se vuelve a explicar, quizá a todos si se repite; proceso no previsto, que requiere una decisión de la empresa y no del proveedor. Confundir la tercera con la primera es la forma más rápida de hacer infinita la lista de modificaciones.

Medir la adopción: actividades completadas, no accesos

Los accesos indican que las personas entran. No indican que el trabajo pase por ahí. Las señales que describen de verdad la adopción son otras.

• Proporción de las operaciones del período registradas en el sistema respecto a las que realmente ocurrieron.
• Operaciones completadas sin corrección posterior, que indican si las personas saben hacerlas o las hacen a tientas.
• Retraso entre el hecho y su registro: si crece, el sistema se vive como un trámite y no como una herramienta.
• Número de peticiones de ayuda sobre el mismo punto: indica dónde el sistema o la explicación no funcionan.

Estas señales hay que mirarlas por departamento. Una adopción media buena puede esconder un departamento parado, y es precisamente ese departamento del que llegarán los datos que faltan y que estropean las vistas de todos.

Cuándo conviene aplazar o empezar por menos

Hay momentos en los que la misma introducción bien hecha fracasa igualmente, y conviene reconocerlos antes.

• Un período de pico estacional, o un plazo que absorbe la atención de la empresa.
• Ninguna persona interna con tiempo asignado para seguir la puesta en marcha: el proveedor no puede sustituirla.
• Un proceso todavía en discusión entre departamentos: el sistema haría visible un desacuerdo que hay que resolver antes, y no con el software.
• Una función esencial todavía no lista: mejor empezar por un departamento o por un tipo de operación y ampliar después.

Empezar por un grupo reducido tiene una ventaja que va más allá de la prudencia: produce personas internas que saben usar el sistema y pueden explicárselo a los demás con las palabras de la empresa, que funcionan mejor que las del manual.

Lo que esta guía no cubre

Aquí se trata la adopción organizativa: a quién implicar, cómo formar, cómo cerrar el pasado, qué medir. Las pruebas técnicas que hay que hacer antes de poner el software en uso diario —casos límite, datos de prueba, verificaciones sobre los cálculos y los permisos— se tratan en la guía dedicada a la prueba de aceptación. La elección de qué entra en la primera versión y qué espera también tiene una guía propia.