El pasado sábado tuve la suerte de compartir aula con Jose M. Pelaez, en el Executive MBA en dirección de Operaciones y Logística del que es profesor. Puede asistir como oyente a una de sus clases sobre Sistemas de Información en Operaciones Logísticas.
Además de lo agradable de poder escuchar y compartir las tres sesiones con José Mª, fue una interesante experiencia volver a las aulas, en este caso de una escuela de negocios, para tratar con gente de cursos de postgrado.
La audiencia era de perfil poco generalista (menos de lo que yo recordaba de mi MBA del IE), ya que la mayoría eran ingenieros trabajando en operadores logísticos.
En todo caso, uno de los aspectos más enriquecedor de la experiencia fue recordar los "vicios" típicos de los ingenieros, especialmente de los que trabajamos en Sistemas de Información. Y el fundamental es creer que los sistemas lo arreglan todo. Es más, realmente, suelen arreglar bastante poco. Si tus problemas son de operativa o de sistemática, los ordenadores no te van a ayudar. NO. Lo diga el consultor que lo diga o el proveedor de ERP que lo diga.
Y aunque con los años te das cuenta de eso, de vez en cuando tu afán "cuadriculador" vuelve e intentas arreglar todo cerrando las puertas del sistema. Pero la realidad siempre es más compleja. Ese es el momento en que los usuarios se quejan de "que no pueden trabajar" y los informáticos de que "para que hemos hecho esto si sólo tiene agujeros".
Uno de los primeros gerentes que tuve en consultoría (ingeniero de Teleco, para más señas) decía siempre que "los sistemas de información tienen que ser siempre modelos y, como tal, reductores de particularidades". Como base teórica es excelente, pero los procesos (en general) requieren cada vez más personalización, más adaptación al cliente y, por tanto, tienen cierta tendencia a des-estandarizarse.
Por eso, cada vez más, creo que hay que ir a sistemas de información flexibles y rápidos, aunque eso pueda suponer ir contra los dogmas de la teoría. Ni el código podrá ser todo lo limpio que nos gustaría, ni las bases de datos estar tan normalizadas como dicen los manuales. Recientemente, hemos puesto en marcha una aplicación que sólo sirve para facturar al 90% de nuestros clientes. Pero para llegar al 100% de los clientes, hubiéramos necesitado mucho más tiempo de análisis y desarrollo (varios meses) para, seguramente, tampoco lograr la perfección. Y creemos que es mejor facturar hoy automáticamente ese 90% que, dentro de 8 meses, tener la posibilidad de llegar al 100.
Y no creo que esto sea una chapuza. Los sistemas no van a durar 20 años, como cuando se hacían en Cobol hace 40 años. Como decía Ampara Moraleda, "cada vez nos pasan más cosas por unidad de tiempo" (gracias, Luis, por la cita). Y a las empresas, también. El ritmo de modificaciones es tan rápido que el coste de hacer "perfectas" las cosas sólo supone retrasar el inicio de la siguiente modificación, detectada cuando aún no has terminado la primera.
Es cierto que esto supone un mayor esfuerzo por nuestra parte (la de "los de sistemas"), pero es la única forma de no ser un freno a la innovación de los procesos en nuestra empresa y convertirnos en un facilitador de esos nuevos negocios que, necesariamente, tendrán que apoyarse en nuestros programas y nuestras bases de datos.
El segundo aspecto llamativo de la sesión fue la separación entre la gestión empresarial (entendida como objetivo de los propietarios o administradores) y la gestión del día a día (las operaciones, los costes, etc.). Pero eso lo dejaremos para otro día.
NOTA: La foto está tomada de una clase, en el blog de Enrique Dans.
15 jun 2009 | 07:10 PM
Uno de los mejores profesores que he tenido nos incrustó en la memoría, sabía muy bien diferenciar entre lo que se necesita memorirar para el corto y el largo plazo, que los perfeccionistas se bloquean y con el tiempo he validado que tenía toda la razón.
Estoy completamente de acuerdo con el planteamiento que haces, tanto en que la tecnología no va solucionar todos los problemas, a veces hasta los crea, como en la necesidad de priorizar y agilizar.
Vuelve a sonar a Consultoría 2.0, Consultoría artesana o Consultoría agil o...
16 jun 2009 | 01:00 AM
Tienes toda la razón Rafa. Pero esa experiencia que has ganado y te permite ver con claridad no se transmite con facilidad a los clientes que realmente quieren el 100% (bueno el 100% que cada semana crece un 10% claro) de sus necesidades y que "no van a dejar pasar esta oportunidad de hacerlo todo", "si no lo hacemos ahora no lo hacemos nunca", etc.
Los clientes son ellos dicen, y no vas a saber tú más que ellos... Bueno esto último si has llegado de consultor y muy bien pagado a lo mejor no lo dicen pero lo piensan ;)
No se, lo me desespero con muchos clientes tratando de poner sentido común y limite al alcance del sistema.
18 jun 2009 | 01:48 PM
Hoy he vuelto a tener una reunión del proyecto "incompleto". Y la verdad es que es uno de los que más orgulloso me siento de los últimos tiempos. El haber renunciado a cubrir el 100% del alcance es lo que nos ha permitido completarlo. El 100% del 90% de funcionalidad está conseguido. Si hubiéramos buscado el 100% de la funcionalidad, estaríamos en el 40%, es decir, no tendríamos nada.
Pero es verdad que es difícil de explicar o de hacer entender. Siempre te pueden decir que, "si no voy a tener todo, prefiero queadrme como estoy"... Y llegar con este planteamiento a un cliente puede ser entendido como "este tipo no me va a solucionar nada".
Es verdad que para lograr esto hemos tenido que recurrir a un cliente interno que compartía este punto de vista, ya que cuando se lanzó el proyecto como la super-solución, había tantos departamentos (y objetivos) diferentes, que era imposible llegar a ningún sitio. El cliente adecuado, con el alcance adecuado y un objetivo único han sido la base para lograr completar el proyecto. Y ahora es más fácil que los otros se suban al carro del éxito.