El término, prestaciones leperas, lo inventamos hace unos años para referirnos a lo que voy a comentar en este artículo. Dejamos de usarlo debido a que en algunos casos se consideró ofensivo, o así lo interpretaron algunas personas. Pero hoy estoy dispuesto a rescatarlo, apelando a dos motivos. Por un lado el humor, y por otro la necesidad de abordar un problema real que es necesario resolver. Al final del texto voy a intentar justificar mi postura y pedir comprensión para la misma. En función de lo que haya argumentado espero recibir la aprobación o la desaprobación
La definición de las prestaciones leperas son peticiones que hacen algunos usuarios de prestaciones que dicen necesitar pero que no las necesitan, son algo absurdas y sin embargo se plantean como necesarias.
Veamos algunos ejemplos.
Hace unos años debido a los problemas de capacidad en los ordenadores muchas de nuestras aplicaciones de gestión separaban los datos por ejercicios. Así si una persona estaba trabajando en el año 1990 y quería consultar un albarán de 1988 debía salir de la aplicación y volver a entrar indicando el cambio de año. A final de año era necesario ejecutar un proceso de fin de ejercicio, que abría nuevos ficheros, copiaba datos, calculaba algunos acumulados y dejaba el tema operativo. Lo que hacíamos es guardar en sitio distintos cada año, porque no cabían juntos. El método funcionaba relativamente bien y como además había informes interanuales (con acumulados) resultaba relativamente cómodo.
Ahora bien, las capacidades evolucionaron. En 1985 un disco de 10 Megabytes costaba medio millón de pesetas (3000 euros), pero en los años noventa los discos duros de decenas de megabytes eran relativamente baratos y en el siglo XXI ya nos sobraba capacidad para una gestión normal incluso con los discos más baratos del mercado. Hoy una memoria USB de 16GB vale menos de 10 euros. Compara:
Es obvio que las circunstancias han cambiado, ¿verdad?
Total, que hicimos que la aplicación de gestión no necesitara el fin de año puesto que teníamos ya espacio de sobra. Sin lugar a duda fue un avance y nos permitió no tener que estar especialmente atento los primeros días de cada año a posibles problemas. La aplicación era capaz de trabajar con varios años a la vez y desde la misma ficha de cliente se podía consultar todo el histórico.
Pues bien, tuvimos un problema curioso: Dos clientes demandaron con urgencia... ¡la utilidad de cierre de año! porque sin ella no podían trabajar.
Ahora bien, las capacidades evolucionaron. En 1985 un disco de 10 Megabytes costaba medio millón de pesetas (3000 euros), pero en los años noventa los discos duros de decenas de megabytes eran relativamente baratos y en el siglo XXI ya nos sobraba capacidad para una gestión normal incluso con los discos más baratos del mercado. Hoy una memoria USB de 16GB vale menos de 10 euros. Compara:
- año 1985 .... 10 MB cuestan 3000 euros
- año 2013 .... 16000 MB cuestan 10 euros
Es obvio que las circunstancias han cambiado, ¿verdad?
Total, que hicimos que la aplicación de gestión no necesitara el fin de año puesto que teníamos ya espacio de sobra. Sin lugar a duda fue un avance y nos permitió no tener que estar especialmente atento los primeros días de cada año a posibles problemas. La aplicación era capaz de trabajar con varios años a la vez y desde la misma ficha de cliente se podía consultar todo el histórico.
Pues bien, tuvimos un problema curioso: Dos clientes demandaron con urgencia... ¡la utilidad de cierre de año! porque sin ella no podían trabajar.
Otro ejemplo fue el siguiente: Por cuestiones de auditoría un cliente referenciaba unos documentos con determinadas claves. Concretamente una letra según el tipo y luego un número correlativo. El problema es que si descubría un error tenía que volver a etiquetarlos para mantener la numeración correlativa. El cliente nos pidió no recuerdo algo así como un programa que sacara las referencias para que una persona pudiera modificarlas. Me costo horas convencerlo de que no hacía falta para nada, de que la aplicación podía asignar inmediatamente las referencias.
Tengo otro ejemplo que me molestó grandemente por el tiempo perdido. A la hora de clasificar los lotes de fabricación de determinados alimentos existía un enfarragoso sistema de codificación. El lote se numeraba según el matadero de dónde provenía, el mes en que entraba y la previsión de curación. Como podía coincidir matadero y mes, a veces había que añadir una letra adicional. Además la previsión de curación cambiaba con lo cuál era un dato falso en muchas ocasiones. El lote debía ir puesto así en las etiquetas. La solución es fácil: numerar los lotes y recoger todos esos datos que se imprimirían como hiciera falta. Pero según el cliente ¡eso no servía!, el código tenía que ser justo el que él decía porque si no no podía vender luego. De nada sirvieron mis explicaciones de que le podíamos crear una referencia como él pedía, pero que no era necesario cómo código. Además tampoco le valía teclear el código. Tenía que dar los datos, la máquina crear el código y luego usarlo para las consultas. Debía pensar que había algo de mágico en la creación del código. Además había que prever un código de barras capaz de soportar las letras.
No sigo, que tengo muchos más ejemplos. Cómo vemos se trata de tres peticiones que no son necesarias, que sirven para hacer algo que no hay que hacer. ¿Por qué se pide? pues porque la inercia de los procesos hace que se hagan mecánicamente. No se piensan y se crea un drama falso cuando se plantea de hacerlo bien.
Por si no ha quedado claro, lo resumo con una anécdota. Una mujer le enseñó a su hija a preparar los churrascos de carne. Lo primero era partirlo en dos partes. Cómo eso era pesado le preguntó la hija que para que servía. La respuesta fue que así se lo había enseñado la madre. Pasado el tiempo llegó la abuela y surgió la pregunta:
- Mamá, me enseñaste que había que cortar los churrascos en dos partes ¿eso era para que se cocinara mejor?.
- No, es que mi plancha era pequeña y no cabían enteros
Tengo otro ejemplo que me molestó grandemente por el tiempo perdido. A la hora de clasificar los lotes de fabricación de determinados alimentos existía un enfarragoso sistema de codificación. El lote se numeraba según el matadero de dónde provenía, el mes en que entraba y la previsión de curación. Como podía coincidir matadero y mes, a veces había que añadir una letra adicional. Además la previsión de curación cambiaba con lo cuál era un dato falso en muchas ocasiones. El lote debía ir puesto así en las etiquetas. La solución es fácil: numerar los lotes y recoger todos esos datos que se imprimirían como hiciera falta. Pero según el cliente ¡eso no servía!, el código tenía que ser justo el que él decía porque si no no podía vender luego. De nada sirvieron mis explicaciones de que le podíamos crear una referencia como él pedía, pero que no era necesario cómo código. Además tampoco le valía teclear el código. Tenía que dar los datos, la máquina crear el código y luego usarlo para las consultas. Debía pensar que había algo de mágico en la creación del código. Además había que prever un código de barras capaz de soportar las letras.
No sigo, que tengo muchos más ejemplos. Cómo vemos se trata de tres peticiones que no son necesarias, que sirven para hacer algo que no hay que hacer. ¿Por qué se pide? pues porque la inercia de los procesos hace que se hagan mecánicamente. No se piensan y se crea un drama falso cuando se plantea de hacerlo bien.
Por si no ha quedado claro, lo resumo con una anécdota. Una mujer le enseñó a su hija a preparar los churrascos de carne. Lo primero era partirlo en dos partes. Cómo eso era pesado le preguntó la hija que para que servía. La respuesta fue que así se lo había enseñado la madre. Pasado el tiempo llegó la abuela y surgió la pregunta:
- Mamá, me enseñaste que había que cortar los churrascos en dos partes ¿eso era para que se cocinara mejor?.
- No, es que mi plancha era pequeña y no cabían enteros
