26 - Mi cuarto cliente : los mercaderes no venecianos (VII)

En una entrada final quiero contar resumidamente los últimos proyectos en este cliente (aunque resultará una entrada larga, que se puede leer por partes). Abarcan desde diciembre de 1996 hasta fin de 1997, más de un año de trabajo durante el que continuamos desarrollando nuevas funcionalidades y nuevos módulos del SC, tocando más palos y continuando con el proceso de centralización que es la clave en este cliente.

Entre otras cosas se centralizarán los PVP de los productos de marca propia y productos de mejor precio. En la estrategia comercial de un distribuidor es típico desarrollar marca propia (o marca blanca, como se llamaba al principio). Este cliente optó en aquel momento por la estrategia de situar su marca propia entre los productos de marca conocida y los productos de mejor precio. Es decir, quiso posicionar su marca como un buen producto a un buen precio. Para ello elegía para cada producto uno de mejor precio, es decir, el más barato para el público y situaba el PVP del producto de su marca por encima de éste pero por debajo del producto correspondiente de marca conocida. Por ejemplo : el Nescafé 400gr a 4,85€, el café soluble marca propia a 3,20€ y un café soluble marca Pepe a 2,15€. Fijando bien esta estrategia de PVP era posible mejorar notablemente el margen por producto y por tanto el margen final, atendiendo a la negociación de los precios de compra (ya centralizados) y a la rotación del producto en los lineales de cada tienda. Todo ello junto con una buena campaña de marketing y promoción de la marca propia en los folletos y promociones de cada tienda.

Como quiero ser breve, para finalizar ya con este cliente, comentaré brevemente los proyectos de esta etapa final junto con anécdotas y recuerdos que me surgen sobre la tecla.

El siguiente proyecto que desarrollamos vino a ser un módulo más en el SC y consistió en un sistema de compras centralizadas para las tiendas aplicado al sector de textil. Las tiendas venían a la Central a realizar los pedidos que la Central les serviría en sus tiendas posteriormente. Ya existía un sistema que realizaba estas funciones pero el proyecto consistía en clonar este sistema en uno nuevo dentro del SC y bajo la nueva arquitectura. El sistema antiguo corría en una máquina cavernaria y estaba codificado en RPG (¡¡!!). Así que nuestro nuevo proyecto (esta vez sólo para mí con mis chicos) consistía en realizar labores de “bodyshopping”, pero, eso sí, de alto nivel, y me explico.

Cuando nos explicaron lo que había que hacer dijimos, muy fácil, dadnos toda la documentación del diseño funcional, técnico y detallado de la aplicación antigua y los fuentes, fijamos unas entrevistas con los usuarios (tanto de la Central como de tiendas) para recoger mejoras funcionales a añadir y nos ponemos a clonar. “No hay documentación alguna, ni siquiera de la base de datos. No hay acceso a los fuentes”. Pero entonces, “¿cómo mantenéis la aplicación?”.”No se mantiene, funciona bien y no da errores”. Por causas que no recuerdo o que quizá no nos contaron no disponían de los fuentes, de ningún tipo de documentación, no se podían editar los programas (sólo tenían los ejecutables) y sólo contábamos con los usuarios que nos podían explicar la funcionalidad de la aplicación y con la colaboración puntual de un analista-programador de AC que diez años antes había participado de lleno en el desarrollo del sistema. Así que el “body-shopping” pasó a ser un desarrollo artesanal con un enfoque metodológico totalmente nuevo para mí : prueba a fondo un sistema metiéndole datos y viendo el “output”, aplica el método de ensayo-error y fíate de lo que te cuentan los usuarios, vamos una especie de “ingeniería inversa” con un toque surrealista.

Y así lo hicimos. Desarrollamos el sistema bajo la nueva arquitectura, con las mejores sugeridas por los usuarios (imaginad lo complicado que resultó la gestión del proyecto para controlar lo que quedaba dentro del alcance y lo que no cuando de antemano fue imposible establecerlo) y además logramos que funcionara como el antiguo, pero más bonito. Recuerdo un par de procesos de cálculo interno que realizaba el sistema que nos costó horas y horas descubrir cómo funcionaban, qué algoritmo y qué calculo aplicaban. Y todo a base de meter datos de todo tipo, para encontrar el cálculo habitual y encontrar, lo que es peor, las excepciones al mismo (que las había, y algún usuario te daba alguna pista, “cuidado, que cuanto no hay talla y sí color el sistema tiene que obviar el dato X”). Recuerdo las horas interminables con Mrs. Minutito metiendo datos en el sistema antiguo y viendo el resultado para tratar de averiguar cómo funcionaban las entrañas, a las que no podíamos acceder. Pero lo conseguimos. Llegamos a poner ambos sistemas en paralelo y con una carga masiva de datos comprobar que el “output” era exactamente el mismo. Igual se nos había escapada alguna excepción, alguna singularidad (empleando jerga matemática), pero el 99,99% parecía estar logrado. De este nuevo enfoque metodológico aprendí mucho.

Adicionalmente incluimos mejoras, sobre todo de interfaz gráfico de usuario, a la hora de introducir datos en el sistema. Por ejemplo incluimos por programa pantallas matriciales de datos que gestionaban las combinaciones de talla y color que eran una de las claves del sistema, todo muy visual, con colorines y avisos.

La puesta en marcha fue todo un éxito (perdonad la inmodestia), sin ningún percance ni error. El usuario se mostró encantado con la nueva aplicación, al manejar un sistema mucho más “user friendly” e intuitivo a la vez que manteniendo las mismas funcionalidades del antiguo. En este sentido la “gestión del cambio” fue mínima y así pudimos percibirlo en las sesiones de formación a usuarios que impartimos. Esta vez sí que dejamos una documentación exhaustiva de todo el sistema, incluyendo manuales de formación y de usuario, base de datos, y todo el diseño. Y todo lo hicimos los de siempre : Mrs. Minutito, Mrs. R., Mr. Charlie Brown y otros dos programadores que no he mencionado hasta ahora (O y N), que trabajaban realmente bien y que encajaban en el equipo de forma envidiable, os lo puedo asegurar. Trabajar con gente así es garantía de éxito y sin ellos no hay mérito alguno. El cliente manifestó su alta satisfacción con el resultado final y fuimos felicitados (y también recompensados en la siguiente subida salarial) por ello.

