En primer lugar, aclarar que aunque el término se refiere, en origen, a los consultores de la antigua Arthur Andersen, luego Andersen Consulting (desaparecida incluso de Google), es casi utilizable para cualquiera de las Big Four (antes, Five). Seguimos...

Cuando en 2003 empecé el MBA, una de mis compañeras de grupo me soltó, a los dos o tres días de conocernos "Es que tú eres normal, no pareces un arturo".

Mucho antes de eso, en muchos clientes había oido de forma más o menos directas o, simplemente, al pasar junto a la máquina de café, comentarios, generalmente despectivos, sobre "los arturos". En algunos casos, se utilizaba también en el mismo sentido términos más generales como "los consultores" o, en entornos menos considerados (por ejemplo, almacenes logísticos), "los encorbatados estos".

Siempre me ha parecido una generalización bastante injusta (como todas). Pero tras unos cuantos años fuera del entorno, a veces te descubres pensando lo mismo que pensaban los que te veían entonces.

Hace unos días vino un consultor de una de estas grandes a una entrevista de trabajo. Le entrevistaban dos personas que, casualmente, habáin trabajado en empresas de ese tipo. Precisamente por eso, no podían dejar de reirse al comentar la entrevista y los términos que utilizaba "el arturo": "quiero pasar a cliente final", "¿cúal es la denominación exacta del puesto?", "¿a quién debo "reportar"?", "¿cuales son las funciones y necesidades del puesto?", "¿cúal será la estructura de mi equipo?"...Todo con mucho sentido para una descripción del puesto o un proyecto de reingeniería de procesos.

Pero la vida real, en la mayor parte de las empresas (dejaremos fuera a las del IBEX-35 y alguna más), es más complicada. Menos estructurada y más flexible. Y el responsable de Asesoría Jurídica tiene que echar una mano a algún consejero con sus escrituras, o el de logística tiene que organizar la mudanza del CEO de un cliente, o el responsable de TIC tiene que mandar a un agente de CAU a casa de un consejero para ver porque "no va la wifi". Y, además de esas anécdotas, te tienes que preocupar de que las cosas salgan adelante. Aunque esa decisión no sea de tu departamento o la solución a un punto abierto dependa de otros. Tienes que ocuparte de llenar los vacíos que quedan en los procesos para completarlos, porque aunque no figure en la descripción del puesto, hay que hacerlo. Y no importa nada el quién.

Lo que me resulta llamativo es lo lejos del MundoReal que se puede llegar a estar. Yo tuve la suerte de trabajar en proyectos con todo tipo de personal de los clientes, con directores generales y con mozos de almacén. Y es algo que agradecí mucho. Cuando estás tres noches seguidas con los mozos y responsables de un almacén, la percepción de la logística y de los sistemas que se necesitan tiene poco que ver con la que te cuenta el Director de Aprovisionamiento en la sala de reuniones de la planta noble. Y si solo has estado en esas reuniones, terminas convirtiéndote en ese estereotipo, casi caricatura, por el que a veces nos identificaban. Y realmente es injusto para los muchos consultores que han (hemos) estado en proyectos trabajando junto a operadores de CAU, mozos de almacén, cajeros de sucursal bancaria, comerciales de telefonía, etc...y es que no todos eramos "arturitos pata-negra de despacho de consejero delegado".

Como conclusión, esa caricatura está asociada a la rigidez, al seguimiento estricto del modelo. Y creo que hoy, incluso con independencia del tamaño de la compañía, se necesita flexibilidad, capacidad de adaptación (que es algo que puedes y debes aprender en consultoría). Y si no eres capaz de hacerlo y de transmitir esa imagen, tienes un problema.

PD: Y he sido algo indulgente al no comentar nada sobre el corte de pelo estándar, el traje y la camisa estándar, la corbata estándar y la llegada y salida en taxi hasta la puerta.

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.

Un atinado comentario de Sergio en el post anterior sobre las rebajas de precios, me ha recordado un lúcido análisis de Angel sobre el coste de un consultor y, como consecuencia, sobre cuanto debe costar un proyecto o, mejor dicho, ¿a cuanto hay que vender un proyecto?

Sobre este tema ya ha escrito mucho Luis, pero me gustaría añadir una idea, que proviene de una experiencia personal.

