22 - Mi cuarto cliente : los mercaderes no venecianos ( III )

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.

21 - Mi cuarto cliente : los mercaderes no venecianos ( II )

Todos los desarrollos de sistemas que hicimos en este cliente ( mientras yo estuve ) fueron a medida. Salvo unos devaneos con una herramienta DSS que se les implantó, y que estaba fuera del SC, todo lo demás ( salvo que no recuerde bien ) se hizo a medida. En algún módulo, el SC conectaba con un paquete ( además lo de paquete en el sentido peyorativo del término, de malo, por lo que contaré más adelante ) de software que no hubo forma de eliminar del cliente. Como no funcionaba bien, tuvimos que crear una hoja de cálculo en paralelo que suplía sus funciones ( el TILAS, ya mencionado ).

El primer módulo que desarrollamos en el SC era el de “plantillas de negociación” o negociación de condiciones comerciales con proveedores.

La negociación de condiciones comerciales de compra ( ¿a qué precio compro? ) de un gran distribuidor con sus proveedores es una batalla ardua y compleja en la que muchas veces sale perdiendo el proveedor. Salvo que seas la coca-cola de turno, un proveedor no tiene más remedio que doblegarse ante el monstruo distribuidor de sus productos. El arma del distribuidor para ello : el volumen de compra. Si un proveedor no vende sus productos en un gran distribuidor, puede tener un problema importante de producción y stocks. El distribuidor, sabiendo todo esto, se embarca antes de comprar en un proceso anual de negociación de condiciones comerciales de compra, es decir, establecer los precios de compra de cada producto con cada proveedor. Ajustar el máximo esta negociación sienta las bases del margen final que se obtenga.

El proceso, en aquellos tiempos al menos, era retorcido y complejo y se basaba en una estructura de aplicación de descuentos ( lineales o en cascada ) sobre el precio de tarifa, que tímidamente mostraba el proveedor. Tras aplicar más de una decena de descuentos, ese precio de tarifa se quedaba liposuccionado y a veces anoréxico. Siempre me llamó la atención el por qué complicar tanto la estructura de descuentos de forma artificiosa ( que si descuento comercial 1, que si descuento logístico, que si descuento pronto-pago, que si descuento promocional, que si 3x2, que si descuento porque-mi-hija-hace-la-comunión, .....) en vez de aplicar un único descuento a la tarifa y tener un precio final ( como, de hecho algunos distribuidores hacían ). La razón para mí no es otra que complicar la estructura de descuentos es un arma de negociación en sí misma : se negocia al alza en uno pero a la baja en cinco y al final el proveedor, sin saber muy bien cómo, le están fijando un descuento global de 25 puntos. Porque además los descuentos se aplican sobre el precio tarifa o sobre el precio descontado intermedio en función del orden que ocupe el descuento en la estructura. Vamos, un pequeño lío intencionadamente complicado para llegar al objetivo final : sangrar al proveedor. Cuando contaba mi segundo cliente, comenté que algunos proveedores pierden dinero ( rentabilidad por cliente negativa ) con algunos distribuidores. En este cliente cuarto comprobé que realmente podía llegar a ser así.

Pues bien, para apoyar este proceso, lo primero que hicimos fue preparar una aplicación, que, instalada en un portátil, permitía el jefe de sección de turno sentarse con el proveedor y tras una pantalla de ordenador ( que el proveedor no veía, lo cual aumentaba la tensión y la incertidumbre ) fijar los precios. Un portátil en aquellos tiempos, dentro de una sala pequeña de negociación ( los “box” ) sin un mísero póster que la decorara ( parecía más bien una sala de interrogatorios ), frente a un tipo adusto que no dejaba de mirar en la pantalla, eran elementos más que suficientes para amedrentar al pobre proveedor de turno que sólo quería que sus rotuladores de colores se vendieran en una gran superficie. Y excusarse en la tecnología para mejorar la negociación, todo un ardid en manos de algunos jefes de sección : “Uy, pues el ordenador no me deja, tenemos que bajar medio punto más el descuento logístico, pero a cambio subimos un cuarto el promocional, y, eso sí, me haces un 3x2..... Nada, que sigue diciéndome que no, que hay otro producto competidor a mejor precio, si es que vais muy caros y la competencia os come.....”. Al final el proveedor, sudoroso, ya no sabe si le están contando una milonga o es verdad, claudica y termina saliendo del “box” cabizbajo, con sus tarifas desvalijadas y la única intención de tomarse unos whiskies para olvidar el mal trago.