Pero claro, no todo es siempre excelente, y de este proyecto guardo un mal recuerdo que refleja la inicuidad de algunas personas para las que el fin justifica los medios no importa que mi fin sea una estupidez y los medios supongan un elevado coste para otros, un fin pírrico, en definitiva. Resulta que por parte del cliente, situaron como responsable de este proyecto a un ejemplo perfecto de cómo la vanidad puede confluir con la prepotencia para superar complejos de inferioridad y practicar las filias personales : era rubio, musculoso luciendo camisas prietas con sus iniciales (por supuesto), la nariz podría emplearse para apagar velas perfectamente y casi le tocaba el mentón, también prominente y andaba que, como dicen en mi tierra, le faltaba sólo el caballo y las dos pistolas. Nunca me inspiró confianza, siempre me pareció un tocap....lotas, de mirada desagradable, déspota, reafirmando su autoridad constantemente. Pero como era el cliente, había que torearlo como mejor se podía. Entre otras cosas se vanagloriaba de obligar a los consultores a venir a trabajar los sábados. Para ello fijaba las fechas de los Informes de Progreso en sábado, aduciendo que su agenda estaba muy completa (en la cafetería decía que “si yo tengo que trabajar un sábado, ellos también”, con esa voz suya que parecía que se había tragado un payaso) y ahí estábamos nosotros algunos sábados acudiendo a la reunión para encima tener que mirarle la cara adusta, con mirada de necesitar mucho “bifidus regularis”. Era Mr. Shit.

Pues bien, el incidente que tuve con Mr. Shit fue que se convocó una reunión de proyecto con los usuarios a la cual él quería asistir (para controlarlo todo, no sea que confabularan a su espalda). Cuando ya estaba acordada, me llamó para cambiarla porque le había surgido un cambio de agenda y no podía asistir (y por tanto no podía celebrarse, claro). Así que subí a su mesa (todavía no tenía despacho, qué infamia) y de palabra acordamos la nueva fecha que él podía (milagrosamente no era un sábado) y rehice la convocatoria con todos los usuarios comunicando la nueva fecha y hora. Mi error fue no llamar a un notario para levantar acta con dicho cambio en la que Mr. Shit firmara reconociendo el mismo. Así que llegado el día de la reunión, ante el retraso de Mr. Shit (no íbamos a empezar sin él), voy a buscarlo y me lo encuentro sentado en su mesa mirando al techo. Le comento que llega tarde a la reunión y me dice que no hay ninguna reunión agendada. Le recuerdo que yo mismo la fijé con él en ese mismo sitio y le enseño la convocatoria que entregamos a los usuarios (él incluido). Pero él se limita a decir : “Nunca fijaste conmigo esa fecha. Nunca he recibido esta convocatoria. No puedo asistir. No puede celebrarse. Tendrá que ser otro día. Hablaré con Mr. π para que esto no vuelva a suceder”. El incidente tuvo su importancia porque Mr. Shit se encargó de quejarse amargamente de mi mala planificación a Mr. π además de insinuar que yo estaba mintiendo para tapar mi error. Mr π me pidió lógicamente explicaciones. Como además de mi jefe era mi amigo, tengo claro que me creyó cuando le conté lo que había ocurrido y cuando le dije que claramente estaba mintiendo, por no dar su brazo a torcer, por un olvido por su parte o sencillamente porque le gustaba molestar impertinentemente (comprenderéis que hay otro vocablo más claro para esto, pero evito decirlo, sólo diré que empieza por “j”). Así que no se celebró la reunión, yo quedé mal con los usuarios y encima tuve que agachar la cabeza y guardarme las ganas de esperarlo en el parking y enseñarle la punta de mi zapato (permitidme este desahogo verbal). Mintió, estoy convencido, no se le olvidó todo el cambio y no me lo inventé yo todo. Es más, estoy seguro que si hubiera podido acceder a su agenda lo hubiera visto apuntado, como vi que lo apuntaba el día que fijamos la nueva fecha. A él le hubiera dado igual asistir a la reunión porque ese día continuó mirando el techo. Pero no, su autoridad tenía que verse reflejada, y su sadismo puesto en práctica. Con el tiempo lo ascendieron a un puesto de alta responsabilidad en el cliente, pero le duró poco. Luego me enteré que lo desterraron allende los mares (haciendo honor a su nombre) y tras un tiempo finalmente lo pusieron de patitas en la calle (seguramente por fin supieron con quién trataban o quizá era mayor su ambición que su capacidad). No sé dónde estará ahora, pero me lo imagino dirigiendo un burdel sadomasoquista o retorciendo pescuezos en una granja de pollos. Y no vayáis a pensar que tengo un mal concepto de su persona, no, por favor.

Acabado este módulo, acometimos otros proyectos ya menos destacables que fueron los que tuve que desarrollar teniendo como jefes de equipo a mi cargo a dos catalejos de primer nivel, uno de ellos ya mencionado en una entrada anterior : Mrs. Smiley. El otro tenía un apellido que era en sí toda una profecía de cómo era de bueno como remero (hay ironía en esto, que quede claro). Con Mrs. Smiley tuve que sufrir cómo no aportar poco o casi nada a un proyecto, salvo las sonrisas, puede llegar a ser recompensado injustamente, y eso a pesar de la “caña” que le di para que reaccionara, se pusiera las pilas y empleara las neuronas para “crear”. Pero no lo conseguí, o no daba más de sí o no le daba la gana de darlo. Al final me tuve que “chupar” la revisión de todo su diseño detallado y los cuadernos de carga de lo que estábamos haciendo (un nuevo módulo en el SC sobre aprovisionamiento centralizado de productos de ocio). Y aunque en el “appraisal” que le hice, reflejé lo que había ocurrido y se le dieron toques de atención en ese sentido, sus sonrisas llegaron a prevalecer sin que yo pudiera evitarlo. Un catalejo de primer nivel, incapaz de arremangarse y aportar, incapaz de entender conceptualmente el proyecto, pero, eso sí, con mucha verborrea y mucho comentario oportunista.

