En los comentarios al post anterior sobre la posible migración a Google Apps, se planteó el tema de los aspectos comerciales de la operación. Y esto es algo muy significativo, en mi opinión, para entender porque un buen producto tiene poca implantación. Al menos en España. Y quiero centrarme en aspectos de relación, en absoluto estamos hablando, ahora, de productos.

Hace casi un año que nos surgió la primera intención de, al menos, estudiar este tema. Unas pasadas por la web de Google y ninguna capacidad de contactar con alguién de la compañía en España. Tampoco pudimos encontrar referencias españolas (ahora si las hay), ni siquiera listados de socios o integradores con los que hablar. Solo un formulario.

Este verano recibimos propaganda en papel, junto con un disco-calculadora de los ahorros potenciales. En la carta, como contacto, un tipo de Estados Unidos, al que no me sentí tentado de escribir. Planteado el tema en twitter, alguién me facilitó un contacto en Google España. Evidentemente, ese twitter es personal y quién me contestó lo hacía también a ese título.

Es verdad que una vez contactado, fue relativamente sencillo intercambiar algunos datos sobre nuestras necesidades y cerrar una visita-demo. Incluso teniendo en cuenta que estábamos terminando el mes de agosto.

Pero la conclusión general es que el contacto inicial no es nada sencillo. Ni con Google, ni obtener referencias, ni acceder a partners.

En cuanto a la presentación en si misma. Pues la verdad es que de Google esperas siempre lo máximo. Y cuando la presentación se parece a lo que haría un consultor generalista, te quedas un poco frío. Es cierto que luego la parte demo mejoró la sensación general, pero ese pensamiento de "vaya 45 minutos previos me he tragado" no te la quitas. Además, los roles de los participantes no quedaban muy claros.

Y luego hay una parte que en consultoría llamábamos "seguimiento de la oferta": escribir para presentar conclusiones, volver a llamar de vez en cuando para aclarar dudas conceptos, ofrecer pruebas parciales... todo eso que habitualmente se termina convirtiendo en ser un pesado insoportable (difícil saber el límite). Pues de eso, nada. 0 llamadas, 0 correos. Y la sensación generada no es de "que majos que no quieren molestar" sino de "estos tipos o tienen muchos clientes y no pueden con todo o pasan de nosotros". Ninguna de ellas demasiado buena para convertirte en un proveedor de confianza.

Como comparación, al día siguiente de publicar mi anterior post, una persona de Microsoft, con la que no habíamos tenido trato desde hacía, al menos, dos años, me envía un correo electrónico. Me comenta que se ha enterado de nuestras intenciones y me ofrece información sobre Exchange on-line entre otros servicios. Podríamos quejarnos de que no nos ha contactado en dos años y que sólo lo hace cuando hay una amenaza. Pero lo cierto es que lo hace, mientras que su competidor ni siquiera lo hace cuando hay una oportunidad.

Y, por último, un detalle que considero importante hoy en España (aunque  Sergio o Andrés se me echen encima). Está bien que Google sea un empresa abierta, joven y tenga unas oficinas super-cool. Pero cuando vas a un cliente, no está de más ser un poco convencional en el aspecto externo. En cualquier entorno, creo que es mejor pecar por exceso de formalidad que por defecto. No hace falta ir con traje, pero lo de vaqueros y polo no termino de verlo claro cuando vas a casa de un cliente. Sobre todo si el cliente es de cierto tamaño. Estoy seguro de que para una empresa del IBEX-35 se hubiera adaptado la indumentaria.

Releyendo lo escrito, puede que haya quedado demasiado crítico. Pero no estoy hablando de una empresa de 5 programadores en Ávila (con todos los respetos). Hablamos de Google. Y creo que las actuaciones comerciales deben estar a la altura de su reputación y, sobre todo, de sus productos. ¿O hace falta poner ejemplos de empresas que han basado su éxito mucho más en su red de ventas y socios que en la calidad de sus productos?.

