28 - Mi quinto cliente : los malteses (II)

Cuando finalmente acabamos el CRP y ya teníamos una idea más o menos clara de qué quería el cliente hacer con él (lo cual me recuerda a los programas de “Cambio radical”) pasamos a la segunda fase : la implantación de Omega. El CRP en realidad había sustituido la fase canónica de diseño técnico y diseño funcional, previa a toda implantación. Ahora ya teníamos un conocimiento previo de Omega, una lista de todas las modificaciones, una lista de todos los nuevos desarrollos y una lista de las nuevas necesidades técnicas en temas de máquina. Lo que no teníamos era una vela puesta al santo de los consultores (que no sé cuál es, por cierto).

Y aquí vino un momento clave en el desarrollo de este proyecto : estimar la instalación. Y a ello me puse cuando Mr. Cr. Me lo pidió. Con mi mayor pericia en dirección de proyectos preparé mi hojita de cálculo y porcentaje arriba, porcentaje abajo, tarea de más tarea de menos, nivel de dificultad arriba y abajo, llegué a una conclusión en horas, número que ahora no recuerdo y que, a efectos de esta historia, me invento : 20.000 horas.

Cuando Mr. Cr. recibió este número, rápidamente torció el gesto. Él, que para esto es un “crack”, ya había sopesado las horas y veía que no iba a poder vender ese proyecto a las tarifas de AC. “Vamos a repasar tu estimación, que seguro que te has curado en salud”. Y ahí empezó el recorte : esta tarea no la hacemos (o lo que es lo mismo, se hace porque hay que hacerla pero a cuenta de “overtime”), estos porcentajes los bajamos, esta partida de contingencia la eliminamos porque Omega es el no-va-más y estamos respaldados por el fabricante y sus mejores expertos, esta parte de formación se la damos al cliente, ..... Total, que el 20% de las horas desaparecieron. De nada sirvió mostrar mi desacuerdo.

Con esas horas reducidas, Mr. Cr. se encerró con el cliente para negociar la venta de la implantación. Y ahora vino la segunda vuelta de tuerca. Cuando salió de la reunión me dijo : “Yuki, lo tenemos que hacer por este dinero”. Yo le di horas, él me las redujo, negoció y me devuelve pesetas finales. Ahora paso las pesetas a horas y me encuentro con que las horas son todavía menos, algo así como un 30% menos de las inicialmente estimadas.

Recuerdo protestar amargamente, poner en duda nuestra capacidad para hacer el proyecto con ese dinero (ese dinero representaba menos equipo, menos horas, dado que había que mantener la rentabilidad del proyecto y teniendo en cuenta que la tarifas de AC eran muy altas), quejarme, tratar de hacerle ver que era poco menos que imposible, que nos enfrentábamos a un gran desconocido, que no teníamos capacidad de respuesta si las cosas se torcían....... Me faltó arrodillarme e implorar. “Esto es lo que hay” fue la única explicación.

Resultado final : menos horas, menos equipo, más incertidumbre, a igualdad de plazos, a igualdad de inestabilidad del paquete, ceteris paribus, como dicen los economistas. Con este panorama la única variable que éramos capaces de manejar era una : el overtime, el cual también tiene su límite (24 horas diarias).

Así que iniciamos la implantación : incorporamos al equipo nueva gente, programadores y analistas que iban a ser necesarios ( llegamos a ser en torno a 30 personas por parte de AC). Por parte del fabricante nos asignaron dos consultores funcionales de preventa que supuestamente conocían profundamente el producto y un consultor técnico expertísimo en las entrañas de Omega. Contábamos con el apoyo pleno del fabricante para recibir nuestras incidencias con prioridad máxima (en su centro de excelencia o Helpdesk situado fuera de España y con el que el contacto era siempre telefónico y en inglés).

No voy a relatar la tortura de más de 12 meses de implantación que sufrimos, conforme fueron saliendo uno a uno los cadáveres que Omega tenía guardados en el armario, entre otros : la herramienta de desarrollo que nos vendieron como de última generación, muy intuitiva y de fácil aprendizaje era en realidad un arma letal muy poco documentada y con un elevado nivel de “isostasia”; funcionalidades básicas del paquete como el cálculo del IVA en los procesos de facturación presentaban errores que requerían un parche inmediato por parte del fabricante; el sistema de resolución de incidencias con el fabricante se mostró muy poco ágil e insolvente; la capacitación técnica de los expertos del fabricante que iban a asesorarnos quedó por debajo de lo requerido para un Omega que estaba siendo alterado a requerimiento de los usuarios; etc, etc, etc.

