Tradicionalmente el diseño de los ERP’s, CRM, BI, … ha estado orientado a los desarrolladores, dejando de lado ciertas peticiones, no tanto funcionales, sino operativas de los usuarios. Ello ha provocado sistemas difíciles de manejar en cuanto a complejidad y con un requerimiento de formación muy importante para los usuarios. La demostración más fehaciente la tenemos en las aplicaciones que nos instalamos cada día en nuestros smartphones y tablets con tiempos de formación y aprendizaje muy reducidos. Siendo la tendencia cada vez más actual de simplificar estas aplicaciones y hacerlas más intuitivas para los usuarios, los ERP, CRM, BI, … cada vez tienen menos de intuitivos y más de complejos. Si bien es cierto que hay procesos que lo son y por tanto difíciles de simplificar para el usuario, estoy seguro que siempre los desarrolladores podemos hacer algo más para cambiar esta tendencia realizando un diseño software centrado en los usuarios. Y entonando un mea culpa he de decir, que en mi caso, hay mucho margen de mejora.
También es cierto que simplificando simplificando, algún avezado usuario ha solicitado el botón mágico que una vez pulsado nos diga la situación económico-financiera de la empresa con un valor único.
A mi no me cuentes de balances, ni márgenes ni ratios. Yo solo quiero saber si gano o pierdo. Un botón de esos que tiene el Bush que al pulsar me diga si gano o pierdo.
(Esta frase síntesis máxima de la simplificación -y simplismo- es real, oída hace unos años al gerente de una empresa, imaginar como terminó la implantación).
Bajo mi punto de vista, las reglas que ha de cumplir un ERP cualquiera para un diseño software orientado al cliente, son totalmente análogos a los que podamos exigir a una web. Y aunque es bastante habitual hablar de ello en el desarrollo web, no se hace el suficiente hincapié en otros tipos de software.
No es lo que hace el software, es lo que hace el usuario. (Fuente: Gapingvoid)
Veamos algunas de estas reglas que debe cumplir el diseño software.
Usabilidad
Podríamos resumirla en la eficiencia en la realización de las diversas tareas y en la percepción del usuario de éstas. La usabilidad debe estar dirigida, es decir, no puede satisfacer a cualquiera que se siente delante de la pantalla, pues sería imposible, pero sí de tratar de satisfacer las necesidades de la inmensa mayoría de usuarios que vayan a manejar la herramienta.
Accesibilidad
No exclusión de ningún usuario por limitaciones del software. Un ejemplo muy sencillo de entender sería: si el software no posee una
interfaz multiidioma, excluirá a un gran número de usuarios.
Visibilidad
Sistemas de búsqueda que nos permita localizar cualquier información. Formularios de consulta que permitan localizar cualquier dato
esté donde esté.
Utilidad
Todo proceso o tarea ha de estar orientada a un objetivo con un valor añadido. Ejemplos inútiles son todos aquellos que requieren intervenciones periódicas para corregir o regenerar ciertos datos. Si estos procesos necesariamente han de existir, mejor que sea el sistema capaz de realizarlo automáticamente y no requiera esa intervención humana.
Lógica y comprensibilidad
Igual que en una web no podemos exigir a un usuario que realice un proceso incomprensible e ilógico, podemos extrapolarlo a un ERP. Cualquier operación ha de ser coherente y lógica desde la perspectiva del usuario.
Entendimiento
Hablar en los mismos términos el software y el usuario no generará a éste una afinidad con el primero debido al uso del mismo lenguaje sino a evitar fallos de comprensión. En estos casos, los mejores sinónimos son los inexistentes. Por ejemplo, si el concepto es «Cliente», siempre será «Cliente» y no «Entidad», «Tercero», …
Reducción de errores y/o malas prácticas
Muchos controles pueden realizarse sin un coste elevado para el desarrollador, evitando así errores descontrolados
que en ocasiones pueden provocar otros efectos indeseados. Un ejemplo muy sencillo de aplicar y que evita multitud de errores son máscaras de formato de fechas, números, etc.
Interactividad
Si el sistema va alertando al usuario de determinados eventos, deja a éste su tiempo para la realización de tareas de mayor valor, ofreciendo a éste avisos solo cuando requiere su atención. Esta interactividad es importante pero a su vez puede ocasionar un exceso de información al usuario y en ocasiones también un entorpecimiento de sus tareas habituales, por lo que debe ser medida adecuadamente.
Teclas de acceso rápido
Éstas permitirán agilizar las tareas cuando sean conocidas por el usuario.
Clarificación de mensajes
Diferenciar claramente mensajes informativos, restrictivos, de error, de decisión, de aviso, de progreso, etc. Categorizar estos avisos y que sean para el usuario lo suficiente explícitos en cada momento para evitar dudas por parte de éste.
Trazabilidad
Trazar cualquier dato a través de los flujos de información y de forma bidireccional. Ejemplo muy simple: saber en todo momento la relación entre un pedido, albarán, hoja de carga, factura, etc.
Estoy seguro que hay muchos más requisitos que debe cumplir el diseño software para considerar que está diseñado centrado en el usuario. ¿Cuáles se te ocurren a ti?
Autor: Sergio Martínez|
Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly |
|
Es interesante reflexionar sobre estos conceptos que muchos desarolladores y empresas no tiene presente. Creo que la mejor manera es que quienes desarrollan «operen» el sistema en entorno real, para que ellos mismos perciban las dificultades que genera la forma en que el mismo fue diseñado.
Otra idea que considero de valor, y pocas veces vi aplicada, es la necesidad de disponer de ayudas on line a nivel de cada campo, ya no solo como elemento que entregue el proveedor, sino la posibilidad de complementar dicha
ayuda con comentarios (observaciones, recordatorios, etc.) que cada uno de ellos genere.
Un punto no menor es identificar con precisión cada pantalla / reporte / mensaje / punto de menú, etc., con un código específico que permita mejorar la precisión con la cual se informen inconvenientes o errores a la mesa de ayuda del proveedor, o simplemente se solicite auxilio para operar.
Creo que muchas de estas soluciones contribuirían a facilitar el uso de los aplicativos y, si hacemos bien las cuentas, representarían una ecuación «ganar-ganar» para clientes y desarolladores.
Gracias Benjamín por tu comentario.
Como dices, ponerse en «la piel» del usuario es clave para realizar un diseño que sea operativo y funcional para éste. En ocasiones se busca la comodidad en el desarrollo en detrimento de los procesos del usuario y esto es una condena al fracaso a medio plazo por parte del software.
Sin embargo, también es cierto que el usuario tiende a querer simplificar en exceso los procesos. Hace unos días me decía un cliente que porqué el ERP mostraba tantos mensajes al usuario incomodando al usuario. Cuando le dije que me mostrara algunos ejemplos, todos eran en la línea de cuestiones que el sistema no podía resolver por sí solo y que requería la intervención del usuario. Es decir, el software hacía preguntas al usuario para determinar el camino a seguir, sin embargo éste quería tal agilidad que cualquier pregunta le parecía improcedente. Y esto hay que hacerle ver al usuario que el software no puede tomar decisiones por sí solo y que requiere un mínimo de intervención humana para ir resolviendo esas cuestiones.
Gracias de nuevo. Te animo a comentar cuanto quieras. Un abrazo.