Junto a la aplicación de la que hablo en el capítulo anterior, preparamos la gestión de los ficheros maestros de artículos y proveedores que sería el germen del módulo posterior de “Gestión de surtido” en el SC. Por surtido entendemos artículos y proveedores, así como toda la estructura de agrupación (sector, sección, familia, etc...).
Esto formaba parte de la estrategia de centralización, porque junto con el primer paso anterior se realizó además una centralización del surtido. Antes cada tienda decidía qué surtido tenía y ahora era la Central la que definía qué surtido era de obligada implantación en todas las tiendas (y además fijaba los precios de compra según lo anterior). Ese surtido común a nivel nacional era sobre el que se negociaba con la plantillas de negociación ya mencionadas. Siempre se dejaba la posibilidad de un pequeño surtido local en cada tienda que era competencia sólo suya (un licor de arándanos que se vende muy bien en Navarra o unas tortitas azucaradas típicas de Cádiz).
El mero hecho de codificar los artículos (darles un código numérico, por ejemplo) ya podía ser un problema complejo y tomar la decisión adecuada algo delicado : asignar códigos “tontos” (que en sí mismos no contienen información ni lógica) o asignar códigos “significativos” (por ejemplo, seis dígitos donde los tres primeros indican la agrupación y los otros un secuencial creciente dentro de la agrupación). Si además la codificación en el sistema de tiendas es diferente a la del sistema central, siendo los mismos artículos, las interfases entre sistemas se complican bastantes y puede llegar a ser necesario realizar una recodificación en los sistemas para disponer una codificación única. Esto dicho así de fácil puede ser algo realmente complicado y delicado, que al final se hizo en este cliente, aunque yo no participé directamente en ello. Éste es un tema con mucha enjundia en sí mismo y que claramente no es objeto de esta historia.
Pues bien, entre mediados de mayo de 1995 y finales de este año nos dedicamos a desarrollar lo que llamamos la “segunda fase del SC”, que consistió si no recuerdo mal en dar forma final al módulo de “Gestión de surtido” antes comentado, así como a dar soporte a los usuarios del sistema ya en marcha (correctivo y evolutivo).
Diseñar y desarrollar unos mantenimientos de proveedores y artículos es algo conceptualmente sencillo : se definen los campos de cada maestro, las validaciones a realizar en el alta, en la modificación y en la baja, el diseño de las pantallas, los informes asociados, las tablas asociadas, etc... Pues no sé cómo, pero el Mantenimiento de Artículos fue uno de los programas más complicados de todo el sistema. Creo que llegó a tener vida propia y una única domadora, Mrs. R, que era la "dueña intelectual" de ese inmenso fuente. Depurar el programa nos costó mucho tiempo, mejorarlos por la inclusión de nuevas funcionalidades colaterales también, y aun así, de vez en cuando mutaba y volvía a “cascar”. Y es que llegó a ser tan complejo que llegó a ser víctima de la teoría del caos y el efecto mariposa, es decir, que tocabas el formato de un campo fecha y te dejaba de funcionar la validación de pedidos pendientes asociados al artículo. Este concepto que muchos que hayan estado a cargo de programas saben que existe y lo habrán sufrido yo lo bauticé como “Isostasia” (concepto geológico creo que hoy en desuso que esudiamos en el colegio los de mi época, eso del SIAL que flota sobre la SIMA y a su vez sobre el manto) y mis programadores llegaron a asimilarlo y tenerlo muy en cuenta : “Hay que modificar esto, cuidado con la isostasia” o “¿qué grado de isostasia tiene esta modificación?”. Tocabas en un sitio y se te movían cinco o seis de forma imprevista. Supongo que una re-estructuración del programa o una división en subprogramas nos hubiera ayudado a no crear ese monstruo. Pero también nos dio “vidilla” y a cuenta del mantenimiento de artículos tuvimos una par de años de risas y anécdotas.
Lo más divertido de este programa era la parte “batch”, es decir, lo que el programa hacía pero no se veía en pantalla : cada vez que se daba de baja un artículo se lanzaba un “trigger” que primero validaba si se podía borrar el registro y luego, si se podía, se dedicaba a borrar uno por uno todos los registros asociados al mismo en la base de datos relacional. Vamos, tú dabas el OK en la pantalla y te ibas a tomar un café pensando que el artículo ya estaba borrado y cuando te ibas a comer todavía estaba el trigger borrando registros. No recuerdo ya si era un procedimiento almacenado en vez de un trigger pero el efecto era el mismo.
Aun así y a pesar de que el trigger debería funcionar bien, quedaban huérfanos en la base de datos ( registros asociados a una clave de artículo que no existía en el maestro de artículos ) y había que entrar por SQL y dedicarse a, primero encontrarlos y luego borrarlos. A eso me dedicaba yo en mis “ratos libres”, mientras Mrs. Minutito (consciente de que mis habilidades técnicas no eran de gurú precisamente) sudaba imaginándose el desastre que podía llegar a hacer cada vez que escribía eso de “DELETE * FROM ARTICULOS WHERE......”, y ese “where” era el que le hacía temblar a Mrs. Minutito (bueno, temblaba mucho más si no ponía el "where"). Al final era un ritual : me acercaba a mi mesa sonriendo y decía a Mrs. Minutito “voy a borrar huérfanos” y ella ya empezaba a inquietarse, “ten cuidado, antes de hacerlo déjame que le eche un vistazo, ¿estás seguro?”. Eran momentos divertidos y, además, nunca llegué a realizar ningún estropicio.
Mrs. Minutito era tan detallista, tan exhaustiva y tan eficiente haciendo su trabajo que un día me la encontré sumando con la calculadora y cuando le pregunté qué hacía, me dijo que estaba comprobando que el programa calculaba bien (había simulado el resultado en Excel y en ese momento estaba comprobando que lo que sumaba Excel era correcto). Estaba haciendo la prueba no sólo del programa sino también del propio Excel. Le dije que para eso ya estaban los chicos de Bill Gates y que si quería llamábamos a un ingeniero electrónico para comprobar que la calculadora sumaba bien con sus circuitos impresos Made in Japan. Todavía nos reímos cuando le recuerdo este momento (Mrs. Minutito es amiga mía) y ella lo niega diciendo que en realidad no comprobaba que Excel sumara bien sino otra cosa. Yo no lo entendí así y tampoco lo recuerdo así, pero la cuestión es lo que nos reímos con esto. Mrs. Minutito fue un elemento fundamental en los sucesivos éxitos de los módulos que íbamos implantando. En su cabeza se contemplaba todo el “corpus” técnico del sistema que íbamos gestando y que no se metiera la pata en sus distintas ampliaciones funcionales dependía en buena parte de ella. Su minuciosidad y atención al detalle aunque a primera vista exagerados fueron clave para hacer bien nuestro trabajo, no me cabe la menor duda de ello (profesional donde las haya, cuya empresa no supo retenerla ni valorarla, pero que, mientras estuve en ese cliente, yo no permití que me la "quitaran" con alguna asignación imprevista a otro cliente).
Recuerdo también que nos incorporaron a un becario para echarnos una mano al triunvirato (Mrs. Minutito, Mrs. R y yo). Era un chico de los que yo llamo de “tránsito lento” con un ritmo vital pausado. Lanzar una impresión e ir a recogerla a la impresora que tenía al otro lado de la mesa era para él dar un paseo como el que va al parque a dar migas a las palomas. Muchas veces lo sorprendías mirando al infinito y tenías que chasquearle con los dedos delante de sus ojos para que volviera al proyecto (debía de tener mucha vida interior y se la traía de casa al trabajo). En una ocasión estaba el becario de pie apoyado en la impresora admirándose de cómo las hojitas salían una a una y ordenadamente y caían a la bandeja cuando de repente me miró como quien observa un fenómeno de la naturaleza (yo andaba ordenando unos papeles) y me preguntó : “¿y tú a qué te dedicas exactamente?”. Mrs. R y Mrs. Minutito se echaron a reír, yo creo que también. “Yo soy el que se asegura de que tú trabajes” o algo así le contesté. Luego ya me puse más en serio y le conté cuáles eran supuestamente mis funciones como jefe de equipo, y creo que logró entenderlas. Pero su paso y su actividad continuaron a su ritmo habitual. De hecho una mañana alzamos la vista y lo encontramos dormido sentado en la silla balanceándose con una perforadora en la mano derecha y unas hojas que se salvaron de la perforación en la izquierda. Con toda la sutileza que pudimos tener, le despertamos.
También en esta época andaban de reformas en las oficinas centrales y en varias ocasiones nos obligaron a movilizarnos (con mesa, ordenador, carpetas, bolígrafos y hasta las fotos de los niños) de una zona a otra del edificio. Hubo creo que hasta cinco mudanzas, en las cuales, por cierto, ayudamos proactivamente : consultores con traje porteando mesas, sillas, CPUs, monitores y cajas de una lado para otro, como ejemplo de integración con el personal del cliente. Y además sin coste adicional, servicio integral en toda regla. Los ruidos de fondo de la maquinaria efectuando las reformas, los obreros con mono azul trabajando entre consultores con traje que tecleaban frenéticos en sus ordenadores, los tubos colgando del techo como lianas de jungla, los martillazos, el sonido de las radiales rompiendo material, todo eso forma parte del atrezzo audiovisual de los recuerdos en este cliente.
To be continued.
3 comentarios:
Yo tambien tenia un gerente que sumaba los resultados del excell... por si te equivocabas en un signo decia el muy cachondo. Lo cierto que alguna vez este sistema en operaciones con signos esta muy bien... pero otras veces es la leche
Jo Yuki, esto es impagable. Que hartón de reir que me he pegado, con tus anécdotas y las mías propias que me han venido a la cabeza al ir leyendo...¡qué bueno!
Por favor, si aún existiera St Charles pediría que pusieran este post en el museo, o mejor, que lo clavasen en las puertas de madera de Arthur Andersen... las originales me refiero.
Realmente muy buena entrada. A mi me ha sucedido exactamente lo mismo, más o menos por la misma época (96). Estaba el sistema que hacía una parte del trabajo, y una pequeña área ("Control Operativo") que hacía... bueh, lo que no hacía el sistema: sacar reportes en excel, arreglar la base de datos, etc.
Creo que las herramientas han avanzado lo suficiente como para evitar este tipo de cosas (procesos manuales para hacer lo que debería hacer el sistema).
Pero sucederá siempre, en alguna medida. Hay veces que es difícil explicarle a la gente de negocios que un sistema no se implanta "y listo", sino que siempre requerirá alguna "ayudita" por parte de los seres humanos.
Basta de bla bla bla, voy a seguir leyendo.
Publicar un comentario