Visto bajo la perspectiva del tiempo, fuimos los conejillos de indias para el fabricante de Omega. Necesitaban poner en el mercado cuanto antes a Omega, necesitaban contar con algunas referencias de implantaciones de éxito, y ahí estábamos nosotros. Pero era demasiado pronto, lo que nos dieron era una versión beta para que la probáramos a base de pelearnos con ella para ir reportándoles errores (algunos gravísimos). A veces costaba creer que alguien del fabricante hubiera probado mínimamente el paquete antes de ponerlo en el mercado con unas tarifas de licencia tan caras. Llegamos a generar tal cataclismo a base de incidencias, errores y cagadas varias, que a nivel mundial se movilizaron expertos (creo recordar que vino un indio durante un par de semanas a achicar agua y que era uno de los mayores expertos del producto y que se fue sin habernos resuelto casi nada huyendo de la quema) y los grandes mandamases a nivel mundial tuvieron sobre su mesa un proyecto que para ellos era un grano en el culo. En definitiva, nosotros probamos y depuramos fehacientemente a Omega (éramos la única instalación en curso en ese momento en España y una de las pocas en el resto del mundo). Los que vinieran detrás ya podrían agradecérnoslo.

La cantidad de horas a la luz de la luna peleándonos con el paquete y con los usuarios. El enorme esfuerzo realizado. David contra Goliath. Un ERP que cada vez que lo tocabas mutaba por zonas, cambiaba su ADN y se comportaba de forma distinta. Sorpresas que nos continuábamos encontrando hasta el final.

Cuando llegó el día de la puesta en marcha éramos un equipo agotado, extenuado, casi sin aliento. Pero lo peor todavía no había llegado. Lanzamos los procesos de conversión de rigor previos a toda puesta en marcha. Estaba previsto que acabaran a las 12 de la noche, pero eran las 8 de la mañana del día siguiente y todavía no nos habíamos ido a casa por problemas de rendimiento de la máquina (máquina que había sido ampliada para atender las necesidades de Omega y sobre la cual habíamos realizado una prueba de volumen satisfactoria).

Aun así, ese día iniciamos la puesta en marcha y hubo cosas que empezaron a fallar. Las habíamos probado, lo puedo asegurar, pero fallaron. Hubo que recurrir a procedimientos manuales para que los pedidos de los clientes llegaran y se procesaran las entregas. Fue el peor arranque de toda mi vida como consultor. Y por supuesto que no voy a apelar a la mala suerte, ni a Murphy ni a una confabulación conspiratoria para explicar qué había pasado. Está claro que algo no hicimos bien : no probamos lo suficiente, no tuvimos tiempo para realizar una prueba integrada de manual, repetida, con mucho volumen, totalmente representativa. Pero el error primero por mi parte fue no saber decir NO a la estimación de horas que se me impuso en este proyecto.

Tras ese día se sucedieron unos 4 meses de puro infierno, dedicados a arreglar todo lo que no funcionaba mientras la empresa se las apañaba con un sistema precario recurriendo a soluciones manuales para algunas funcionalidades (algunas de las cuales siguen en uso). Cuatro meses trabajando sin descanso una media de 15 horas diarias de lunes a domingo, todo el equipo, aguantando, resistiendo (insisto, sin descanso, ninguno). Bueno, todos menos Mr. Cr., claro, que tenía otras cosas que hacer, y, sinceramente, mejor así.

Con el paso de esos meses las cosas se fueron estabilizando y los errores arreglando. Entre los arreglos que se hacían en el proyecto y los parches que mandaba el fabricante para resolver errores de la funcionalidad básica poco a poco se fue consiguiendo un Omega adaptado y domado. Todavía había que lanzar procedimientos colaterales para arreglar los errores de cálculo del programa. Todo era como un mapa de sistemas parcheado que poco a poco comenzaba a funcionar. Entre medias de la implantación me habían nombrado gerente, pero casi no lo recordaba. No había echado más horas en toda mi vida.

Finalmente abandoné el cliente, cuando ya estaba todo más o menos enderezado. Todavía los que se quedaron tuvieron que sufrir bastante pues el monstruo de vez en cuando entraba en crisis y sufría ataques de irreverencia. Pero yo salí del infierno, y salí muy muy muy quemado. Fue el punto de inflexión, el punto de no retorno, el momento en el que toqué fondo. Ya sólo me cabía escapar. Más hacia abajo ya no se podía caer.