El otro catalejo (al que años después tuve como proveedor de servicios cuando yo ya estaba en la parte del cliente, creo que su tarjeta decía algo así como “Director de Desarrollo de Negocio”, aunque yo tenía claro que se dedicaba a “vender motos”) fue alguien a quien no vi venir, me fie y delegué buena parte del diseño del módulo nuevo del SC (en ese momento yo actuaba como jefe de equipo pero con 2 o 3 jefes de equipo por debajo y coordinaba el desarrollo de varios módulos del SC al mismo tiempo, al igual que actuaba Mr. Cid, con lo que os podéis imaginar que el volumen de trabajo que desarrollábamos era ya importante). Cuando llegó el momento de acometer el desarrollo del módulo y le pedí el diseño detallado a Mr. Vendomotos y los cuadernos de carga para empezar la programación, me encontré con un diseño levemente detallado, que pretendía que hablándole de pájaros y flores, el programador fuera capaz de desarrollar el sistema : ni ficheros, ni campos, ni validaciones, ni estructuración técnica, una m...erda con todas sus letras (quito la “i” para que no se me tilde de grosero). Con las fechas comprometidas con el cliente, cuando me encontré con ese panorama, no me quedó más que dar un golpe de estado : hablé con Mr. π y le expuse la situación, encima me calló la bronca por no haber supervisado el trabajo de Mr. Vendomotos (pero me lo habían vendido como un tío “solvente que trabajaba muy bien, que llevaba muy buena carrera y que era muy sólido técnica y funcionalmente”) y tomamos la resolución de sacar del proyecto al figura, meterme yo a saco en el mismo a rehacer todos los diseños y a poner una vela a San Líbrame de los Catalejos bendito para que todo nos saliera bien y en fechas. Convoqué una reunión de urgencia con mi equipo (el de siempre en este cliente) y les dije : “chicos, tenemos un problema”. Una vez más se volcaron con todo su esfuerzo y su buen hacer y me sacaron del apuro, teniendo que ser reasignados a este “marrón” y teniendo que dejar aparcado lo que estaban haciendo en ese momento, que no era esto : con cuadernos de carga medio detallados y dando directrices de palabra, obviando hacer una documentación bien hecha (para luego completarla, una vez puesto en marcha el módulo) y centrándonos mucho en realizar unas buenas pruebas unitarias e integrada que nos aseguraran que lo estábamos haciendo bien, logramos llegar en fechas y poner en marcha el módulo. Creo recordar que no fue un “roll out” tan impecable como otros, que hubo algunas incidencias que supimos resolver casi al momento, pero conseguimos sacarlo adelante. Luego nos dedicamos a completar la documentación, a comentar bien los fuentes, a revisar aspectos menores que habíamos dejado de lado (aspectos gráficos en las pantallas y en los campos y cuestiones casi de estética en el módulo), al tiempo que continuábamos con la labor paralela de dar soporte a usuarios del SC, un SC cada vez más grande y complejo.

Pues bien, de esta situación saqué la lección aprendida de no fiarte de lo que te cuentan de una persona y supervisarla hasta que te genere confianza y te demuestre que es lo que dicen que es. En este caso fui víctima de la rumorología que suele bien acompañar a todo buen catalejo que se precie, me la creí y pensé que era alguien solvente, capaz y que sabía lo que tenía que hacer porque lo había hecho en otros proyectos similares. Y resultó que no, que era un “bluff”, una estela de algo que no tenía consistencia. Un catalejo de pata negra con denominación de origen.

Y así transcurrió otro año más en este cliente. A finales de 1997 ya se comenzó a gestar mi salida del mismo, tal y como comenté en la primera entrada de este cliente, porque Mr. Cr. me tenía preparado un nuevo cliente y un nuevo proyecto que relataré en próximas entradas (mi quinto cliente, y, aunque dicen que no hay quinto malo, en este caso encontré el contraejemplo perfecto, pero eso lo contaré más adelante). Así que poco a poco fui cediendo mis poderes a Mr. Cid, que era el designado para hacerse cargo de todo el SC (él ya tenía sus poderes y los amplió al recibir los míos) con todo el equipo asignado al mismo a su cargo y con todos los proyectos bajo su rienda.

Y yo abandoné este cliente, tras casi tres años de trabajo duro pero muy enriquecedor, didáctico y representativo de la labor de un consultor de sistemas. En breve me harían Gerente si todo iba sobre lo previsto, yo lo sabía y me apetecía probar. Lo que no sabía es que el precio que tuve que dar a cambio era muy alto, mucho más que los más de 60 puntos de subida salarial que me darían al promocionar a gerente, mucho más que disponer de portátil, teléfono móvil, mi nombre en una tarjeta de cartón con el logo de AC, una mesa siempre disponible en la Torre Picasso, una porción de secretaria (los gerentes nuevos compartían secretaria) y pertenecer al “Executive Team” de la firma, con sueldo variable añadido. Pero eso no ocurriría hasta septiembre de 1998, quedaban todavía nueve meses, los cuales transcurrieron en mi quinto cliente : los malteses.

25 - Mi cuarto cliente : los mercaderes no venecianos (VI)

Así que, manos y traje a la obra, nos pusimos en marcha para implantar el nuevo ML. Como ya comenté, el proyecto tenía dos fases (como casi todos) :

Fase de diseño

La fase de diseño del ML la realizamos en las oficinas centrales, porque todavía no se había habilitado la nueva sede de la dirección logística (estaban en ello). Los tres senior partimos de una hoja en blanco (lo que me ha hecho recordar una frase muy americana en la documentación de la firma : “this page intentionally left blank”, que supongo que algunos recordarán ) para, junto a Mr. Diego, diseñar el nuevo ML. Recuerdo que uno de nuestros documentos de diseño que más empleamos y discutimos eran las famosas “bolas y cajas” (diagramas entidad-función del Method/1), que planteaban el boceto de todo el modelo y de donde derivábamos los procedimientos, la organización y los requerimientos de sistemas.