La forma más sencilla de poner el precio a un proyecto de consultoría es empezar por estimar el esfuerzo necesario en horas de cada perfil (programador, analista, etc...). Luego se añade un coeficiente de incertidumbre que depende de si conocemos bien al cliente o no, si creemos que sabe lo que quiere, si la tecnología es o no madura, etc.

A eso se le añade un porcentaje de supervisión (el temido overhead), que son las horas de gerente, socio, etc.. Con eso tenemos el precio "base" al que podremos hacer un descuento por interés en entrar en el cliente, por ser una buena referencia para el futuro, etc.

Pero como dice Sergio, no hemos hablado apenas del cliente. Puede ocurrir que el precio así calculado sea 100 (por usar una base). Pero podemos hacer que el cliente ahorre 500. ¿Cuál debería ser el precio entonces? ¿Tiene sentido una rebaja de última hora en un proyecto así?. Y si el proyecto no va a tener un impacto positivo claro para el cliente, ¿debemos hacerlo? ¿hay que hacerlo barato y rebajar la calidad, con lo que el resultado será aún peor y perjudicamos nuestra credibilidad?. ¿O tiene sentido recomendar no ejecutarlo, beneficiando la credibilidad pero dañando nuestro resultado, al menos a corto plazo?. Estas son las preguntas que permitirán que la relación sea de confianza, el mejor criterio (el único?) para seleccionar a un consultor.

Y ahora una batallita sobre proyectos baratos o caros.

El proyecto más rentable en el que he trabajado para un cliente fue un desarrollo web. Estamos en el año 2000 ó 2002 (aprox.). Permitía a los proveedores consultar cuales de sus facturas habían sido revisadas, tenían o no incidencias y cual iba a ser la fecha de pago de la misma. Lo resumo con datos aproximados. Cuando tienes, por ejemplo, 2.000 proveedores, las llamadas para hacer esas consultas volvían loco al departamento correspondiente durante la semana anterior a la fecha de pago.

El desarrollo web costó menos de 15.000 euros en un mes de trabajo. Sumemos un servidor, unas licencias, un certificado de seguridad, etc. Pongamos coste total 30.000 euros (y me estoy pasando muuucho). Pero como los proveedores también se iban a ahorrar mucho tiempo de gestiones y llamadas, ¿qué tal si les cobramos un poco?. Sólo 50 euros/año. Ellos se van a ahorrar en teléfono y gestiones mucho más.

Resulta que el proyecto no sólo "se paga por si mismo", sino que convierte al departamento financiero en un centro de ingresos para la compañía. En este caso, está claro que el proyecto se vendió "barato". Si el consutlor es capaz de proponer la idea, valorar el impacto y que el cliente la acepte, puede vender el coste de desarrollo al triple de su coste real y, aun así, sería inferior al valor aportado.

No siempre es fácil evaluar el impacto económico de un proyecto en una compañía y el abuso de los Business Case de estos últimos años con ahorros imposibles (e increíbles) ha hecho mucho daño a la credibilidad de los mismos, pero no cabe duda de que hacerlo antes de presentar la propuesta evitará tener que hacer rebajas de última hora que implican un coste económico y de confianza que seguro que nos traerá complicaciones futuras.

NOTA: Curiosamente he podido ver que la web sigue activa, con esa letra Times sobre fondo sombreado típica de 2000-2002. Y ahora es multiidioma, por lo que supongo que el modelo se ha estendido a otros paises de esta multinacional. Sin duda, uno de los mejores proyectos TIC de todos los tiempos por rentabilidad para el cliente.

No me gusta regatear. Ni en mis compras particulares ni en las que aquí interesan, las profesionales.

Me parece que cuando pides propuestas estas deben reflejar lo que quieres al precio que el proveedor considera justo. Y espero que ese sea el precio del producto/servicio. No espero que luego si no es el elegido venga con un 5-10-20% de descuento. No me parece presentable. Si haces eso, no puedo evitar pensar que han intentado engañarme la primera vez.

Hemos pedido ofertas para un proyecto de cierto volumen, alrededor de 250.000 euros. Tras una selección entre cuatro, nos quedamos con dos propuestas casi idénticas en tecnología y precio (menos de 1.000 euros de diferencia).