En la próxima entrada haré unas reflexiones sobre este proyecto y este cliente, destacando alguna anécdota o situación de cierta relevancia.

To be continued.

27 - Mi quinto cliente : los malteses (I)

Los malteses, he aquí el proyecto definitivo, el punto de inflexión, el detonante. Una mezcla de mala suerte, animadversión, despropósitos, mala actitud, negligencia, inmadurez tecnológica y temeridad consultora. Un proyecto faraónico, y no sólo por lo mucho que duró y lo complejo que fue, sino porque llevaba un cadáver dentro (en realidad, más de uno), el mío. Una andadura eterna de casi dos años de duración : unos 8 meses de diseño, unos 12 de implantación y unos 4 de tortura.

Un proyecto teóricamente fácil : tras un diseño conceptual se llega a la conclusión de que hay que renovar los sistemas comerciales y financieros de la compañía, que se están quedando anticuados, habiéndose identificado muchas áreas de mejora y nuevas funcionalidades requeridas por los usuarios. Como parte de esa conclusión se incluye la necesidad de que sea un ERP y no un sistema a medida el que sustituya a los sistemas actuales. También, en la conclusión, se apunta cuál : Omega (por aquello de “el final”), un megaERP, parafraseando a Rafa.

(Voy a contar muy resumidamente este proyecto sin apenas entrar en detalles (supongo que el subconsciente no quiere entrar en detalles, lo llaman “shock post-traumático”). Así que en una primera parte contaré el proyecto tal cual devino y en una segunda recordaré algunas anécdotas y situaciones destacables del mismo, lo cual no ha de coincidir con el número de entradas que esto suponga).

El cliente, un fabricante de un producto de gran consumo muy demandado, un líder en su sector, una evolución de la que era la típica empresa familiar, que ahora factura mucho y necesita modernizarse. Fue en este cliente donde conocí de primera mano la existencia de “budas”, auténticos pachás que trabajando de 8 a 15 horas con una productividad algo más que mejorable, cobraban un sueldo muy por encima del mercado : por ejemplo, un analista programador sin titulación universitaria y que entró en la empresa como grabador de datos y que se “levantaba” los 8 kilos de la época (hablo de hace 10 años). Algunos ganaban casi más que la directora de sistemas, porque arrastraban una situación consolidada hace tiempo, que sindicalmente era intocable. Eran auténticos “budas” ante los que el empresario sólo podía esperar a que se jubilaran. (Directora de sistemas que no era otra que la que fue mi primera gerente en aquél mi primer cliente así como en el segundo).

Yo llegué para ser gerente en funciones (todavía no lo era) dirigiendo a un equipo que ya llevaba bastante tiempo en este cliente. En realidad lo que iba era a liberar a Mr. Cr de las funciones gerenciales en ese cliente (menudo regalo envenenado). El equipo con el que me encontré era de unas 8 personas que habían participado directamente en el diseño conceptual. Ahora abordábamos la nueva etapa : diseñar la implantación del ERP elegido.

Omega acababa de aparecer en el mercado. Existía un antecesor estable ya consolidado, pero Omega era la renovación tecnológica del cual no había implantaciones anteriores (sólo una muy pequeñita donde el paquete se implantó tal cual, sin modificaciones). Así que íbamos a ser los pioneros en hacerlo, los temerarios que se olvidaron del peligro de implantar versiones inestables (casi betas en el mercado) tanto tecnológica como funcionalmente. ¿Dónde nos estábamos metiendo, incautos nosotros?

Este proyecto podría ser el mejor ejemplo de cómo no implantar un ERP. En la implantación de ERPs recuerdo un enfoque metodológico que los norteamericanos llamaban “vanilla approach”, que era algo así como : el ERP se implanta tal cual, se parametriza lo mejor que se pueda para adaptarlo al negocio del cliente y se pone en marcha tal cual, siendo el cliente y su modelo de negocio y su flujo de procesos los que se adaptan al ERP, cambiándolos, si es necesario. Es decir, el ERP NO SE TOCA, modificaciones cero.

