Hace unos años monté uno de los desarrollos de los que más orgulloso me siento como programador abap HR. Mi cliente tenía un tremendo caos en los roles y autorizaciones en SAP HCM. Debido a la descentralización y diferentes tipos de usuarios que tenían en RRHH, el diseño original era bastante complejo, y pasado un tiempo, el personal de IT me trasladó que aquello se había convertido en una caja negra.

Con las herramientas estándar SAP podían ver los roles y autorizaciones de cada usuario, y para cada rol las transacciones SAP. Todo esto se trataba de mantener en un fichero excel que por supuesto quedó desactualizado al poco tiempo.

Cada vez que se tenía que crear un nuevo tipo de usuario, con permisos diferentes a los usuarios existentes, o se necesitaba completar una auditoría se seguridad, se tenía que ir prácticamente usuario a usuario para saber a qué tenía acceso cada uno.

El objetivo era claro, disponer de una herramienta que pudiera listar fácilmente a qué transacciones, a qué infotipos, y a qué empleados tenía acceso cada usuario. Esto, que parece algo lógico, no era un desarrollo del que dispusieran las empresas de manera estándar, ni en las implementaciones. Así que nos pusimos manos a la obra.

El programa se podía ejecutar de varias maneras: por usuarios, por roles, por perfiles y por transacción.

En cada uno de estos modos de ejecución, el programa listaba toda la información necesaria para tener una foto clara de los accesos, parámetros, transacciones de cada usuario. El tiempo de ejecución era mínimo al usar lecturas directas a la base de datos sin el peso que implicaban las bases de datos lógicas de HCM. En definitiva, cuando presenté el desarrollo al cliente estaba muy contento con mi criatura y pensaba que había resuelto el problema que tenían.

Pero…. todos pensamos que nuestros hijos son los más guapos y los más listos. Y esto no es así.

En el programa agregué una serie de estadísticas para saber la tasa de utilización y de este modo hacer un seguimiento de la verdadera utilización del programa. Al cabo de unas semanas, vi que solo lo estaba usando yo y otra persona. Obviamente algo no iba bien.

El manual de usuario era muy detallado: pantallazos con flechitas, todos los modos de ejecución, el valor añadido de cada opción, el objetivo de cada una de la funcionalidades, y en qué vistas de configuración se podía hacer un mantenimiento en condiciones.

¿Cuál era problema? Muy poco intuitivo, demasiado complejo de utilizar. Las auditorías se ejecutan cada 6 meses y la persona que debía hacerlas tenía que leer el manual en cada ocasión. Finalmente terminó por pedirme a mí que las ejecutara. Y este no era el plan.

El programa era muy bueno, pero había que simplificar su uso. ¿Cómo?, creando una variante por cada uno de los procesos que se podían ejecutar.

Creé un nuevo manual de usuario, pero esta vez era de solo dos páginas. En ellas enumeraba lo que se podía hacer con el programa e indicaba la variante a utilizar: eran 7 sencillos casos de uso.

Para cada variante había una combinación distinta de columnas en el listado de salida, es decir, había una disposición ALV diferente. De este modo se quitaban columnas que confundían al usuario y que hacía que la salida fuese mucho más clara.

Esto, que no llevó más de un par de horas, fue el cambio que se transformó todo. El programa empezó a usarse cada vez que se creaba un nuevo usuario, cada vez que se detectaba una brecha de seguridad y por supuesto en cada auditoría de seguridad (que no volví a ejecutar nunca más).

Menos es más

Es necesario tener una documentación técnica y funcional detallada y en un formato correcto. Pero también se debe tener un manual de usuario lo más resumido y ejecutivo posible. Centrado en cómo se ejecuta el programa. Separar la paja y el trigo no es fácil, pero es realmente necesario.

“Un desarrollo nuevo, sin formación, no vale de nada”