La semana pasada murió Scott Adams el creador de Dilbert. Uno de esos autores que en su momento crea un personaje y una historia que enlaza con mucha gente. Recuerdo que cuando descubrí las historietas de Dilbert vi que lo que pasaba en mi antigua empresa de por las mañanas era algo demasiado común en el mundo empresarial. Y que los jefes pelopincho eran una especie en plena expansión.
Scott Adams contaba que muchas de las aventuras de Dilbert se inspiraban en los correos que los lectores le enviaban contando sus experiencias. De hecho en sus libros tenía secciones donde copiaba directamente algunos de esos correos. Así que hoy voy a hacer un pequeño homenaje a Scott Adams con una historia que nos pasó hace unos días de esas que podría haber sucedido en la Oficina de Dilbert.
Tenemos un cliente que tiene el software de gestión externalizado. Está instalado en un servidor virtualizado en la nube. A principios de año cambiaron a un trabajador. Encontró trabajo sin necesidad de usar el coche y con un sueldo parecido. Así que contrataron a otro en su lugar. El año pasado tuvimos algunos problemas a la hora de dar de baja a un usuario en el servidor virtualizado y sustituirlo por otro en el acto. Así que al final puesto que si avisamos para dar de baja a un usuario, el mes en curso nos lo facturan, decidimos que en estos casos el empleado nuevo seguiría usando el usuario del empleado que se había (eso sí, cambiando todas las contraseñas) mientras los técnicos del servidor nos daban de alta al nuevo usuario y lo probábamos tranquilamente y el último fin de semana del mes hacíamos la transferencia de datos sabiendo que todo estaba ya operativo en el nuevo usuario.
Cuando nos avisaron del cambio de empleado, pasamos instrucciones al CAU del servidor en la nube para cambiar las contraseñas del usuario del empleado que nos dejaba y los datos para crear el nuevo usuario. El nuevo empleado llegó y empezó a trabajar con el usuario existente, mientras nosotros probábamos el nuevo usuario.
Pero al cabo de tres días el nuevo empleado no podía trabajar. No accedía al servidor. Nos llama y yo abro incidencia en el CAU del proveedor y mientras como tenía muy avanzada la configuración de su nuevo usuario, pienso en hacer ya el cambio. Pero cuando entró a probar el nuevo usuario tampoco funciona. Ni yo ni los técnicos del servidor entendíamos nada. Así que empezamos a investigar los dos a ver si antes que nada encontrábamos una explicación a los problemas.
Y descubro que dos días antes el jefe comercial del aplicativo de gestión había llamado al jefe de la empresa que es cliente nuestro. Nuestro cliente le había comentado que iba a necesitar varios usuarios nuevos (para empleados que están a punto de incorporarse) y también que uno de los empleados había que cambiarle el usuario.
El jefe comercial le dice que no se preocupé, que él se encarga de todo. Así que llama al jefe de la parte técnica y le dice que como quieren quedar bien con nuestro cliente, que den de baja el usuario del empleado que ya no trabaja y den de alta el nuevo usuario y que ellos se encarguen de las pruebas y de la configuración final para tenerlo todo disponible al día siguiente.
Y eso fue lo que pasó. El jefe del área técnica se encargó del asunto. Pero en el sistema de esta cliente hay algunas cosas que no son como parecen. Los técnicos del CAU que nos conocen lo saben. El nuevo usuario no funcionaba porque algunas cosas de la parametrización interna que hacían desde su CAU y luego probábamos nosotros no las hicieron… así que ese nuevo usuario no era capaz de usar los sistemas de nuestro cliente.
Una vez entendimos lo que había pasado la solución fue rápida. Desde el CAU reactivaron el usuario dado de baja (menos mal que no lo borraron) y se lo activamos a nuestro empleado. Y borraron el usuario mal creado y lo volvieron a crear.
Como siempre digo, a veces el ir deprisa y no preguntar a los que están en el día a día trae problemas… pero es lo que hay.