En el otro extremo de la metodología, está el “Con-un-par approach”(TM) (también conocido como "With-two-balls approach") : coges el ERP, lo cambias en más de un 50% y añades otro 25% de funcionalidad nueva, no importa si partes de una versión inestable técnica y funcionalmente, no importa si los mejores expertos del fabricante del software son incapaces de manejar su producto cuando se modifica tanto, no importa si has eliminado el porcentanje de contigencias en la planificación del proyecto y cuentas con un 30% menos de horas de las que, bajo un esquema de prudencia ante la incertidumbre, serían requeridas. Pues ése, ese fue nuestro enfoque.

Adicionalmente, durante este proyecto tuve por primera vez la experiencia de ver cómo la metodología te arrolla y te paraliza, cuando te empeñas en ser tan metodológico que no eres capaz de ver que el tiempo pasa y no llegas, y entonces tienes que dar carpetazo a tanta metodológica metodología y pasar a un enfoque más “quick-and-dirty”, con espíritu pragmático porque, si no, no llegas.

En fin, los malteses fue un pequeño caos, el largo camino de entrada hasta el ojo de un huracán donde hasta que llegas todo son turbulencias pero una vez allí, en el ojo, todo se para, se calma (se aturde, en realidad) para al instante salir disparado, lanzado con gran fuerza al mundo real (al que te estás perdiendo mientras te dejas los días peleando contra un ERP). A partir de ahí, ya nada duele, ya se alcanza la certidumbre de que todo ha de cambiar. A partir de ahí ya sólo queda esperar la ocasión, el momento preciso que te permita salir, escapar, de la jaula de oro. Y así fue.

Era el quinto cliente, y eso que dicen de que “no hay quinto malo” era mentira.

Como ya comenté, la metodología que se aplicó a este proyecto fue bastante novedosa (al menos para nosotros), si bien al final hubo que aplacarla y controlarla, porque se nos desbocó. Por una parte se aplicó un enfoque de visión por procesos de negocio frente a la visión por funciones. No se mira la empresa como un agregado de departamentos estancos, cada cual con sus funciones, en desarrollo vertical. Al contrario, se aplica una visión transversal sobre los departamentos y se definen los procesos de negocio “cross-departamentales” (valga el término). En función de estos procesos de negocio que identificamos, desarrollamos metodológicamente el proyecto.

El otro aspecto de la metodología que fue distinto fue la metodología CRP (Conference Room Pilot) para integrar y adaptar el ERP al cliente y el cliente al ERP (en teoría este proceso de adaptación tiene que ser bidireccional : el ERP se adapta al cliente mediante la parametrización y pequeñas modificaciones del producto; el cliente se adapta al ERP modificando sus procesos de negocio, sus procedimientos y su forma de trabajar). El CRP consistía en reuniones a las que asistían usuarios de distintos departamentos para ir presentando estructuradamente el ERP e ir discutiendo funcionalmente el mismo : lo que necesitamos y lo que no, lo que nos gusta y lo que no, lo que echamos en falta y es necesario ver cómo se obtiene con el ERP. Así recorriendo todo el producto, pantalla por pantalla, informe por informe, punto de menú por punto de menú. El objetivo es múltiple : el usuario se involucra y empieza a conocer el producto, el usuario se compromete con las decisiones que se toman y ese compromiso da solidez a la solución final que se pondrá en marcha, el usuario se convence de que el ERP va a satisfacer el modelo de negocio de la empresa, se da forma a la parametrización básica del producto, se identifican las modificaciones funcionales o funcionalidad adicional necesarias. Una vez obtenida la parametrización básica, se continúan las reuniones con usuarios recorriendo sus procesos de negocio, sus funciones, para obtener la integración ERP-cliente (recordad, bidireccional).

Dos conclusiones tuvimos claras mientras realizábamos el CRP tan metodológicamente bien soportado :

1.- El tiempo se nos echaba encima y no cumplíamos fechas por las interminables reuniones con usuarios enredados en discusiones bizantinas, que dejan entrever las auténticas guerras de poder existentes en la empresa, hasta el punto de que tal campo no se quitaba de la pantalla simplemente porque alguien que me cae mal ha dicho que sobra : parametrizamos en función de las cuestiones personales de los usuarios entre ellos. Eso sí que es innovación metodológica. Para solucionar este aspecto, comenzamos a agilizar las reuniones, reduciendo el número de usuarios concurrentes, alejándonos un poco de nuestra visión por procesos, para conseguir ser más resolutivos más rápidamente. Del mismo modo, aplicamos un criterio político a la gestión de las reuniones, anticipando las luchas de poder en función de qué departamentos estaban convocados al tiempo que evitábamos reuniones que podían suponer enfrentamientos personales.