(Estaba esperando al final de la historia para publicar el post, pero como parece que nos va a llevar algo de tiempo decidirnos, iré contando las novedades. Este es el inicio).

Esta vez parece que va en serio. Aprovechando el cambio de instalaciones, necesitamos cambiar nuestro servicio de correo electrónico. Un Exchange 2000 que funciona más que dignamente en combinación con un antispam muy efectivo (90% de correos detenidos). Pero ese entorno no es compatible con un dominio en Server2008 (entre otros muchos factores), así que es necesario el cambio. Como ahora si existen opciones, hemos abierto un poco el abanico.

Y aquí aparece en escena Google Apps. Hace tiempo hicimos un primer intento, pero no conseguimos un contacto directo en Google ni un integrador/partner que nos ayudara. Esta vez (gracias a un twitter-contacto: gracias @), lo tenemos.

Ahora viene el proceso lógico en estos casos. No valen dogmatismos anti ni pro Microsoft, ni nada parecido.Ese proceso empieza por valorar si la solución es funcionalmente válida. Es decir, si es capaz de dar solución a las necesidades de nuestros usuarios: además del correo electrónico, convocatorias de reuniones, agendas compartidas, carpetas públicas, etc...

Luego veremos los costes reales de cada solución. Y aquí vamos a comparar lo que necesitamos. Es verdad que GApps incluye chat y conferencia de audio video, o Google Docs. Pero no es lo que necesitamos ahora. Así que no lo puedo considerar una ventaja en la comparativa. O, al menos, no algo fundamental. Pero también es indiscutible que los casi 120 euros de una licencia CAL de Exchange equivalen a 3 años de GApps. Y me faltan los servidores, el exchange, el almacenamiento, el antispam, antivirus, etc...

Estas dos condiciones son las básicas en cualquier proyecto de sistemas (o de levantar un muro, supongo). Pero en una decisión de este tipo entran otros dos factores.

Las supuestas "tendencias". Lo siento, pero no me termino de creer estas cosas. No porque algunos gurús digan que todo va a la nube, debemos ir todos por ese camino (me recuerdan a las agencias de rating valorando empresas en las que participan o de las que cobran servicios). Lo que le vale a una multinacional farmaceútica con 100.000 empleados "worlwide" puede no ser lo mismo que para una empresa logística de 400 buzones.

Además, hay otro factor crítico: la opinión de la alta dirección sobre la ubicación de la información. Algo que en esto no es un factor baladí. Se me antoja parecido a los primeros financieros que recomendaban que el dinero en vez de estar en la caja o bajo el colchón, se dejara en un banco. La sensación de pérdida de control o de seguridad es inevitable. Poco rigurosa, pero inevitable.

Y, por último (last but not least, que dicen los americanos), la combinación de todo esto: la privacidad y la seguridad son muy importantes, sin duda. Pero cuando los ingresos menguan y los cobros se retrasan, ahorran unos miles de euros (unos cuantos, aparentemente), pueden vencer ayudar a vencer ese miedo. Las tendencias está bien conocerlas, pero ayuda más que una empresa de tu tamaño y sector haya hecho lo mismo hace poco (a lo de ser el primero no le veo las ventajas) y con un resultado positivo.

Aún no sé como acabará el proceso (aunque lo iré contando). Lo que si me parece una conclusión extrapolable es que la actual situación económica puede abrir la puerta a muchas tecnologías (cloud, opensource, etc.) que en los "días de vino y rosas" ni se consideraban.

Seguiremos informando...

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.

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.

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.

El otro día, Alberto Noguera criticaba a las pymes con una serie de argumentos más o menos acertados o demagógicos, según quién entrara a comentar.

Por otro lado, nos encanta hablar de web 2.0 (aunque ya haya algún desencantado), de cloud computing, de gestión de proyectos y modelos.