Hasta ahora he mencionado sólo los descuentos en factura. Aparte se negociaban otros descuentos fuera de factura que se aplicaban por periodos dentro del año y se facturaban en función de volúmenes de compra, presencia en folletos y campañas de los productos, ubicación en cabeceras de góndola, estrategias de merchandising, etc... pero eso es otra historia ( y otro módulo del SC ).

Con esta aplicación ya se dio el primer paso en el proceso centralizador : si antes eran las tiendas las que negociaban con el proveedor cada una por su cuenta, ahora se realizaba una única negociación a nivel nacional en la Central y para todas las tiendas, es decir, se fijaban precios de compra únicos a nivel nacional. Esto por una parte quitaba poder a las tiendas y por otra generaba sinergias de negociación que favorecían al distribuidor : ahora el proveedor no se sentaba a negociar con una tienda y así cincuenta veces sino que se sentaba una sola vez y negociaba con todo el grupo distribuidor, es decir, perdía poder de negociación.

Pues bien, esta sencilla pero estratégica aplicación fue el comienzo. La desarrollamos en unos dos meses y medio entre las 4 personas ya mencionadas ( Mr. π, Mrs. Minutito, Mrs. R. y yo ), con una arquitectura técnica sencillita ( que luego se migraría a otra solución más compleja pero necesaria ). Recuerdo, por ejemplo, que la base de datos no gestionaba los bloqueos de registros, de forma que tenía que ser por código esa gestión. Si no se hacía así, cabía la posibilidad de que el mismo registro fuera modificado por varios usuarios a la vez y se guardarán los cambios del último en cerrar la transacción. Así que, por código, cuando se cogía un registro, se hacía en exclusiva y a los demás usuarios se les mandaba una cajita que decía “registro bloqueado por otro usuario”. Las pruebas de esto se hacían a dos manos en dos teclados ( lo que yo llamo “Nacho Cano’s approach” ). Eran soluciones sencillas para problemas complejos ( ¿o eran soluciones complejas para problemas sencillos? , según como se mire ) que luego se solucionaron de otra forma con una nueva base de datos.

Acabo de acordarme de que mientras trabajábamos en todo esto en una sala con capacidad para unas 10 personas, en la sala de al lado se podía escuchar en ocasiones los botecitos de una pelota de ping-pong seguida de algunas voces, leves risas y algún ajetreo de zapatos. Y era que esa sala de al lado era una sala de relax y ocio para los empleados, y, de vez en cuando, la empleaban y con ello la mesa de ping-pong que había. Nosotros no jugábamos, por supuesto, aunque, de haberlo hecho, hubiéramos parecidos los del anuncio de una conocida marca de trajes ( sobre todo por muchos consultores ) donde un grupo de trajeados juegan al baloncesto, adaptado esta vez a la versión ping-pong.