El proceso logístico consistiría en : las tiendas diariamente harían sus necesidades (expresión con cierta sorna que nos dio entrada a chascarrillos que amenizaban las largas jornadas y que hace referencia a la generación de necesidades de producto en la tienda en base a su previsión de ventas y su stock disponible) y las enviarían a Logística. Aquí las integrarían para preparar las entregas, bien desde plataformas en camiones multitienda y multirreferencia o bien entregas directas desde proveedor. Luego las tiendas recibirían la mercancía solicitada. Así de fácil. Adicionalmente, claro, la gestión de stocks en tienda y en plataformas, el reaprovisionamiento de plataformas mediante pedidos a proveedores y todos los intercambios de información entre tiendas, plataformas, proveedores y operadores logísticos (agentes involucrados).

Fase de implantación

Para implantar el modelo, además de poner en marcha las plataformas definidas en el diseño de la red física, operadas por los operadores logísticos con los que se había contratado el servicio, y además de poner en marcha la organización, los procedimientos y la normativa asociada, se implantaron los sistemas de información necesarios para el ML. Por una parte, un pequeño desarrollo en el sistema de las tiendas (fue mi primera incursión en este sistema, para la que conté con el conocimiento y el apoyo de Mr. π además de buena parte del equipo de tiendas) para generar las necesidades y enviarlas a Logística así como para realizar la recepción de mercancía junto con los informes y consultas asociados a todo ello. Por otra parte un módulo adicional en el SC que en un principio se intentó que cubriera todo el resto de la funcionalidad requerida, pero que al final se quedó reducido a cubrir el mantenimiento de datos del ML dado que el grueso de las operaciones (recepción de pedidos de tienda, preparación de entregas, gestión de rutas, reaprovisionamiento de plataformas, gestión de stocks de plataformas, previsión de ventas, gestión física del almacén, inventarios, etc.) no se pudo incluir en el SC por decisión (yo diría que política) del cliente.

Y aquí es donde hace su aparición el TILAS que ya mencioné en algún capítulo anterior. Y me explico.

Como suele ocurrir en consultoría, para dar una solución suelen concurrir varias ofertas. Nosotros diseñamos el ML, pero para implantarlo, el cliente barajó varias posibilidades contactando con otras empresas de servicios (la competencia, vamos). Una de ellas ofreció un paquete propio (cuyo nombre no digo pero que a buen entendedor..., aunque llamaré solución T) para gestionar toda la operativa de las plataformas. Nosotros, por nuestra parte, ofertamos como solución desarrollar a medida un módulo que se integrara en el SC con la alternativa de integrar en el SC un paquete del mercado muy conocido para las funciones específicas de previsiones de ventas y reaprovisionamiento, etc... (es absurdo desarrollar a medida funciones específicas que ya cubren soluciones en el mercado). Y ahí surgió la enconada batalla. Hicimos una revisión de la solución que proponía la competencia y concluimos que era una solución insuficiente para cubrir las funcionalidades además de ser técnicamente un poco antediluviana (además de que el interfaz era de todo menos GUI, como los "dumb terminal" de los IBM de los bancos en los años 80). Avisamos al cliente de problemas de estabilidad, de coherencia, de lagunas funcionales (entre otras cosas no tenían funcionalidades para la previsión de demanda, con lo que habría que realizar dicha previsión a mano e introducirla en T para lanzar el reaprovisionamiento de las plataformas), .... Todo podría indicar que al ser parte interesada, nuestras conclusiones eran parciales, pero no lo eran (no en su mayoría, eso lo aseguro). Al final, y ayudado seguramente por algún movimiento político fuera de horario de oficina, el cliente optó por la solución de la competencia (hay que tener en cuenta también que ya la tenían implantada en otras áreas funcionales de la empresa, por lo que decir ahora que no era de alguna forma poner en evidencia a quien en su momento dio luz verde a implantar este paquete).

Así que la implantación del ML pasaba por integrar la solución T en el desarrollo de sistemas, decisión que estuvo a punto de hacer naufragar la puesta en marcha del ML.

Por tanto, cada empresa hizo su trabajo y desarrolló y preparó sus sistemas. Por supuesto tuvimos que desarrollar en común unas interfases para intercambio de datos entre el SC, el sistema de tiendas y la solución T (pedidos de las tiendas, datos logísticos de los artículos, datos de los operadores logísticos, ...), para lo cual mantuvimos unas cuantas reuniones con nuestra competencia.

Cuando ya tuvimos todos los desarrollos realizados y probados, intentamos realizar una prueba integrada de todo el proceso logístico incluyendo en la misma la solución T. Pero los desarrolladores de la solución T incurrieron en retrasos que condicionaron los plazos previstos para la puesta en marcha del proceso (quiero recordar que, aunque la solución T la aportaba la competencia, nosotros éramos los responsables del “project management” global y por tanto los encargados de poner las pilas a los que se retrasaran). Y así tuvimos que librar duras batallas orales y escritas (las imprescindibles actas de reunión) para asumir responsabilidades y hacer que fueran asumidas por los demás. Hasta tal punto llegó la situación, que nos llegamos a plantear retrasar un mes la fecha prevista para la puesta en marcha, habida cuenta de los retrasos en los que se había incurrido y las pocas horas dedicadas a realizar una prueba integrada seria y solvente del nuevo ML. Pero finalmente, en una reunión tripartita entre el cliente, la competencia y nosotros, se concluyó que la fecha de arranque no se movía, avalando la competencia que su solución T estaba preparada y que ellos, por su cuenta, habían realizado la prueba integrada del proceso empleando datos de prueba masivos que les facilitamos nosotros a través de las interfases ya desarrolladas. Ellos daban su visto bueno a su solución, nosotros también a la nuestra. Pero la realidad era que no se había realizado una prueba integrada global de todos los procesos y todos los sistemas, sino que cada parte había hecho la suya y nos fiábamos los unos de los otros y el cliente nos dio su autorización para, con ese planteamiento, arrancar en las fechas previstas.

Y llegó el día del arranque. El día anterior anduvimos hasta bien tarde lanzando los procesos de conversión de datos y alimentación de los nuevos ficheros de las bases de datos para iniciar la operativa del ML, tanto en las tiendas (se eligió un piloto, creo recordar que con 3 tiendas, para iniciar el arranque, para posteriormente irlo extendiendo al resto) como en el SC. Creo que era lunes y tras un domingo agotador de conversión estábamos dispuestos a inaugurar ese barco llamado ML.