2.- El usuario mostró un rechazo importante al ERP, siendo en muchos casos imposible lograr que cambiara su forma de trabajar, sus procedimientos y sus funciones. El usuario exigía que el ERP hiciera exactamente lo mismo que hacía su sistema actual (hecho a medida). Perdimos la bidireccionalidad del proceso, nos fuimos a las antípodas del "vanilla approach" y, lo peor de todo, no supimos evitarlo (o no pudimos). Además nos costaba mucho conseguir el compromiso (el "commitment") de los usuarios, que no querían apechugar con un nuevo sistema que se les imponía desde arriba sin que nadie les hubiera preguntado nada.

Haciendo referencia a una entrada de Luis (tic616), este proyecto encaja con un cliente apalancao y un equipo mixto de especialistas, guerrilleros e infantería prusiana, si bien creo que sobre todo éramos guerrilleros o no nos quedó otra.

Moraleja : un ERP se implanta cómodamente en empresas que nacen nuevas, donde el modelo de negocio, los procesos y los procedimientos se gestan en paralelo con la implantación de las funcionalidades del ERP. Un ERP no se implanta cómodamente en una empresa donde tienen sistemas a medida que hacen exactamente lo que los usuarios quieren y, dado que no están dispuestos a renunciar a ello, se necesitan modificaciones al ERP que superan el 40% de su funcionalidad. Y no es que no sea cómodo, sino que puede convertirse en un auténtico infierno.

To be continued.

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.

Las claves del éxito : serlo y parecerlo. Matriz BCG aplicada.

Preámbulo

En una entrada anterior expuse un texto que hablaba de remeros y catalejos. Al hilo de comentarios que se aportaron al mismo, se pueden entender ambos conceptos de dos formas, dos acepciones : remero y catalejo como tipos de trabajo que se realizan en consultoría o remero y catalejo como tipos de profesional que se encuentran en consultoría. En ese texto, aunque no se indicaba expresamente y quizá no quede bien claro, la intención era exponer la segunda acepción de estos términos.

Una cosa es que en consultoría se pueda organizar la venta de servicios en dos bloques : uno de "generate demand" (o sea, vender) y otro de "fulfill demand" o "delivery" (o sea, desarrollar los proyectos que se venden). En este sentido se pueden encajar también los conceptos de catalejo y remero respectivamente, bajo la acepción primera, de tipos de trabajo. En este sentido, por tanto, está bien que haya remeros y catalejos, porque cada uno desarrolla un tipo de trabajo, una fase del proceso de prestación de servicios profesionales. Hubo una época en AC que se llegó a organizar a los consultores de esa forma. Creo que ahora ya no es así. Pero era una buena forma de enfocar la venta y aprovechar al máximo las capacidades de los empleados, dado que no todo el mundo sabe hacer de todo igual de bien. Era una tándem perfecto. Así, un catalejo te prepara una propuesta "cum laude" y la presenta con su mejor empatía e inteligencia emocional y vende el proyecto seguro. Un buen remero sabe llevar el "management" y no se le escapa una y puede diseñar el mejor plan de conversión de datos de toda la historia de la consultoría. Si intercambiaran sus trabajos, o todo sería un desastre o como mínimo el resultado final sería sin duda peor. Estos mismos personajes, bajo la acepción segunda, serían ambos remeros y también catalejos. El único pequeño matiz a añadir es que los catalejos suelen estar mejor pagados que los remeros, pues, al fin y al cabo, son los que venden y generan los "fees".

Pero la otra acepción, que es la que me interesa en esta entrada, es la preocupante en una empresa. Gente que trabaja muy bien pero no tiene visibilidad ni visión de negocio y que no sabe ver más allá de su parcelita de trabajo y gente que es nula pero con su mejor sonrisa y unas cuantas palabras aprendidas de memoria es capaz de escalar hasta-el-infinito-y-más allá. Son los remeros y catalejos puros respectivamente. Y, a mi entender, ni lo uno, ni lo otro. Y ahora, la entrada : exponer por escrito algo que manejaba en mi cabeza hace tiempo y que empleaba para ilustrar algunas reuniones con mis equipos de trabajo; a ver si soy capaz de ponerlo por escrito.