El líder, pero no remero, de todo esto era Mr. Cr, bajo cuya aura yo continuaba, para lo bueno y para lo malo. Por encima de él, un socio que aparecía sólo de vez en cuando y casi siempre hacia las 19h, con lo que potenciaba el “overtime cultural” entonces imperante ( además el “overtime” no cultural requerido que también existía ). En más de una ocasión, alguno de nosotros que tenía previsto salir un poco antes ese día para resolver alguna cuestión ( o simplemente para tomarse una cerveza con la luz del sol y hacer la fotosíntesis ), cambiaba su expresión cuando escuchaba eso de “hoy viene el socio”, porque sabías que si salías antes ( hablamos de las 18 h, no más, una hora antes a cuenta de las decenas de más acumuladas ), el socio llegaba y tú no estabas, pudiera ocurrir que preguntara por ti y a partir de ahí tu mente paranoica era capaz de elaborar las más terribles consecuencias : subida cero, no promocionar, una X en la lista de los “malos”, etc... Probablemente el socio no iba a preguntar por ti y no habría mayores consecuencias ( de todas formas, había que procurar que no ocurriera esto muchas veces ). El socio llegaba siempre sonriente, bronceado ( en pleno invierno incluso ), con aires de dandi ( con "i" latina, según avala el DRAE ) de los 60, y de alguna forma te daba la impresión ( falsa impresión, sin duda ) de que hasta hace una hora estaba en un SPA tomando aguas y rayos UVA y que a las 18h se ponía su disfraz de socio y se largaba a los proyectos a j...... a supervisarlos. Recuerdo que una de las valoraciones generales que hacía del equipo era que éramos unas personas “un poco grises”. No sé si se refería al color de nuestra piel al no recibir los rayos del sol o a que no nos poníamos a dar saltitos de alegría con sonrisas falsas cuando él aparecía ( hoy me he levantado algo ácido, por lo que releo ).

Mr. Cr en estas fases estaba dedicado, supongo, a la promoción interna dentro del cliente, a vender lo que luego serían las sucesivas fases del SC. Sería más tarde cuando participaría de lleno en uno de los módulos ( bueno, lo de “lleno” es por ser generoso ) y yo, por supuesto, estaría a su cargo. Pero eso vendrá un poco después.

To be continued

20 - Mi cuarto cliente : los mercaderes no venecianos ( I )

Este sí que va a ser un cliente para el que necesitaré varias entradas en el blog. En él estuve a lo largo de casi tres años ( desde marzo de 1995 hasta primeros de 1998 ), realizando numerosos proyectos, la mayor parte de los cuales formaban parte del mismo y gran proyecto en este cliente : apoyar su estrategia de cambio de un escenario de descentralización a uno de progresiva centralización. Luego llegaría una fusión empresarial, pero de esa historia yo pasé muy de lado, ya estaba saliendo de este cliente.

Este cliente era y es un “retailer” importante. Cuando llegué a él ya era grande, pero tuve la oportunidad de verlo crecer todavía y cada vez más. Esto se podía correlacionar con el número de personas consultores que comenzamos trabajando para él ( no más de 10 ) y el número que llegó a ser y sigue siendo ( no me quiero equivocar, pero fácilmente más de 100 ).

En este cliente me incorporé siendo ya Senior ( S1 ) y lo dejé siendo ya S4. Mis primeros proyectos suponían gestionar 3-4 personas en el equipo. Los últimos ya pasé a gestionar en torno a 20. Esto suponía una evolución importante en mis responsabilidades y funciones.

Como todo “retailer”, los sistemas de información estaban separados ( conceptual y técnicamente ) en central y tiendas. Yo llegué para ocuparme de desarrollar los primeros ( en los segundos ya había gente de AC trabajando, de hecho, eran sistemas de tienda desarrollados por AC ), que, al principio, eran de poca entidad, habida cuenta del modelo descentralizado de organización que aplicaba el cliente. Es decir, cada tienda, de alguna forma, era un reino ( de Taifas, claro ), el director de la tienda acumulaba poder y autonomía y mientras reportara buenos resultados a la Central, podía continuar reinando : cada tienda decidía el surtido, los precios de compra, los precios de venta, gestionaba su aprovisionamiento, todos los flujos logísticos, realizaba las compras directamente al proveedor, marcaba sus propias políticas de marketing, acciones comerciales y merchandising, etc... Teniendo en cuenta esto, las actividades centralizadas eran los Servicios Generales ( contabilidad, RR.HH, etc... ) y alguna actividad comercial que tradicionalmente se centralizaba ( por ejemplo el aprovisionamiento y el establecimiento de surtido en el sector textil ).