En cada tienda del piloto se ubicó a un responsable de nosotros (yo estaba en una). En la Central a cargo del SC y para verificar la recepción de las necesidades de cada tienda se quedó Mr. Cid junto con los responsables de la solución T, la cual tenía que recibir esas necesidades, procesarlas y generar los pedidos, la carga de los camiones y las rutas de reparto (información ésta que se enviaría al operador logístico para realizar la gestión física de la mercancía en la plataforma).

Las semanas previas al arranque, Mr. Cid tuvo la genial y acertadísima idea de desarrollar en Excel un sucedáneo de la solución T, una solución más o menos automatizada que se alimentara de los datos que enviaban las tiendas y lanzara un proceso que generara las entregas, las cargas de los camiones y hasta casi las rutas de entrega. (No recuerdo si comenté que Mr. Cid era un genio del Excel, el Excelman pata negra, que manejaba las tablas dinámicas como quien come pipas, VLOOKUP, etc...). A dicha solución, que era nuestro as bajo la manga y de cuya existencia hicimos partícipe a Mr. Diego, la solución de contingencia, la solución de “utilizar en caso de”, la llamamos TILAS.

Pues bien, el día D iniciamos el proceso en cada tienda, generando las necesidades y enviándolas a la Central, donde la solución T estaba dispuesta para recibirlas, integrarles y procesarlas. Cuando las necesidades intentaron subir a la solución T, contaba Mr. Cid que apareció un “Warning”, un “Total error”, un........ vamos, que la cara que se les puso a los responsables de la solución T ya lo decía todo. Llamé por teléfono a Mr. Cid para ver si habían recibido bien las necesidades y recuerdo sus palabras : “Yuki, recibir las hemos recibido, pero al subirlas, T ha hecho aguas por todos sitios y aquí estamos, TILAS en mano, achicando agua”. Así que Mr. Cid puso en funcionamiento su TILAS mientras la competencia apagaba el fuego en la solución T y, con un par de horas de retraso, finalmente se envió la información al operador logístico para realizar las entregas en las tiendas. Todo funcionó correctamente, con cierta necesidad de procesamiento manual por el uso del TILAS, con cierto retraso, pero al menos funcionó. Y no pretendo colgarme ninguna medalla (si acaso, que se la cuelgue Mr. Cid, el gestor de la solución de contingencia), pero así fue el arranque, así el fracaso inicial de la solución T (ya lo habíamos avisado) y así la aportación de “valor añadido” por parte de nosotros para sacar adelante la situación. Tal cual, no me invento nada.

Menuda bronca les cayó a nuestros competidores. Se dedicaron intensivamente a solucionar T, a probarlo en condiciones y a garantizar que funcionaba. Mientras tanto el TILAS se tuvo en uso todos los días durante unas semanas hasta que la solución T fue reparada. Creo recordar que hasta Mr. Cid sacó versiones mejoradas (TILAS 2.0 y demás) y que siempre se tuvo esa hojita de Excel guardada en el cajón por si acaso algún día volvía a fallar la solución T (creo que hasta se llegó a dar formación a un usuario de cómo utilizar el TILAS en caso de emergencia).

Y así transcurrió todo, a lo largo de nueve meses de proyecto, toda una gestación con sus pequeños sustos. Aunque el neonato nació con problemas, al final pudimos encauzarlo. El ML comenzó a funcionar, ajustándose poco a poco (“ajuste fino” que se dice), extendiéndose por fases a otras tiendas. La solución T terminó funcionando, con las limitaciones funcionales que comenté (las plataformas se reaprovisionaban a mano, tirando de listados) y dando algún susto de vez en cuando. Las tiendas, al principio reacias al ML, terminaron reconociendo que les aportaba beneficios : reducción de los tiempos de entrega, mejora del margen, reducción de las roturas de stock, reducción de los errores de entrega (en cantidad y en producto). Con ello, por tanto, los niveles de stock en tienda (dinero inmovilizado mientras no se venda) se redujeron también, y con ello también el margen. Es decir, que fueron felices y comieron ML, con alguna TILA de vez en cuando.

Así que poco a poco pasamos a extender el ML al resto del país, a revisar el modelo, a incorporar los nuevos desarrollos en el SC al circuito de mantenimiento y atención al usuario. (No lo he comentado, para ser más breve, pero fueron Mrs. Minutito y Mrs. R las que, una vez más, realizaron los desarrollos en el SC junto con algunos programadores más).

Para finalizar, una pequeña anécdota que me ocurrió, de ésas que no se te olvidan nunca más : estábamos (Mr. Cr., Mr. Cid y yo) en una reunión con Mr. Diego, ya en la nueva sede de la dirección logística, discutiendo un tema de parametrización del sistema (algo sobre las diferentes unidades de medida de los productos : de compra, de venta, de almacenaje, de transporte, etc.) así como sobre los factores de conversión de unas a otras, para poder calcular los costes de manipulación y almacenaje que el operador logístico facturaba a Mr. Diego. En una intervención mía, comentaba con un ejemplo cómo iba a funcionar lo que discutíamos y dije algo que no recuerdo en concreto pero que voy a recrear de forma fácil como : “si llegan 10 palets, el sistema calcula 250 cajas, que llegan 2 palets, pues 50 cajas, que llegan 20, pues 500 cajas, que llegan 3 pues 75 pajas”. (No, no es un error, dije “pajas”). Mr. Diego me miró sorprendido y dijo algo así como “¿tantas?”. Yo pensé “trágame-tierra”. Mr. Cid no sabía cómo contener la risa y finalmente Mr. Cr. soltó un comentario para distendir (“pero bueno, Yuki, qué has comido hoy, que estamos hablando de trabajo”). Tanto palet y tanta caja, que al final enlacé la primera sílaba de la primera palabra con la última de la segunda y formé el polémico vocablo. Menos mal que los que estábamos reunidos nos conocíamos desde hace ya mucho tiempo y el ambiente siempre era distendido en las reuniones. Si esto me pasa delante del consejero delegado, igual hoy no estaría escribiendo estas líneas.