El cúmulo de virtudes y capacidades que debe llevar incorporadas un consultor (unas de serie y otras adquiridas con el tiempo) se puede agrupar en dos dimensiones, con intención simplificadora de cara a realizar un análisis de las claves del éxito en tu carrera profesional en una empresa consultora (y por extensión en otro tipo de empresas).

1.- Serlo : lo relaciono con lo que se llamaba “content skill”, es decir, lo que se sabe hacer. Serlo es ser capaz de hacer cosas difíciles porque se tiene el conocimiento y la habilidad necesaria para ello : conocimientos técnicos y funcionales, destrezas mentales e intelectuales, experiencia en soluciones similares, etc… Alguien que piensa, que aporta, que crea, que innova, que ofrece soluciones solventes a problemas reales, que se bate el cobre y se deja la piel para que las cosas funcionen y funcionen bien.

2.- Parecerlo : lo relaciono más con la interacción que el consultor tiene con su entorno (el cliente, los compañeros, los jefes, etc…), el “interface” que muestra (tanto dinámica como estáticamente). En el caso extremo es lo que se aparenta, frente a serlo que es lo que en realidad se es.

Ambas dimensiones son necesarias para tener éxito profesional. De nada sirve serlo si no sabes interactuar, empatizar, mostrar, vender, venderte. De nada sirve parecerlo si no sabes serlo o no tienes a nadie que lo "sea" por ti.

Por analogía con un sistema de gestión, el serlo es el “backoffice”, que lanza procesos, realiza cálculos, elabora información para “reporting”, etc.. y el parecerlo es el “frontoffice”, que muestra los resultados en pantalla o en informes, que muestra indicadores de control y dispara alarmas, que interactúa con el usuario recogiendo transacciones que luego el backoffice procesa y almacena. No sé si está muy lograda esta analogía para expresar la idea.

Pues bien, con estas dos dimensiones se puede establecer algo parecido a una matriz BCG de dos ejes y establecer cuatro compartimentos en función de la combinación de ambas dimensiones graduadas de menos a más. Los empleados se ubican en un momento dado de su carrera profesional en uno de ellos, pero, además de forma gradual : uno, dentro de un compartimento, está más arriba o más abajo, más a la derecha o más a la izquierda.

( Esto es un modelo simplificado que no pretende optar al nobel de estudios de psicosociología laboral ).

Tipos de empleado :

· Estrella : lo es y además lo parece. El objetivo y el ideal en la firma.
· Catalejo : no lo es pero lo parece, da el pego y rodeándose de un buen equipo puede salir adelante pero siempre caminando sobre la cuerda floja. Un auténtico superviviente.
· Remero : lo es pero no lo parece, curra mucho y muy bien pero siempre en el fondo gris de la sala. No desfila ni se contonea cuando aparece el socio en el proyecto.
· No-way : ni lo es ni lo parece. Situación crítica que apunta hacia “pending termination”.

Además, sobre la matriz podemos analizar las posibles evoluciones de una persona conforme adquiere experiencia y pasa el tiempo.

Evoluciones más probables :

· De No-way a estrella
· De Remero a estrella
· De Catalejo a Estrella
· De No-way a Remero
· De No-way a Catalejo

Cualquier otra evolución es improbable o absurda.

En todos los proyectos, sobre todo en los grandes, siempre hay remeros y siempre hay quien lleva el catalejo, aunque tenga tu misma antigüedad. El del catalejo se vende muy bien (internamente, me refiero, ya se sabe que tu primer comprador y cliente es tu propio jefe), el remero curra pero no sabe venderse. Eso sí, el del catalejo él solito es incapaz de hacer algo provechoso. De hecho algunos consiguen no programar en toda su vida, no hacer ninguna conversión, si diseñan algo lo hacen a grandes pinceladas que el remero de turno tendrá que rehacer (estoy hablando en todo momento de consultoría de sistemas de información), técnicamente son casi nulos, funcionalmente sólo se han aprendido los grandes titulares (siempre habrá un remero que se los desarrolle), etc... Caricaturizándolo y llevándolo a extremos, el del catalejo puro es un inútil que sabe vender una bicicleta a un paralítico, sabe aparentar que sabe, maneja conceptos que desconoce como si los hubiera inventado él, tiene mucho palique, mucho “bla-bla-chu-chu” (expresión que aprendí de Mr. Cid), pero en cuanto surge el marrón o hay que trabajar de verdad, hace un gesto de mago y te la “la cuela por debajo del baby” (otra expresión de este compañero) y se queda tan tranquilo y “se fuma un puro” (una más) con el socio mientras tú, remero, coges el marrón y lo sacas adelante. El socio piensa que si no fuera por el del catalejo, el proyecto se iría a pique, pero, es al revés (sin el remero se iría a pique y sin el del catalejo igual hasta iría mejor). Un catalejo que sabe evolucionar a estrella es bueno y es viable. Un catalejo que sólo sabe ser eso termina en la calle (aunque alguna excepción habrá, y de hecho alguna conozco "tocando el cielo").

