Hace poco compramos un aparato para casa. Era algo que iba mejorar nuestra calidad de vida substancialmente, así que lo esperamos con mucha impaciencia. Ahora, después de varias semanas de uso, el aparato no solamente cumple con todas nuestras expectativas, incluso las supera. No obstante al principio tuvimos cierta frustración al no encontrar una buena y clara explicación de ciertas funciones en el manual de usuario. El manual explicó cada parte, cada botón y cada manivela o mando. Pero no explicó qué botón, manivela o mando había que activar, abrir o cerrar en caso de querer realizar alguna función en concreto.
Manuales de usuario de software de aplicación.
Lo mismo sigue ocurriendo para manuales de usuario de sotware de aplicación. En demasiadas ocasiones, aún me encuentro delante de guías de usuario que explican la aplicación y no los procesos o tareas que se tienen que llevar a cabo con ella. Incluyen una detallada descripción de los menús, funciones, botones, campos y pestañas cómo si fueran entidades individuales no interconectadas o interrelacionadas.
Explica cómo clavar un clavo en la pared!
Si el manual de usuario de un martillo explica que la herramienta consiste de un mango de un material específico con cabeza metálica pesada en uno de sus extremos, nos dará una descripción verídica del martillo, pero no nos dará ninguna información sobre cómo hay que usarlo. No sería de más utilidad para el usuario explicar cómo clavar un clavo en la pared con el martillo sin pillarse los dedos?Por eso es importante de construir los manuales de usuario alrededor de los procesos y las tareas de las personas que van a utilizar la herramienta. Sé que no estoy explicando ninguna novedad, pero no obstante se siguen produciendo manuales de usuario descriptivos y no activos.Para escribir un buen manual de usuario hay que realizar previamente las siguientes simples tareas:
- Analizar los flujos de procesos elaborados por el departamento de operaciones. Los flujos de procesos ofrecen una vista de pajaro de las operaciones que se llevarán a cabo con la herramienta. Normalmente no desgranan cada tarea, pero dan una visión global de qué departamento es o será responsable de qué proceso y cómo las operaciones están conectadas. Es decir donde acaba la operación de un departamento y empieza la de otro.
- Analizar las tareas diarias que llevan a cabo los departamentos o personas que utilizarán la aplicación. Después de haber analizado los flujos de procesos es hora de hablar con las personas que traducirán estos procesos en tareas concretas. Qué hacen ahora y cómo cambiarán sus tareas utilizando la nueva herramienta?
- Analizar los menús y funciones de la aplicación. Naturalmente es importante saber cuales son todas las funciones, menús, pestañas, etc. Sobre todo porque después de haber analizado los flujos de proceso y las tareas, hay que traducir este conocimiento en un manual lógico para que cada departamento sepa encontrar perfectamente la información que necesita en el manual activo.
Manuales activos son manuales que se centran en la acción más que en la aplicación. De este modo, el manual de usuario de una ERP para el departamento logístico será y tiene que ser distinto al manual de usuario para el departamento financiero o de servicio al cliente, porque cada departamento utilizará la ERP de una manera distinta aunque en algunas ocasiones utilizarán los mismos menús para realizar tareas distintas.[:]