24 - Mi cuarto cliente : los mercaderes no venecianos (V)

Tras lo anterior, continuamos con una nueva fase en el SC, al tiempo que manteníamos y dábamos soporte al usuario en los módulos ya en funcionamiento.

Esta fase del SC fue la más importante e interesante por su contenido y por su desarrollo e implantación. Transcurrió entre marzo de 1996 hasta mediados de mayo del mismo año para diseñar el modelo, y desde junio hasta finales de noviembre del mismo año para implantarlo y ponerlo en marcha. Yo, todo un senior con más de 4 años de experiencia, sólidamente integrado en la “firma” y dispuesto a arrostrar los peor que se me venía encima a partir de ahora. Eso sí, yo seguía dispuesto a trabajar 10-12 horas diarias por un 80% más de sueldo que por el que me contrataron y el traje ya lo podía lanzar al aire y me caía colocadito por las mañanas.

La idea era continuar con el proceso centralizador. Ahora se centralizaba el aprovisionamiento de las tiendas. Ya no es cada tienda la que pide a los proveedores y éstos sirven en cada una de ellas. Ahora es la Central la que pide a los proveedores para todas las tiendas y los proveedores sirven la mercancía en una serie de plataformas logísticas dispersas por el país. Desde las plataformas se servirá a las tiendas en base a las necesidades de cada una de ellas, con la excepción de entregas directas de proveedor a tienda para productos de alta rotación cuyo pedido suponga camiones completos. La gestión de las plataformas se realizaría a través de un operador logístico seleccionado y contratado a tal efecto, pudiendo ser varios operadores según la región y plataformas que gestionen.

Este modelo de aprovisionamiento centralizado no supuso un invento nuevo, era algo ya habitual, pero sí tuvo efectos importantes en el negocio de los mercaderes no venecianos :

1.Por una parte, en los proveedores : como ahora los pedidos a cada proveedor son de mayor volumen (se pide para reaprovisionar las plataformas) y además el proveedor entrega en las plataformas y no en cada una de las tiendas, es decir entrega unos pocos camiones completos en vez de muchos medios camiones, se generan ahorros de transporte y de gestión logística de entregas en los proveedores. Este ahorro económico que reciben los proveedores no se lo pueden quedar todo ellos, claro, y surge ahí el “descuento logístico”, es decir, como con mi nuevo modelo de logística te genero ahorros, has de darme parte de ellos si quieres trabajar conmigo. Otra vuelta de tuerca más o menos argumentada. Esto supone que se inicia una ronda de negociación del descuento logístico con cada proveedor para cada una de sus referencias, con lo que los precios de compra de la plataforma son menores que los precios a los que compraban las tiendas ( que, recordemos, ya se negociaban también centralizadamente).

2.- Por otra, en las tiendas : éstas ya no compran a los proveedores sino que “compran” (piden) a las plataformas y a un precio menor que al que compraban antes (precio de cesión). Por tanto, a efectos de su rentabilidad por tienda, el margen mejora. Y aquí tienen la opción de mantener el margen reduciendo el precio de venta al público para ser más competitivos (los precios de venta al público no están centralizados..... todavía, sino que los establece cada tienda). Si esto se aplica así, supone un beneficio añadido al consumidor, que compra más barato porque la central reduce sus precios de compra, vamos ECR en estado puro, aunque algo forzado y poco cooperativo.

Poner en marcha este nuevo modelo logístico, en adelante ML, fue un proyecto estratégico, difícil y muy ilustrativo del buen hacer del consultor. Por una parte había que diseñar la red física de distribución y plataformas. Por otra parte había que desarrollar los procedimientos y normas de operación y el modelo organizativo de las mismas para implantar los nuevos flujos de aprovisionamiento de tiendas. Y por otra, cómo no, desarrollar los sistemas de información necesarios para dar soporte a todos estos nuevos procesos de negocio e integrarlos con el mapa de sistemas ya existente.

Para todo ellos se incorporó un equipo de trabajo para acometer el diseño del nuevo modelo : 3 senior, 1 para el diseño físico de la red y 2 para los procedimientos y para los sistemas (¿adivináis quiénes eran los de sistemas?). Por encima de ellos, una vez más, una gerencia bicéfala : 1 gerente especialista en logística (Mr. Gus) y 1 gerente especialista en .... bueno el otro era Mr. Cr. Sí, como ya anuncié en otro capítulo, yo volvía a estar acogido bajo el ala gerencial y ejecutiva de Mr. Cr. Mr. π estaba cerca y disponible (menos mal) pero sería Mr. Cr. quien dirigiría este proyecto con sus 2 senior de sistemas (Mr. Cid y yo), mientras que Mr. Gus dirigiría el trabajo del senior de diseño de la red de plataformas.

Aquí fue donde hizo su aparición Mr. Cid por primera vez en este cliente (y donde me reencontré con mi coetáneo de incorporación a la firma).

Como ya podéis imaginar, la gerencia bicéfala nos dio más de un quebradero de cabeza, sobre todo por la nefasta relación personal y profesional que existía entre los dos gerentes. La situación llegó hasta el punto de que se nos enfrentó a los dos senior con el otro senior con órdenes concretas de no compartir cierta información (contenido de informes de progreso, entre otra). Absurdo, anticolaboracionista, todo lo contrario al trabajo en equipo, pero real. Y todo porque no me caes bien y no quiero que te cuelgues una medalla que lleva mi nombre. Tal cual. Fue de las contadas ocasiones donde fui testigo de competitividad entre compañeros. Pero, como en otras situaciones similares, los tres senior habíamos hecho muy buenas migas y nos compenetrábamos bien, compartiendo todo lo que fuera necesario y pasando de directrices absurdas, centrándonos en lo importante : sacar adelante el proyecto y pasarlo lo mejor posible.

Aquí fue también donde Mr. Cr. se ganó el apelativo que da origen a lo de “Cr”, pues era característico que de vez en cuando se reuniera con sus dos senior para ver cómo iba el proyecto. Nos sentaba (por separado o juntos, según los casos) en una sala y programa de trabajo en ristre pasaba a repasar una por una las fechas fin de cada tarea. Si le hablábamos de algún retraso, ya podíamos justificarlo bien, y a la más mínima sacaba su brazo derecho que, convenientemente arqueado, dejaba caer sobre la mesa repetidas veces al ritmo de la frase típica “te lo dije-o-no-te-lo-dije”. Con el brazo izquierdo, igualmente arqueado pero simétricamente en relación con el otro, sostenía el programa de trabajo. Ese brazo izquierdo no lo movía.