Pero llegó el momento en que todo esto cambió. La empresa decidió acometer una centralización progresiva de su actividad, para lo cual necesitaba redefinir sus procesos de negocio y adaptar o implantar los sistemas de información necesarios para dar soporte a todo ello. La centralización sería progresiva, poco a poco, como decía un compañero mío en este proyecto, Mr. Cid, “los indios se matan uno a uno”.

Por todo esto, en este cliente tuve la oportunidad de partir de cero en una idea y poco a poco comenzar a implantarla y además verla funcionar. Era como un niño que desde los pañales hasta que comienza a afeitarse está a tu cargo. Luego, cuando ya me fui, el niño ya era todo un adolescente que salía de marcha con sus amigos y llegaba de madrugada a casa los fines de semana. Hoy en día es un adulto maduro que sigue evolucionando. Con ello, una gran ventaja de estar tanto tiempo en el mismo cliente, es que me permitió hacer un recorrido metodológico completo desde al inicio al fin del desarrollo de una solución de negocio ( procesos de negocio, procedimientos, sistemas de información, comunicaciones, formación, atención a usuarios del sistema en marcha, arquitectura técnica necesaria, etc... ). Además, dicho recorrido lo hice varias veces.

Cabe destacar que fue en este cliente donde mejoré notablemente mis conocimientos técnicos más allá de la pura programación, adentrándome un poco más en el detalle de arquitecturas técnicas, modelos cliente-servidor, conexión entre sistemas, comunicaciones, bases de datos relacionales, lenguajes 4GL, programación orientada a objetos, SQL, denormalización de bases de datos para extracción de información agregada ( sistemas DSS y EIS ), optimización de rendimiento de máquina, etc... No obstante, aunque todo suene bonito, todo fueron incursiones genéricas, para manejarse y saber de lo que se hablaba. Los expertos, los de verdad, cuando los necesitábamos, venían y nos ayudaban a la vez que nos enseñaban.

En cuanto al equipo de trabajo, en este cliente tenía como superiores a Mr. π y a Mr. Cr ( después de lo de la mina, volví a casa, como el hijo pródigo ). A mi cargo se incorporaron dos chicas analistas, que posteriormente continuarían trabajando conmigo todo el tiempo que estuve allí ( me fui y siguieron ). Una de ellas, Mrs. Minutito ( seudónimo con todo mi cariño, si ella lo lee lo entenderá perfectamente ). La otra, Mrs.R, tenía apellidos muy adecuados a este cliente. Ambas tenían perfiles técnicos de cara a complementar mi perfil más funcional. Con ellas dos conseguí sacar adelante todos los proyectos que hicimos. Había más gente, sí, más programadores, otros analistas, pero yo decía eso de NO-sin-ellas y supe retenerlas en mi equipo todo el tiempo que estuve en este cliente. Su valía, su capacidad, su compromiso y también el buen rollo que nos unía, eran razones suficientes para no dejarlas escapar. Ellas, a su vez, creo que estuvieron muy a gusto trabajando conmigo, a pesar de los picos de trabajo que tuvimos que compartir hasta altas horas de la madrugada, en ocasiones. Cuando nos juntamos y, como con la mili, hablamos de los “viejos tiempos”, lo recordamos todo con agrado, con risas y mucha complicidad. Son tiempos que ya nunca volverán y que ahora sólo perviven en nuestro recuerdo ( perdón por el punto metafísico-melancólico ).

Entre los tres y con la supervisión necesaria y valiosa de Mr. π íbamos a acometer el primer diseño del primer módulo de lo que sería el futuro y nuevo Sistema Central ( al cual se le dio un nombre que coincide con el de algo que hoy en día forma parte de nuestra comunicación. Es curioso, en aquella época también existía un sistema de información en las tiendas cuyo nombre coincidía con otro elemento clave en nuestra comunicación actual. Cosas de la vida ). Yo lo llamaré SC.

