Reinventar la rueda: Directorio de empleados
Recientemente se planteó la necesidad de realizar una aplicación Directorio de los empleados de la empresa cliente, que pueda ser actualizado con el tiempo por un administrador. Por tanto, la aplicación consta de una parte pública para todos los empleados (el directorio en sí mismo donde consultar los datos públicos de los empleados) y una parte privada para la administración.
Vale, concertamos una reunión para hacer una demo "funcional" de la aplicación, y montamos otra reunión para la presentación. El cliente acepta tanto el diseño funcional como la presentación, y hacemos una demo final con el funcionamiento, la presentación y unos datos de empleados inventados. Recibimos el ok.
Qué falta ??? Pues sí, los datos REALES de los empleados.
El cliente nos facilita 4 fuentes de datos de empleados, provenientes de tres departamentos diferentes, cada una con campos de datos diferentes de los empleados, desincronizados y no centralizadas (los procesos de alta de empleado, baja de empleado y modificación de datos NO implica necesariamente un alta/baja/modificación en todas las fuentes, depende del humor de su administrador), y sin claves para identificar los empleados (hay que cruzarlos por nombre+apellido1+apellido2).
El cliente nos pide que para la carga incial de datos las fundamos en una única base de datos MySQL con al menos el 90% de los empleados, y el resto se cargarán manualmente. El mantenimiento correrá a cargo de un administrador del cliente por determinar.
Dónde está Wally ??? Seguro que 9 de cada 10 lectores se darán cuenta inmediatamente de que este sistema no es viable en el mundo real (y eso que no he mencionado detalles como que no había teléfonos en el 95% de los empleados, que era el campo más importante).
Hemos partido de una situación con 4 fuentes de datos no sincronizadas y no centralizadas y hemos llegado a una situación con 5 fuentes de datos no sincronizadas y no centralizadas. Un avance espectacular.
Además nuestra nueva fuente de datos no es fiable ni completa.
El mantenimiento: no voy nada más que a hacer una pregunta … cómo se mantienen estos datos SATISFACTORIAMENTE ?
Esto costó sus buenos días (y por tanto euros) tirados a la basura. No pude ser más claro (utilicé "imposible de mantener" varias veces), ni más insistente (al menos lo decía tres veces al día) ni más previsor (cuatro meses diciéndolo).
La solución
A ningún genio se le habría ocurrido.
Primero, obtener datos reales. Para ello, simplemente se debe realizar una plantilla. Y luego dos soluciones: que los rellenen propios empleados (por medio de un correo-electrónico, por medio de responsabilizar a los responsables de cada departamento, por medio de responsabilizar a RRHH…). La otra, contratar a alguién para que vaya puesto por puesto preguntando. Ambas fiables, más baratas y se tardaría menos de lo que nosotros tardamos.
Segundo, centralizar los procesos de alta, baja y modificación de datos de los empleados. Para eso está RRHH en la mayoría de las empresas. Estos tres procesos llevarán a cabo una serie de tareas. Se debería de añadir una tarea más que fuese actualizar la única fuente de datos de los empleados (o incluso dar la orden para que "Sistemas" modifique estos datos).
No related posts.