Pero no todas las reuniones eran de seguimiento. También aportaba sus conocimientos al proyecto. Por ejemplo, en una ocasión abordamos el tema de qué modelo predictivo emplear para que el sistema generara una previsión de ventas que fuera la base para realizar los pedidos. Y Mr. Cr lo dejó muy claro : se fija un stock mínimo por producto y cuando se alcance ese mínimo el sistema genera una propuesta de pedido ( es el punto de pedido ) igual al lote de pedido. ¡Uff, menos mal!, de no ser por esa clase magistral nunca hubiéramos sacado adelante el proyecto. ¿Y cómo se calcula el lote de producto?, le preguntamos. Habla con el otro gerente, fue su respuesta. Nosotros ya teníamos en mente plantear un modelo de previsión de alisado exponencial, que, por supuesto, obviamos entrar a comentar con Mr. Cr, vista la aportación que nos había hecho. Y es que a la hora del puro “management” Mr. Cr era (y es) un "crack", gestor de los mejores de cara al cumplimiento de fechas, plazos, rentabilidades y entrega de producto final previsto. Pero el contenido del proyecto, eso ya que lo pensara otro (por ejemplo, Mr. π, que para estas cosas ponía todas sus neuronas en marcha y te dejaba flipando a veces, perdón por el término adolescente).

Por parte del cliente, este proyecto se soportó con la creación de una nueva dirección logística que pretendía funcionar como una empresa autónoma, ubicada en un lugar distinto de la Central y gestionar su propia cuenta de resultados asociada a la actividad de prestar servicios logísticos a la Central. Al frente de la nueva dirección me encontré con (casualidades del destino) el que fue mi primer senior, allá por el año 1992, aquél que me enseño a poner “X” en Lotus y del que ya hablé en el capítulo 11. Ahí estaba él, bonachón, siempre de buen humor, analítico y, cómo no, con un perfil de ex–consultor de AC que nos facilitó la vida en este proyecto sin duda alguna. Los que, siendo todavía consultores, hayan trabajado con ex–consultores como clientes (especialmente si eran de su misma compañía) habrán comprobado las ventajas que supone esto (y también los inconvenientes) : líneas de pensamiento similares, procesos mentales de análisis y obtención de resultados similares, hábitos parecidos, metodología en común, en definitiva, estar hechos de la misma madera. Eso cuenta mucho a la hora de trabajar con tu cliente. Como inconveniente, que no valen las milongas, que te pilla si intentas vacilarle, porque reconoce en tus acciones las que él podría haber hecho si continuara como consultor. Le llamaré Mr. Diego, por razones que luego se darán a entender y que Mr. Cid, si lee esto, recordará al instante. Bajo Mr. Diego, un jefe contable de tienda (cuya presencia todavía no termino de entender en este proyecto, al menos no en ese momento) y su auxiliar acólito; un jefe de almacén que llevaría el control de las plataformas; y un comercial que se encargaría de la negociación con proveedores y con operadores logísticos así como de la relación con tiendas.

Junto a ellos, nosotros, los consultores, dispuestos a todo.

To be continued.

23 - Mi cuarto cliente : los mercaderes no venecianos (IV)

A finales de agosto de 1995, con la mitad del equipo luciendo el michelín en la playa y la otra mitad al pie del cañón en el cliente, se incorporó al mismo un pitufo nuevo, formal, muy prudente y con muchas ganas de aprender (no sabía que acababa de dejar una mina para meterse en otra mucho peor). Conforme llegó, según recuerdo, Mr. π lo sentó a mi lado y le tuve un par de horas escuchando toda la sabiduría que yo tenía del cliente : quién era, quién era quién en ese cliente, estructura de la empresa, proyectos que estábamos desarrollando, quiénes formaban parte de dichos proyectos y, muy importante, cuestiones logísticas : dónde se come, dónde está la máquina de café, dónde la fotocopiadora y el fax, dónde se aparca el coche, los horarios habituales de trabajo (“overtime” incluido), y tantas más. Al final no se quedó con nosotros, sino que lo asignaron a la parte de tiendas para ser el futuro responsable del CAU. De haberse quedado en el equipo del SC, seguro que hubiera hecho un buen trabajo. (Quizá no ha quedado claro, en el cliente los consultores se agrupaban en dos : los del SC y los del sistema de las tiendas. Eso no quiere decir que no estuviéramos juntos en los momentos de ocio, como ir a comer o a tomar un café, con lo cual nos tratábamos todos por igual).

Recientemente he comentado con este pitufo (pitufo que supo promocionar y aguantar unos cuantos años en AC hasta que se pasó a la parte del cliente , en la que ahora disfruta de más calidad de vida, a pesar de que en ocasiones le somenten a tentaciones para volver ) nuestros recuerdos de este cliente y a continuación transcribo (con mínimos retoques para asegurar anonimatos) algunos de los que me ha incluido en un correo que hemos intercambiado : “Las mesas estaban en círculo (en cuadrado, para ser exactos) y creo que los cables colgaban del techo. Si algo caía por la parte de atrás de la mesa era mejor darlo por perdido. El suelo era de moqueta en toda la central y los chispazos al tocar la puerta o la máquina del café, impresionantes......Bastante después, empezaron las obras y nos relegaron a una minisala acristalada donde tenías que colocar el teclado sobre el monitor si querías escribir en el cuaderno. Esa sala se llenaba de humo y hacía imposible ver el teclado a las 8-9 de la noche, gracias a lo mucho que fumaba Mrs. Minutito y pese a las quejas anti-tabaco de un senior andaluz cuyo nombre no recuerdo ( pues yo te lo recuerdo, Yuki, se llamaba Yuki )..... Mi primer recuerdo imborrable del proyecto y de Andersen Consulting en general fue una visita del socio a Mr. Cr. dos días despues de llegar yo al proyecto. A las 8 (20h) se fue la gente de Coritel, pero R.M. (otro senior pero en la parte tiendas) y tú seguíais allí. De hecho, R.M. estuvo desde las 7:30 hasta bastante más de las 9:00 dando formato a una tabla de Excel de apenas 8 columnas y 3-4 filas (podía ser el calendario de un mes) para hacer tiempo y no irse antes que Mr.π, que a su vez se fue 15 minutos después que Mr.Cr., que esperó 30 minutos a irse después de salir el socio. Lo de R.M. jugando con negritas, cursivas, ariales, bordes simples y dobles durante 2 horas fue de esas cosas "que no tienen precio". Yo, mientras, alternaba leer manuales con leer código (que no entendía) y hacer dir y cls en directorios de servidores en entorno MSDOS”. Completó esta escena con un comentario en el capítulo anterior : " ...así hasta llenar más de dos horas de puro “overtime” cultural. Mientras, yo leía manuales y código que no entendía. Sólo sabía que no me podía ir antes que mi senior”.