Y del mismo modo, el remero es incapaz de abandonar su visión estrecha y mirar hacia otros sitios, carece de visión de negocio, es incapaz de interactuar con el cliente y fortalecer la relación profesional con el mismo, difícilmente sabe emplear la cadera para capear los temporales político-profesionales con el cliente, no sabe ver más allá y si por él fuera se pasaría toda su vida codificando las mismas líneas de código, y que nadie le incordie ni le pida que haga algo distinto.

El ideal en consultoría (como en muchos otros tipos de empresa y hasta en la vida misma) es ser una estrella. Entrar siendo una estrella es casi imposible, otra cosa es que pases muy rápido a serlo (hablo siempre para gente sin experiencia. Los que entran con experiencia requieren otro análisis). Entras siendo un No-way (algunos entran siendo catalejos, pero fácilmente se les ve el plumero, son los conocidos pitufos-gerente) y rápidamente pasas a remero o a estrella o a catalejo. Luego de remero a estrella o de catalejo a estrella. Pasar de No-way a estrella es posible si en todo momento logras un equilibrio entre ser cada vez mejor y parecer cada vez más.

A lo largo de todos los años en AC conocí a individuos de todas las tipologías. Aunque la gran mayoría de mis compañeros eran estrellas o bien estaban evolucionando a estrella (desde el remo o desde el catalejo), también existían de los otros tipos, aunque los menos y quizá por ello los que más se hacían notar. Recuerdo a un Senior gerenciable que vino al proyecto (en el que yo era Senior todavía no gerenciable) para entrevistarse conmigo y comprender la arquitectura técnica que habíamos instalado e intentar aplicarla a su proyecto. A los 30 segundos de comenzar a hablar con él me di cuenta de que no tenía ni idea de lo que estaba hablando, soltaba términos y expresiones con maestría pero era como el juego ese de dar un discurso enlazando expresiones aparentes al azar. Cuando ese discurso se lo soltaba al gerente o al socio, más o menos resultaba aparente porque cuanto más alto estás menos remero eres y si encima el socio o el gerente son más catalejos que remeros pues ya el éxito está asegurado. Pero hablando conmigo (un remero de pura cepa, pata negra con denominación de origen, que comenzaba a intentar ascender a estrella) era un fiasco, un “hollow man”. Hablaba de cliente-servidor, entorno colaborativo, FFCP, mirroring, procesamiento paralelo y simétrico, etc… que parecía que hasta sabía, pero os puedo asegurar que no tenía ni idea de lo que estaba hablando. Yo le contaba nuestra arquitectura, con intencionada profusión de terminología muy técnica (y eso que, como ya he comentado, yo no era un gurú del tema precisamente, pero al menos los conceptos los tenía claros), pero él, inmutable, asentía con altivez, tomando muchas notas y apuntando con voz alta frases cliché (“eso es clave”, “la situación lo requiere”, “hay que encontrar los key drivers que reducen el gap”, “eso mismo había pensado yo”). Había venido a hacer el paripé. Llevaba así mas de cuatro años, haciendo el paripé, y hasta ese momento le iba bien. ( Con el tiempo me enteré que duró poco más en la firma y le invitaron a abandonar el barco, tanto catalejo vacío ya olía mal ). Supongo que ahora se dedicará a lo que mejor sabía hacer : vender motos.

Recuerdo también a una chica, Mrs. Smiley, de la que ya hablaré, a la que tuve como analista y pseudo Jefe de Equipo y que era el ejemplo perfecto del catalejo superviviente : no se enteraba de nada que fuera mínimamente complejo, pero sabía sonreír y coquetear con sus mejores artes, lo cual le permitía estar bien valorada (espero que esto no se confunda con machismo). Se las apañaba para ser una rémora y hacer suyos los conocimientos y las aportaciones de los demás. Mucha inteligencia emocional y poco de la otra. Al final dejó el trabajo porque en la Bahía le ofrecieron algo mejor que le permitiría desarrollar todo su potencial (frase cliché con tono irónico). Pero el tiempo que logró estar en la firma, le hace meritoria de un premio a la mejor catalejo del año (los famosos “Spyglass awards”). Trabajó conmigo y lo puedo afirmar con justicia a la vista de sus “deliverables”.