Comunicamos al ganador y al finalista la decisión, ya que antes de firmar el acuerdo definitivo hay que poner de acuerdo a una tercera parte, algo que no debe suponer ningún problema.

Y el "finalista" llama al día siguiente para comentar que tuvieron ayer reunión de no-sé-qué comité con no-sé-cual manager y que pueden aportar fondos promocionales para descontar un 10%. es decir, casi 25.000 euros.

Moralmente, me apetecería obviar la llamada y seguir con el plan inicial.

Pero si puedo ahorrar ese dinero a la empresa, creo que debo hacerlo. Y eso implica llamar al proveedor seleccionado y pedirle ese dinero. Lo cual me resulta muy incómodo a nivel personal y poco ético en lo profesional. Y más aún si me dice que no puede hacerlo.

Así que una mañana que debía ser tranquila, de revisión de detalles técnicos se convierte en dar vueltas a la cabeza sobre lo que está bien o está mal y sobre la ética de los proveedores y, por qué no, de los compradores.

NOTA: La foto es de juoerr (en Flickr)

Como otras veces, el debate sobre el precio y el valor de las consultoras grandes. Esta vez, elevado de nivel por gente que sabe de lo que habla como Raúl (@rahego, ex-consultor de las grandes), Angel (@abarbero, consultor y profesor de Escuela de Negocios) o Fernando (@fegido), aunque reducido a frases de 140 carácteres gracias a twitter.

Yo estuve siete u ocho años en una de esas consultoras. Ahora recibo ofertas de empresas mucho más pequeñas, aunque la situación actual y las ganas de vender hacen que estos días IBM, Accenture o Indra también quieran conocernos.

Se hablaba de Accenture, pero creo que se puede aplicar a IBM, Indra o CapGemini de forma similar. No cabe duda de que en el coste hora de un consultor de estas compañías estás pagando una parte de la oficina de Picasso o La Moraleja, la esponsorización de una estrella del golf o un equipo de Fórmula 1, y los salarios "indecentes" (es una forma de hablar, yo no los considero así) de los socios o partner o principals, según como se llamen en cada casa. Todo esto es verdad. No creo que nadie lo discuta.

Pero tampoco ofrece dudas que un documento bien preparado por gente de estas compañías suele significar un cuidado en la presentación y en el contenido bastante mayor del que te presentan otras empresas más pequeñas. Y lo mismo que hablamos del documento podemos aplicarlo al desarrollo y ejecución de los proyectos, siempre y cuando estemos hablando de proyectos de cierta magnitud/dificultad. Prestarte un programador senior por horas durante 8 meses no es un proyecto y no es consultoría. En esos proyectos lo notas en cosas tan pequeñas pero significativas como los literales en las pantallas, su distribución, la reutilización de componentes, la usabilidad, etc.

Y es cierto que esto es más discutible porque hay excepciones. En un sentido y en otro. Hay grandes que presentan cosas lamentables y empresas pequeñas en que trabaja gente igual de buena que en una de esas grandes y que, incluso, han estado en ellas para tomar la atención por el detalle, la necesidad de razonar las cosas y de dar un hilo argumental a una propuesta. Y en estos casos, el Brawn GP es tan bueno (o mejor) que el Ferrari.

A eso se le puede llamar cultura de empresa, forma de trabajar o metodología. Pero para mi esa es la diferencia. Y puede que en ocasiones reste flexibilidad, pero garantiza un estándar de calidad. Entendiendo la definición académica de calidad de "entregar lo que el cliente espera".

La diferencia entre la situación actual y la de hace unos años es que gente con ese "saber hacer" hay ya en muchos sitios, no sólo en esas consultoras. Algunos estamos en clientes y otros se han lanzado a la aventura por libre. Y, de una forma u otra, ambos nos hemos llevado una parte de esa forma de hacer las cosas. Eso, sin duda, resta ventaja a las grandes y da una oportunidad a las pequeñas (en tamaño), pero obliga a todos a trabajar con unos estándares de calidad que vienen dados por el que esas grande compañías han generado. Si eres capaz de mantener esos estándares y aportar la flexibilidad del tamaño, estás en muy buena posición para ser competitivo contra los grandes.