(Me ha gustado comprobar que este comentario coincide con la descripción que hacía de lo que es “overtime” en uno de los glosarios que incluyo en este blog : “Se habla de overtime cultural cuando se realiza no por necesidad del proyecto sino porque no está bien visto que salgas de trabajar antes que tu jefe. Como el jefe también lo aplica y no sale antes que el suyo y así sucesivamente, pues basta con que el socio del proyecto aparezca a las 19h en el cliente, para que todo el mundo acabe saliendo a partir del momento en que el socio se vaya, en cadena y uno a uno, cumpliendo la jerarquía, de forma que el pitufo acaba en su casa a las 11.45h, donde le espera una cena fría y una novia o madre bastante mosqueadas”).

No recuerdo bien si fue en esta fase o en una posterior cuando se acometió un cambio drástico en toda la arquitectura técnica del sistema : la base de datos (pasamos a una base de datos relacional de las buenas, con control de bloqueo de registro, lenguaje 4GL incorporado para definir “triggers”, etc.), la máquina (pasamos a una con mucha memoria y mucho disco para poder gestionar todas las transacciones que iba a realizar el SC) y los lenguajes de programación (comenzamos a desarrollar los programas tipo “batch” –informes, procesos de cálculo, procedimientos almacenados, etc...- en C, con lo que se incorporaron nuevos programadores con este perfil). Para definir esta nueva arquitectura técnica se incorporaron dos consultores de tecnología de AC de la oficina de Barcelona. Al principio les costó integrarse, pero al final eran dos más en la familia creciente de consultores en ese cliente. Este cambio de arquitectura fue prolijo y complicado, siendo necesario realizar muchos ajustes multifactoriales para conseguir el "tuning" perfecto de la máquina y del entorno. Son de esas cosas de tecnología profunda que sólo unos pocos son capaces de comprender. Allí estaban los expertos para acometer los ajustes. Yo de esa parte me limité a saber cómo iban las cosas, aprender a nivel básico algunos conceptos nuevos para mí y comprobar como desarrollador y usuario del sistema que todo tenía buena pinta, los rendimientos eran adecuados y no había problemas cuando el sistema "corría" sobre el nuevo entorno. En cuanto a dimensionamiento de discos duros, mirroring, procesamiento paralelo, asignación de memoria, definición de particiones, ODBC de acceso a la base de datos, arranques en frío y en caliente, y bla bla bla, todo era un mundo extraño y lejano al que casi me daba miedo acercarme, así que hice sólo las incursiones justas y necesarias.

Poco a poco, conforme íbamos desarrollando todas estas funcionalidades, se fueron incorporando nuevos programadores al proyecto. A muchos no les recuerdo bien. Otros venían y al poco tiempo abandonaban el proyecto. Otros permanecieron mucho tiempo en él. Todo ello en función de las necesidades del mismo y de lo bien que actuaban como profesionales trabajando en equipo, lógicamente. De algunos ya hablaré más adelante, pero conocí muchos perfiles distintos de programador : programador-terrorista, programador-sindicalista, programador-todoterreno, programador-suspicaz, programador-torpe, programador-gerente, etc... Recuerdo, por ejemplo, con mucho agrado a Mr. Beard, todoterreno donde los haya, que igual te manejaba el clipper, que el Visual Basic, que el C, y además en cualquier sistema operativo, en cualquier base de datos, lo que hiciera falta, más madera, más madera (como diría Groucho). Cuando íbamos justos de tiempo en alguna entrega o era necesario probar bien un programa complicado, acudir a alguien como Mr. Beard era garantía de éxito. No sólo por su capacidad técnica y por la fiabilidad de su trabajo, sino también por su compromiso y, sobre todo, por ser muy buena persona, alguien de cuya opinión te puedes fiar, porque no tiene segundas intenciones, ni insidias, ni truculencias.

La otra cara de la moneda, por ejemplo, era G, programador-terrorista : indidioso, cargado de veneno, reacio a dedicar un minuto más a su trabajo, retorcido, oscuro, casi nos organizó una huelga a base de enredar y liar entre los otros. Entre medias, S, que no se enteró de nada del proyecto y cuya sangre poseía una densidad superior a la del agua del Mar Muerto.

Fueron muchos, pasaron muchos, algunos se quedaron mucho tiempo, otros apenas un par de meses. Tanta gente, que a duras penas recuerdo sus nombres, sí sus caras, sus aptitudes y sus actitudes. De entre todos ellos, también quiero destacar a Charlie Brown, con su cara de niño, siempre sonriendo, siempre con una actitud positiva, comprometido, girando el bolígrafo entre dos dedos con tanta destreza como manejaba la administración de la base de datos y la programación que se le asignaba mientras se mordía el labio en actitud pensativa, a la vez que con un enorme espíritu creativo y crítico aportaba mejoras al diseño o proponía soluciones.

Con lo que he contado hasta ahora, el SC ya es un niño que ha dejado de gatear y andurrea por casa con más miedo que vergüenza por parte de los padres. Ya gestionamos el surtido en la Central y establecemos los precios de compra. Lo siguiente será centralizar el aprovisionamiento. No se vayan todavía, aún hay más.

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.