Con el tiempo, conforme se fueron añadiendo más módulos al SC, se fueron incorporando más personas al equipo, especialmente con funciones de análisis y programación. Llegó un momento en que se incorporó otro Senior, con los que la jefatura del proyecto pasó a ser bicéfala. Este senior fue un elemento fundamental en el cliente y con él logré trabajar en equipo con eficacia y solvencia, además de desarrollar una relación personal de amistad que recuerdo con mucho agrado. Era Mr. Cid ( ya mencionado en una entrada anterior ), que, otra casualidad más, el 7 de enero de 1992 se incorporaba a AC, al igual que yo, coincidiendo en el aula de formación donde recibiríamos nuestro primer curso en la empresa ( el Orientation y el SFC ). Tres años más tarde coincidiríamos en este cliente para trabajar juntos. Mr. Cid provenía de otro sector próximo al nuestro ( Retailing ), relacionado con la industria de fabricación de vehículos de transporte, pero fue “adoptado” para ser un chico de Distribución. Cuando yo salí de este cliente, Mr.Cid continuó a cargo de todo, asumiendo la mayor parte de los proyectos en curso en este cliente.

De alguna forma, la incorporación de un segundo Senior trajo al comienzo algunas susceptibilidades inevitables a nosotros dos ( si Mr. Cid lee estas líneas, creo que estará de acuerdo con ellas ). Al principio dos gallos en el gallinero se miden, se miran, se sopesan. No tienen muy claro si se trata de una pelea donde sólo uno puede ser ganador o si realmente es un tándem para reforzar la gestión del cliente y de los proyectos en curso. Poco nos costó convencernos de que era un tándem, que ninguno de los dos éramos especialmente competitivos y que podíamos ( y supimos hacerlo ) trabajar juntos. Al final recuerdo especialmente las conversaciones de café, las frases memorables de Mr. Cid que incorporó a la jerga del proyecto, las risas en momentos críticos de una implantación y el compartir preocupaciones y cuestiones incluso de tipo personal.

También para Mr. Cid tuvo que resultar algo difícil incorporarse como Senior a un equipo que ya llevaba tiempo rodando, con su Senior ( o sea, yo ) y los demás miembros de equipo perfectamente coordinados. Tuvo que llegar y saber abrirse un hueco en el equipo. Y lo supo hacer, sin duda.

Cuando años después yo dejé el cliente ( porque Mr. Cr me requería para el que sería mi quinto cliente ), Mr. Cid quedó a cargo de todo; pero, ni mucho menos, eso significó que un gallo venciera al otro, sino que ambos teníamos que seguir creciendo ( up-or-out ) y yo me iba a un nuevo cliente para ser Gerente, y Mr. Cid se quedaba asumiendo más responsabilidades para prepararse para serlo también.

Por otra parte, Mr. Cid aportó al cliente una visión que se complementaba con la mía, nuevos enfoques, una enorme capacidad para automatizar procesos con Excel ( ya hablaré del famoso TILAS ) y, probablemente, algo más de autodisciplina y método. Con el tiempo me contaron de ciertas dificultades personales y profesionales que tuvo Mr. Cid, creo que hoy ya superadas. No renuncio a volver a encontrarme con él, pero será cuestión de oportunidad y circunstancias, porque hace muchos años que perdimos el contacto directo. En cualquier caso y una vez más, espero que le vaya muy bien, porque, una vez más, se lo merece.

( Como podéis comprobar los que seguís esta historia, suelo hacer este tipo de comentarios hacia personas que trabajaron codo a codo conmigo. No es que todas los merezcan, sino que sólo menciono a los que se lo merecen, desde mi estricto punto de vista personal ).