Y, de repente, llega el mundo real. Hemos iniciado hace poco las operaciones logísticas con un cliente con un formato similar a una joint venture. No hablo de un chiringito (al menos por números). Facturación de más de 15 millones de euros y, probablemente, alrededor de 100 empleados.

De cara a la integración de parte del personal en nuestros procedimientos y preparando esa integración "He visto cosas que los humanos ni se imaginan". En alguna delegación, para acceder a internet, tenían contratada un ADSL para cada uno de los 2-3 PCs. Nada de switches, routers comunes o red. Cada equipo, "su internet". Para compartir archivos se lo enviaban por correo electrónico (si, al de la mesa de al lado) o se pasaban un pen-drive. De antivirus, antispam o software con licencia, ni hablamos.

Pero en la central la situación no era mucho mejor. Existía una red LAN (algo es algo) pero ninguna segmentación de permisos o directorios...todo vale, vale todo. Explicando que aquí podían tener datos en el servidor que nosotros no veríamos, igual que ellos no verían los nuestros (simplísima gestión de permisos) les parecía ciencia-ficción. Por supuesto, de aplicaciones o ERPs, nada. Hojas Excel mutantes a diestro y siniestro.

Despues de haber vivido algunas integraciones de este tipo, estoy seguro de que este es el mundo real. Hay cientos o miles de empresas en España que facturan entre 5 y 30 millones de euros y siguen con Windows descargados del emule, sin antivirus, y gestionando todo con hojas de cálculo Excel (por supuesto, también pirata). Y a lo mejor, sólo a lo mejor, esto tiene algo que ver con nuestra posición en los rankings de productividad e innovación.

La semana pasada comí con un amigo, gerente de una importante consultora. Él trabaja en desarrollo e implantación de sistemas de información, y estuvimos hablando de algo básico pero que muchas veces se nos olvida cuando hablamos de tecnología o sistemas.

Estaba encantado con uno de sus últimos proyectos, porque era "una de esas veces que ves que lo que haces es realmente útil para los usuarios y la compañía". Parece algo evidente, pero pensando friamente, es un caso que esta más cerca de ser excepcional que habitual.

Ayudar a los usuarios y a la compañía. Todos hemos instalado complejos sistemas de gestión o control que supuestamente ayudan a la compañía a mejorar el conocimiento de su actividad, a conocer mejor el estado de sus operaciones, a tener más datos de sus clientes, etc. Pero casi siempre a costa del usuario, que se ve obligado a navegar por ventanas complejas repletas de campos obligatorios de los que nunca entienden su utilidad y terminan rellenando con caracteres como ",,,", "." ó "asdf".

Digo supuestamente porque, una vez instalado el sistema, o bien los responsables de completar esa información no lo hacen correctamente ya que a ellos nos les aporta nada y que le sea útil a otro departamento no suele ser razón suficiente para esforzarse un poco más, o bien no se crea la estructura de explotación de esa información adicional.

Y estoy hablando de aplicaciones. Porque hay que ser realista y reconocer que renovar un CPD, virtualizar servidores o instalar blades en vez de clusters es algo que pueda ayudar a la compañía (reducción de costes, de tiempos de caída) pero que para el usuario es absolutamente transparente. Por no hablar de actualizar Exchange, Lotus Notes u Office, que suelen ser casos de impacto económico para la compañía y "peora" de rendimiento para los usuarios hasta que vuelven al nivel anterior, que rara vez superan pese a las "nuevas ventajas" de las nuevas versiones.

Y por no terminar siendo tan negativo, que bueno es al final del año revisar los proyectos que has completado y encontrar que has conseguido alguno de estos "éxitos" con proyectos útiles para usuarios y compañía.

(Reflexión: En esos proyectos, lo que finalmente se valora es la calidad. Que el plazo se haya podido desviar es algo muy poco importante. Aunque si lo sería para el desarrollador si su margen dependiera de ese plazo).