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.