Dada la envergadura de lo que hay que contar sobre este cliente, no tengo muy claro cómo estructurar la historia. Por una parte puedo continuar cronológicamente contando los distintos proyectos que se realizaron. Por otra parte están lo que vengo a llamar las “anécdotas del proyecto”. Pero contarlo por separado le haría perder unidad a la historia, así que quizá mejor contar ambas cosas en paralelo.

En cualquier caso, por la misma razón de envergadura en el tiempo y en el número de proyectos, voy a entrar poco en detalle sobre los mismos.

To be continued.

Sobre remeros y catalejos

(Esta entrada se la dedico a un excompañero de galeras, Mr. Cid, del que hablaré próximamente, con el que compartí unos cuantos años de alegrías, sinsabores, risas y buenos momentos y con el que hablé mucho de estas cuestiones ).

Como yo lo guardo todo, rebuscando en mi disco duro me encuentro con un documento fechado el 27 de noviembre de 1997 cuyo nombre es “Remero.doc”. Lo escribí en esa fecha para tratar de dar forma a estos conceptos de “remero” y “los que llevan el catalejo”. Al leerlo me he tenido que reír por el juego de palabras que hacía entre “remero” y “ramero” tratando de hacerlos sinónimos. El texto tal cual lo comparto con vosotros, sin querer modificarlo, si bien es posible que actualmente lo escribiera algo distinto :

“¿ Eres un remero ?

En el alabado mundo de la consultoría de sistemas de información existen dos categorías de profesionales : r”A”meros y catalejos.

Los remeros avanzan al grito de “Aaaaaum” y hacen el heroico gesto de mover el remo para impulsar la nave.

Los catalejos al grito de “esta es la mejor solución” fustigan de palabra, obra y omisión a la tropa de remeros.

A lo largo de la vida profesional de un consultor, en ocasiones toca ser remero y en otras ser catalejo. Pero, por curiosos fenómenos estocásticos y desarrollos en series de Fourier, el que rema, rema casi siempre; y el del catalejo, casi siempre lo lleva.

No se encuentra una explicación clara al fenómeno anterior. Las antiguas leyendas, los sueños místicos y el derecho consuetudinario abundan en la posibilidad de la siguiente explicación :

Cuando alguien descubre que un joven chico/a JASP recién entrado en la empresa con ganas de triunfar en el “business” es un buen remero en potencia, le encomienda las primeras labores de remo con el fin de analizar qué tal se desenvuelve.

Si el resultado es positivo se continúa con asignaciones de remo hasta que alcanza el título honorífico de “Remero del Reino” ( también conocido entre los colegas como “Ramero del Reino” ).

Si el resultado es negativo y el chico/a da buena imagen y tiene futuro en el “business” como rémora de remeros, se le otorga el título de “Catalejo del Reino” con entrega de un hermoso catalejo de época chapado en cerezo y oro y lente orgánica ( para que no se rompa con el ajetreo de los remeros y siempre permita una nitidez impecable de la visión del futuro a largo plazo ).

En definitiva, si ya tienes a uno que lo sabe hacer, para qué te vas a arriesgar a que lo haga otro mal.


Checklist :


¿ Has programado durante más de un año ?

¿ Has venido más de un fin de semana a realizar una conversión en un sistema que arranca ?

¿ Sabes lo que es normalizar una base de datos ?

¿ Te sientes capaz de hablar de índices, accesos, sql, campos, claves únicas, huérfanos, etc… sabiendo realmente de lo que hablas ?

¿ Has participado directamente en las labores de puesta en marcha de un sistema ?

¿ Has realizado más de un Diseño Conceptual que luego no has implantado ?

¿ Manejas mejor el Power Point que el TNVT ?”


Nota : el TNVT creo que era una emulación en red para acceder a los ficheros, o algo así, ya no me acuerdo. Creo recordar que el acrónimo se traduce en “Telnet Network Virtual Terminal”.

Adivinad cuáles son las respuestas a las preguntas según seas un remero o un catalejo.

Por cierto, hablando de remeros, algunos conoceréis esta historia.