Luego hay otros factores, como el que nunca (de nuevo, con excepciones) eres el primero en que se hace algo, o como que siempre hay capacidad de sustituir a una persona que no encaja en el cliente o hay recursos para cubrir un pico o desviación (yo estoy sufriendo esto porque un proveedor ha desasignado de aquí a personas y ahora no puede no hacernos el mantenimiento). Pero estos están muy directamente relacionados con el tamaño.

Cuanto del extracoste va a parar a Tiger Woods y cuanto corresponde a esa metodología es difícil de determinar. Qué porcentaje extra estás dispuesto a pagar por esa "firma reconocida" depende de tu bolsillo y de tu confianza en tu capacidad de elegir bien.

En resumen, creo que si hay justificación para esa diferencia de precios y que en ocasiones merece la pena pagarla (si puedes). Pero que esa diferencia no puede ser ahora tan grande como hace años. Y que, entre esas empresas más pequeñas o de nicho, hay gente igual de buena que en las grandes.

Un último comentario. De la comodidad del CIO/Director de Sistemas de poder usar a posteriori la excusa de "a mi me lo dijo/hizo Accenture/IBM" hablaremos otro día.

Llevo tiempo dando vueltas a una historia que solo puede parecer razonable a alguien que ha estado bastante tiempo en una de las consultoras grandes. Mejor dicho, no le parecerá razonable a nadie, pero alguien que haya estado más de 5-6 años en una Big Five (o las que sean), lo verá como familiar. Desde luego, Andrés o Senior Manager, con su reciente opinión sobre las empresas "de prestigio", llorarían (de risa o de pena) con la historia.

Una persona lleva 11 años en una de esas. Con una buena carrera, promociones cada 2/3 años, esas subidas salariales de 15-20% anual y evaluaciones en la zona más alta. Una mala relación con un cliente (por una de esas historias que a veces cuenta Luis) y...a la pradera, con el "punto de mira" grabado en la espalda.

(La historia con el cliente es para contarla. Resulta que esta persona trabaja para el Dir. de Sistemas, pero compartió clase en la Universidad con el Dir. de Organización. Los dos directores no se pueden ni ver y el primero ve conspiraciones por todas partes. Conclusión: se queja al socio para que le quiten a esta persona de cerca.)

Hasta ahí, es todo un poco raro. Pero que me llame una persona de otra empresa competidora para decirme que están buscando donde colocar a esta persona, que ya ha movido el CV en su casa y que si lo quiero para intentar moverlo...roza lo surrealista. Sobre todo cuando he verificado que el interesado no sabe esta parte de la historia.

Todo es delirante, pero me quedo con esto:

• que estés fuera de la compañía y no te lo hayan dicho claramente.
• que hayan tardado 11 años en darse cuenta de que no eres tan excelente como te han dicho y que ahora no encajas.
• que muevan tu curriculum a tu espalada, incluso en los competidores, ¿para ahorrarse las probables seis cifras de la indemnización?.
• que no se permita un error, especialmente uno de relación personal. Leí hace poco un tuit sobre diferencias culturales y la diferencia entre "comete tu error" y "cómete tu error".

Ahora que han pasado seis años, me gustaría saber qué de todas estas cosas ocurrieron a mis espaldas cuando yo dejé esa misma compañía.

PD: Han pasado algunos días mientras publicaba el borrador. La historia no ha cambiado, pero ahora me ha contado esta persona que ya han hablado con ella para "ayudarle a encontrar algo". Lo que denominan outplacement pero que puede traducirse por "si te coloco me ahorro una pasta".

La escalabilidad es uno de esos valores supuestamente absolutos en el desarrollo de sistemas de información.

Pero hace poco compartí una experiencia con un ex-compañero que me hizo plantearme que hay que tratar ese "valor absoluto" con mucha precaución.

Problema de negocio: personas fuera de instalaciones propias, con acceso limitado a equipos o redes del lugar donde se encuentran. Trabajo nocturno. Su trabajo es supervisar trabajadores "manuales": limpiadores, ensobradores, encartadores, manipuladores varios. Tienen que preparar un parte de personas, horas y tareas y hacerlo llegar a una central, para que esté disponible la mañana siguiente. La disponibilidad on-line aporta cero valor al negocio

Solución "tecnológicamente avanzada": portátil con conexión 3G/HSDPA, aplicación web o cliente ligero y disponibilidad inmediata de datos en la central.