También conocí remeros con denominación de origen, que llevaban años así, siendo remeros, entre bambalinas ( este es otro símil bueno, el del teatro, los que están en escena y los que están entre bambalinas operando para que la función salga bien ), sacando su trocito de proyecto adelante, pero resultando invisibles para el resto del mundo. No tenían proyección ni visibilidad ni tampoco ambición para progresar profesionalmente, pero además es que no querían tenerlas. Al final, el “up or out” era una espada de Damocles que más pronto o más temprano les obligaba a abandonar la partida.

También conocí a no-ways. Recuerdo a uno con nombre de rey francés que era una caja de bombas : cuando hablaba con el senior se trastabillaba, sudaba y se confundía; era todo un maestro en pasar marrones a otros; era muy hábil echando la culpa a los demás de sus errores y no sé si hoy en día tendrá clara ya la diferencia entre el entorno de desarrollo y el de producción en el desarrollo de sistemas de información. Una tarde este chico se encontraba afanoso probando un programa que actualizaba la base de datos de artículos. ¿Y dónde se tienen los mejores datos de prueba, los registros más completos y sin incoherencias? Pues en producción, está claro. Y ahí estaba él, dale que te pego contra el maestro de artículos real. Alguien que pasaba cerca de él se dio cuenta del asunto y casi le corta las manos con un sable para que dejara de alterar la base de datos de producción. Al final hubo que tirar de backup y hacer una reconstrucción de transacciones del día en el maestro. Pero lo mejor de todo es que él salió ese día de la empresa convencido de que la culpa era de una chica que le había dicho cómo entrar en la base de datos (la chica le había advertido claramente que entrara en desarrollo y que por nada del mundo entrara en producción, estoy convencido de que fue así porque esta chica era una remera de fiar). En otra ocasión se le asignó programar un mantenimiento sencillito de esos de 4 horas de codificación y 2 de prueba. Cuando ya llevaba una semana codificando, y eso que partió de otro mantenimiento similar y sólo había que cambiar A por B (el recorta-y-pega de toda la vida que ahora llaman copy-paste), le quitamos el programa y se lo dimos a Mrs. R. que, en un par de horas (considerando que tuvo que empezar de nuevo), ya lo tenía perfecto para entrar en producción. Al final, según este chico, la culpa de tanto incurrido era de Mrs. R. que era la que había programado el mantenimiento del cual partió él para codificar su programa, que era muy lioso y estaba mal estructurado (cuando era un estándar de codificación ampliamente implantado). Y como esto, unas cuantas situaciones más que le describían como un auténtico no-way. No sé dónde estará ahora, pero espero que no haciendo SQL como administrador de base de datos. Igual se ha metido en política, que ahí se da bien lo de echar la culpa a los demás y pasar marrones y si metes la pata siempre casi nunca pasa nada.

A la larga sólo las estrellas alcanzan el cielo (con algunas excepciones de catalejos que también lo logran). No existen socios remeros (puros remeros nada catalejos), es un concepto absurdo. Alguien que no sabe evolucionar de remero a estrella aguanta como mucho unos 5 años en la firma. Aun evolucionando a estrella si no sabes situarte bien y ser una estrella solvente, más allá de los 8 años no estás.

Corolario : un consultor además de serlo tiene que parecerlo. (Ya sé que no he descubierto la pólvora, y que esto es de sentido común, pero no está de más recordarlo).

Os propongo un "juego" : en un auténtico ejercicio de sinceridad, tratad de posicionaros con un punto en la matriz. Haced luego lo mismo con la gente y compañeros que conocéis. Dad un paso más y tratad de ver la evolución que habéis seguido o han seguido los otros.

Nota : este modelo es aplicable a otros sectores profesionales. También es escalable y lleva el sello de “Borrador sujeto a cambios. Pendiente de revisión” y el de copyleft. De hecho se podría seguir abundando sobre él y desarrollar un modelo detallado de etología del consultor. Se admiten sugerencias.

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.