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.