Solución "intermedia": rellenar un formulario preimpreso "a mano", marcando casillas, y enviarlo por fax. Un sistema OCR reconoce el formulario y vuelca los datos al sistema central.

Cualquiera de las dos soluciones es técnicamente buena. La primera es más espectacular y aprovecha mejor la tecnología disponible actualmente.

Pero surge el tema de la escalabilidad. Nosotros hemos implantado el primer sistema. Apenas tenemos entre 3 y 5 ubicaciones operativas donde realizamos este tipo de servicio. El coste de 5 portátiles con sus módem 3G es razonable, comparado con el ahorro conseguido si hay que hacer que esas personas vuelvan a la oficina tras su jornada de trabajo e introduzcan los datos en un PC.

Mi compañero preparaba el proyecto para una empresa con cientos (puede que miles) instalaciones de este tipo. La adquisición de ese número de  PCs era implanteable. Y el coste de gestión de esos equipos sería brutal. Su solución es menos "tecnológica" pero más eficiente. En este caso la escalabilidad tecnológica está asegurada por las dos soluciones, pero no la financiera.

Y otra moraleja más curiosa aún. En este caso la empresa pequeña puede utilizar una tecnología mejor pero más barata que la grande. Algo en qué deberían hacer reflexionar a muchos de esos gestores de PYMEs que piensan que las TIC son sólo para las empresas del IBEX35.

En esta casa no somos demasiado exigentes con los presupuestos y la planificación anual, por lo que es este mes cuando solemos cerrarlos. No creo que sea bueno ni malo, simplemente es así.

Y dando vueltas a "lo que vamos a hacer en TI este año" se me ocurren algunas reflexiones, seguramente equivocadas (espero que no todas) que quizás puedan encajar en otras compañías.

Parece claro que no va a ser un año de grandes inversiones. Podemos decir que las TIC aportarán eficiencia, efectividad, productividad, etc... pero no creo que este año mucha gente se meta en diseñar y montar nuevos cojo-sistemas de soporte a la decisión o de CRM o similares. Al menos, nosotros, no. Esto posiblemente tendrá una consecuencia curiosa. Al bajar el presupuesto dedicado a "nuevos proyectos" y ser la parte de licencias y mantenimientos más rígida, el resultado final será que el porcentaje de "continuidad" sube y el de "innovación" baja (hablo de porcentajes), dando la razón a los que ven el departamento de TIC como un cementerio de dinosaurios que sólo se ocupan de mantener las máquinas funcionando.

Por otro lado, la gente de las unidades de negocio dedicará menos tiempo a pensar en el futuro y más en el presente inmediato. Esto seguramente va contra la innovación y la planificación, pero está más cerca del MundoReal. Eso dejará a las áreas de TIC más libertad para proponer cosas. Como no podremos esperar a que vengan las peticiones (que no vendrán) y tenemos que demostrar que somos útiles (de EREs está el mundo lleno), podemos, de verdad, aportar ideas. Y ahí caben muchas cosas: novedades en internet, aprovechar herramientas o técnicas de web 2.0, mejorar comunicación con clientes, etc. Nosotros conocemos el negocio mucho más que los de negocio conocen lo que permite la tecnología. Y dado que no van a agobiarnos pidiendo nuevos listados para el ERP, podemos enseñarles lo que la tecnología (entendiendo como tal lo "nuevo") puede aportar al negocio. Este es, para mi, el aspecto más atractivo del año que empieza.

Otra cosa más. Las licencias. Quizás este momento permita explorar iniciativas que en otro momento no valdrían. Outlook es una herramienta fantástica. Gmail es un sistema de correo electrónico excelente (y supongo que Google Apps, más), pero no hay una gestión de calendario tan buena como la de Outlook. Si actualizar el Exchange cuesta ¿100-500-1.000.000? euros, ¿puede ser el momento de aceptar cierto esfuerzo para gestionar la agenda por parte del personal para mejorar en ese importe la cuenta de resultados?. Esto es, sin duda, una oportunidad excelente para las alternativas de software libre.

No pretendo en absoluto ser un Gartner o similar que presenta sus "tendencias 2009". Es simplemente una reflexión más pegada a la realidad de las empresas medianas y algunos aspectos a tener en cuenta este año (además, puede servir de ayuda a consultores a la hora de proponer cosas).