Todo empezó con un artículo de Luis sobre los últimos momentos de un proyecto y la motivación. Coincidía con un arranque y no pude evitar ver los paralelismos.

Me refiero a los "flecos" del proyecto. Esa lista, inicialmente pequeña, de "mejoras" que quedan pospuestas durante el desarrollo del proyecto. Lista que crece exponencialmente según se acerca el arranque y se hace evidente que no hay tiempo para todo. Entonces, pequeñas ayudas, pantallas de simplificación de procesos, listados.... se van quedando para la "Fase II".

Luego llega la fecha de arranque, que más o menos sale bien. Y, cuando se recupera la calma, aparece alguien con "la lista". El equipo que estaba motivado y "con las pilas puestas" para completar algo y que ha llegado exhausto al arranque, se encuentra con una lista de tareas poco agradecidas y nada motivantes que hay que afrontar.

Y a ese escenario hay que añadir el factor de los costes económicos. Si el proyecto está externalizado, toca discutir si esa fase II se debe a incrementos de funcionalidad, a errores de estimación o a otras razones. Pero, en el fondo, se discute quién paga esas horas que faltan por ejecutar. Si es interno, la valoración económica es menos importante, pero la dificultad de gestionar el cansancio y la motivación es la misma.

Lo cierto es que tiene poca solución. Cuando el proyecto es interno, nosotros intentamos incrementar la carga de esa Fase II con nuevos alcances, funcionalidades o tecnologías que aporten algo de motivación (la consulta web de datos, presentación gráfica, transacciones desde PDA o Blackberry,...). Es la forma de añadir alegría a una tarea poco agradecida y así intentar mantener la motivación.

Pero en proyectos externos, esto no es sencillo, ya que estás planteando un nuevo escenario y ese nuevo alcance implica costes que no quieres/puedes asumir. Y que, por supuesto, tu proveedor tampoco asumirá sólo (lo siento, esta tilde la sigo poniendo) para mantener motivado a su equipo.

Aunque, cómo dice Luis, como alternativa puedes poner un poco más de RAM a los equipos ;-)

La foto es de Craig Miles, en Flickr.

Ayer tuve la suerte de estar en Unitronics (@unitronic_es), en una presentación de un sistema de telepresencia que se corresponde con el "state of the art" de la tecnología y una versión "low cost" de reuniones por videonconferencia (view IT). Octavio de tuatu me invitó, junto a Enrique Brito (@ebrito) y Rafa Campoamor (@rafacampoamor) en Madrid y Mikel Agirregabiria en Bilbao y con Marc Garriga @mgarrigap, Carlos Soler y Claudio Bravo (@claudiobravo), en Barcelona. Además, la encantadora gente de unitronics:  Inés Sánchez (@InesSanchez), Responsable de Comunicación Externa,  y a Lola Miravet (@lolamiravet), Directora General de Desarrollo de Negocio y Marketing.

Si alguien quiere una excelente descripción del evento, con fotos y videos, poco que añadir al detallado post de Mikel en su blog (con video y fotos). Voy a intentar añadir una visión un poco más "empresarial" y de aplicación práctica.

Lo cierto es que la tecnología es espectacular y consigue el objetivo de "olvidarte de ella". Sobre la calidad de imagen y sonido, la mejor forma de describirla sería decir que es "real". A los pocos minutos te has olvidado del sistema y te centras en la reunión como si todos los que intervienen estuvieran en la misma sala. Para comunicación entre dos equipos, inmejorable. Cuando las sedes intercomunicadas son tres o más (como ayer), el cambio de imagen en pantalla (se activa por sonido) puede desconcertar un poco.

Cómo es lógico, esta tecnología tiene un inconveniente y es su precio (instalación superior a los 200.000 euros y necesidad de 15 Mb simétricos de ancho de banda). En el caso de empresas multinacionales seguramente ese precio se amortice de forma razonablemente rápida. Si envías cada semana un par de personas de Madrid a Nueva York, Buenos Aires o Tokio, el coste de los billetes, hoteles, horas perdidas en aeropuertos, etc... En el caso de empresas españolas con sedes en tres-cuatro ciudades y reuniones no tan habituales, debe ser bastante más complicado que los números salgan.

Rafa se preguntaba qué aportaba esto respecto a soluciones mucho más económicas como, llevándolo al extremo, una multiconferencia en Skype. Mi opinión es que no todas las herramientas valen para todos los usuarios. Y eso vale para el PC, el teléfono móvil o el sistema de conferencia. Yo no tengo problema en hablar con el gerente de Barcelona por Skype, viéndonos "en pequeñito" y con una calidad "aceptable". Pero esa solución no valdría para una reunión del Consejo de Administración y no creo que sea una cuestión de "clases", sino de uso habitual.

Mikel también hacía hincapie en que ese tipo de reunión presencial, con cierto toque formal, no es el mejor camino para trabajar de forma rápida, ágil...Puedo estar de acuerdo. A veces, con un GoogleDocs compartido y el chat puedes avanzar en aspectos concretos de forma más eficiente. Pero hay reuniones en que la comunicación no verbal es muy importante, y para ellas este tipo de sistemas es perfecto. El ejemplo que más me encaja sería algún tipo de negociación...

En conclusión, una herramienta perfecta para evitar situaciones como la de este video de la propia gente de Unitronics, complicada de aplicar en medianas empresas con pocas sedes nacionales, pero perfecta en grandes empresas con sedes en diferentes países. En todo caso, un máximo nivel de algo que deberíamos ir implantando (con las escalas correspondientes) en otras compañías.

PD: Esto mismo lo contó Enrique Dans desde Shanghai hace algún tiempo.

Con intención, he dejado pasar unas semanas antes de publicar unas conclusiones sobre el cambio del entorno Exchange-Outlook a Google Apps.

Era necesario dejar pasar un tiempo para estabilizar usuarios, plataforma... incluso hay que tener en cuenta que hemos cambiado de oficinas, usuarios, sistema operativo...

Como aviso previo, estamos hablando de la migración del sistema de correo. En ningún momento se planteó la sustitución de las herramientas ofimáticas (Hojas de cálculo, procesador de texto, presentaciones...).

La conclusión principal, funciona. Funciona muy bien.

La segunda, es barato. Aunque esto depende de contra qué compares. Si comparas los costes de una solución in-company, es muy barato. Si sumas servidores de correo, licencias de sistema operativo y sistema de correo, discos de almacenamiento de datos, sistema de archivado (si quieres almacenar mucho tiempo), antivirus, antispam,...la solución GApps es, seguro más barata.

Los usuarios, depende. Un porcentaje muy significativo ha abandonado Outlook y lo ha sustituido por el interface web. Ese porcentaje incluye a todos los que trabajan fuera de instalaciones físicas de la compañía (mediante módem 3G, en instalaciones de clientes, etc.), a la inmensa mayoría de mandos intermedios y directivos y a un porcentaje medio de usuarios de nivel administrativo pero con experiencia en manejar, por ejemplo, sus correos personales en web.

Sólo un pequeño porcentaje de usuarios mantiene el Outlook, aunque curiosamente son los que menos provecho le sacan, ya que no utilizan reuniones, tareas o recordatorios, las grandes ventajas de la herramienta en mi opinión.

La integración con Blackberry ya está resuelta y funcionando y ahora se está produciendo un incremento significativo de la utilización de las funcionalidades que podemos llamar avanzadas: reglas de desvío y copia de mensajes por su origen o contenido, calendarios compartidos, documentos compartidos, grupos, etc.

Sería poco realista no reconocer que ha habido momentos en que hemos pensado "¿Por qué no nos habremos quedado como estábamos?", cuando los usuarios se quejaban de la velocidad del nuevo sistema al sincronizar Outlook o descargar ficheros (venía dado por un problema con la configuración de la red de datos).

Mi conclusión es que ha merecido la pena el riesgo asumido (todo cambio implica riesgo), que el nuevo sistema es tan bueno como el anterior para los usuarios de Outlook y mucho mejor para los usuarios web y que, sin duda, cada vez más compañías migrarán a este modelo, bien sea con Google o con los propios servicios online de Microsoft. Me refiero al modelo, no a la herramienta, que es siempre algo más opinable.

Una versión más profesional de este post se puede ver en esta presentación, que utilicé en el evento de Cloud Computing de IIR, el pasado 19 de mayo.

Una historia de automóviles. O no.

Un señor entra a un concesionario oficial de una marca de automóviles, por ejemplo, ELCARO.

Comprador: Hola, buenas tardes, necesito un coche de cuatro plazas para ir a trabajar. 
Concesionario oficial ELCARO: Muy bien, le ofrezco el modelo ABC, con motor de 1.800 cm3. 
Comprador: Perfecto, el precio me encaja. Me lo llevo. Pero yo no tengo experiencia con su marca de coches, así que necesito que me lo prepare para que yo solo lo tenga que arrancar y utilizar a diario.
Concesionario oficial ELCARO: Ningún problema. Una de las ventajas de esta versión es que usted no tiene ni que abrir el capó, ni mirar el motor, ni nada. Tampoco tiene ninguna identificación exterior para identificar el modelo.
Comprador: Muy bien, es justo lo que necesito. ¿La factura?
Concesionario oficial ELCARO: No se la entrego yo. Se la entrega directamente la marca. Aquí la tiene.

Pasan tres o cuatro años, en los que el comprador visita anualmente el concesionario oficial para las revisiones y el mantenimiento, incluso sabiendo que lo puede conseguir más barato en otros talleres. Cada año paga y obtiene la factura de la marca, ELCARO.

Un día le llaman de la marca para preguntarle por su coche. El comprador recibe al representante de la marca con su mejor predisposición. Al fin y al cabo, compró su coche en un concesionario oficial, paga las cuotas cada mes e incluso el soporte y mantenimiento anualmente.

El representante de la marca abre el coche, entra, lo revisa...Incluso abre el motor.

Y dice: Vaya. Usted tiene un motor de 2.500 cm3. Y lo que pagó fue el de 1.800.
Comprador: ¿?? ¿Y?
Repr. de la marca ELCARO: Va a tener que pagar usted la diferencia por todos los kilómetros que ha hecho este año y pagar un coche nuevo.
Comprador: ¿Cómo? Su socio, bajo su marca, me vende un coche que les pago religiosamente a ustedes. No tengo formación ni opción para ver el motor. Y su socio me entrega uno diferente del que compré de forma que yo no lo puedo saber y ahora usted me pide un dinero muy superior al precio inicial del coche.
Repr. de la marca ELCARO: Si. USted es el dueño del coche y, por tanto, responsable de tener lo que no le corresponde. Los concesionarios son entidades independientes. Y no todas son fiables.

Ahora cambiamos concesionario por partner, representante de la marca por bufete comisionista y ventajista de abogados y damos la vuelta a la marca de automóviles, ELCARO, para convertirla en una empresa de BBDD...y tenemos a Oracle con Garmendía Abogados.

La duda, inevitable, es si el concesionario y la marca no estarán de acuerdo en actuar de esta forma. Es decir, ¿es más creíble pensar que Oracle no sepa que sus partners instalan versiones no autorizadas o que Oracle insta a sus partners a actuar de esta forma para luego cobrar unas cantidades adicionales que, de conocerse inicialmente, les eliminaría del proyecto?

Mi opinión es clara. Si el interés fuera realmente velar por sus licencias, este proceso se haría tras la instalación, o en la primera renovación de licencia. Si se dejan pasar varios años, parece claro que no interesa tanto verificar las condiciones de contratación, como obtener dinero de ellas. Si además la instalación es de tipo "caja negra", tienes al estafado, quiero decir, al cliente, perfectamente pillado.

En estas condiciones, me parece absolutamente razonable que una pyme prefiera descargarse el software del emule que comprarlo a un distribuidor oficial. De hecho, creo que no tiene otra opción. Si no tiene abogados capaces de entender las condiciones legales (casi siempre, en inglés) de las licencias y técnicos para instalar y verificar que la instalación es correcta, no puede saber si el partner o la compañía de software le están engañando.

Este post no pretende ser una apología del software ilegal. No creo en ello. Creo en pagar lo que utilizas. Y si te parece caro, siempre hay alternativas más baratas. Revisando el lema de Hector, "el software, por su valor y por su precio". Pero creo que o las compañías de software se preocupan de verdad de que sus partners sean empresas serias y rigurosas o abren un canal de comercialización directo. Lo contrario sólo genera este tipo de abusos en que es inevitable pensar mal de ellas, que además son las que sufren la pérdida de ingresos derivadas de esas versiones "piratas".

Cuando las obras de los nuevos edificios empezaron a tener una ficha fin real, el director general me encargó ocuparme del traslado de la compañía.

Al ser la parte de sistemas y comunicaciones una de las claves, tenía sentido que coordinara con compras (sillas, mesas, etc.) y servicios generales / infraestructuras (luz, agua,...) todo el seguimiento del proceso. El proceso terminó razonablemente bien, aunque los primeros días no había calefacción en la cafetería, algún día se cortaba el agua, .... lo normal en un "arranque" de este tipo.

El caso es que, como premio o como castigo, el director general ha decidido que "esto de los ordenadores" lo tenía muy controlado y me ha asignado lo que se suele llamar Servicios Generales, y aquí dividimos en Infraestructuras (lo relacionado con los edificios) y Compras (lo de dentro de los edificios), partes que antes dependendían del area financiera. Aunque no hubiera tenido opción de negarme, tampoco me parece tan malo. Y creo que tiene sentido desde un punto de vista de organización y metodología de trabajo.

Pensando en separar las operaciones de las áreas de staff, es razonable, ya que son departamentos de apoyo a la operativa, como son los Sistemas de Información. Las compras tienen algo, en la gestión de tus clientes (usuarios), de CAU. Recibes peticiones, las priorizas, gestionas y solucionas. Luego debes medir que has dado el servicio adecuado con el coste correcto. Y las infraestructuras son más parecidas al desarrollo de sistemas: defines que quieres hacer, presupuestas (horas y euros) y ejecutas, intentando desviarte lo menos posible de las previsiones, aunque siempre habrá incidencias en otra instalación (proyecto) que te obligue a mover recursos. De hecho, esa formalización de la gestión es lo que se pretende con la reorganización.

Pero por otro, parece que estas áreas "aportan menos valor" que los Sistemas de Información (o eso creemos los de sistemas, claro). Lo que puede entenderse como una cierta comoditización (perdón por la palabra) de los sistemas (N. Carr lo dijo hace ya tiempo). Son áreas en que si algo falla (uniformes de almacén, limpieza o aire acondicionado) se genera un ruido brutal en la organización, pero que cuando funcionan, no se valoran. Algo parecido a la red, internet o el correo electrónico.

En esos aspectos no creo que debas pretender que lo que hagas mejore mucho los resultados de la empresa. Quizás debas conformarte (y no es poco) con dar un nivel de servicio adecuado que permita que el tiempo dedicado a eso sea mínimo. Así la organización (como tu área de SI) podrá dedicarse a las cosas realmente valiosas.

Este enfoque vale también para las nuevas áreas. Se puede hacer una gestión de recortar los costes un 2 o un 3% en electricidad o en pedidos de material de oficina. Pero eso no va a ser una ayuda fundamental a los resultados de la compañía. Pero que las gestiones del resto de los departamentos con estas sean limpias, claras y sencilla (lean, que decían mi profes de operaciones en el IE), permitirán que se dediquen a mejorar sus procesos y no desgastarse en tareas administrativas internas.

Quizás soy poco ambicioso en los objetivos, pero veo difícil convertir estas áreas en generadores de gran valor para la empresa. Por eso creo que lo primero que debemos conseguir es "pasar desapercibidos" para el resto de unidades de negocio. Dar un servicio adecuado e intentar no convertirnos nunca en un freno para el desarrollo de los procesos de la compañía.

Voluntariamente, he omitido los aspectos personales. La evolución de más tecnología a más gestión, sin apellidos. Lo que tic616 indicaba hace poco recomendando este artículo. Otro día.

En el post anterior dejé cuatro puntos abiertos o "problemáticos".  Lo típico que la gente de sistemas decimos, no es que no funcione pero es verdad que podría funcionar mejor y.....Pero que nuestro jefe resumiría en ¿funciona o no funciona?. Y si la respuesta tiene que ser binaria, es NO.

Estos son los cuatro puntos:

Las carpetas compartidas

No existen en GMail. Curiosamente, me contaron que Microsoft también las había eliminado en la primera versión de Exchange 2007, pero luego lo solucionó en un Service Pack. Estas carpetas son las que se suelen utilizar con direcciones de correo del tipo cau@dominio.es, atencioncliente@dominio.es, rrhh@dominio.es. Sirven para que varias personas de un grupo o departamento puedan acceder a esa información. Con eso evitas problemas de saturación de buzones personales, "pérdidas" de correos si el destinatario está de vacaciones, etc. Nosotros incluso desviábamos los faxes recibidos a cada carpeta departamental.

Pues bien, en GApps esto no existe. Y punto.

Se pueden buscar soluciones alternativas, pero ninguna es perfecta. Puedes crear la cuenta y dejar que otros usuarios la puedan ver y gestionar. Pero tendrás un límite de 10 usuarios. Y eso para departamentos grandes es un problema. El límite incluso afecta a las conexiones SMTP por Outlook.

El concepto de grupos no es válido. Lo que hace es reenviar el correo a todos los usuarios del grupo, pero ninguno sabe si otro ha etiquetado o procesado ese pedido, por ejemplo.

Nosotros lo hemos solucionado a base de muchas reglas y filtros sobre una cuenta de usuario. Hemos dado acceso a 10 usuarios y hemos monetado muchas reglas para que todo lo que venga del cliente @cliente1.com se reenvíe a los usuarios A, B y C que son los que suelen gestionar esa cuenta y nunca coinciden en sus vacaciones.

Este es, para mi, el principal problema del cambio de aplicación.

Uso vía Outlook

Hay que ser realista. Para los usuarios "tecnológicamente avanzados" la interface web de GMail es imbatible en velocidad y funcionalidad. Pero para usuarios más básicos, que solo reciben y envían correos, mantener el Outlook es casi obligado.

GSync soluciona esa necesidad, sincronizando continuamente el Outlook local con el buzón web de GApps. Hasta ahí, ningún problema. Además, ahora se puede limitar el tamaño del pst, con lo que eliminas los problemas tradicionales de grandes pst de Outlook (2 Gb). Pero funciona como un POP, por lo que tras unas vacaciones o un fin de semana, el tiempo hasta que se completa la descarga puede ser muy alto.

Pero si recibes muchos ficheros "grandes" adjuntos (4-5 Mb), la descarga SMTP genera más tráfico que cuando todo estaba en tu servidor local. Eso hace que sea lento (para el usuario) y que necesites bastante más ancho de banda de internet del que tenías antes de migrar.

No es algo insalvable, pero si algo que debes tener en cuenta.

La utilidad jefe-secretaria

Aquí el problema no es tanto que no funcione, si no que no lo hace igual que Exchange con Outlook. Nada imposible de solventar, pero que afecta a personas de mucho poder en las organizaciones. Y no hablo del Consejero Delegado, si no de su secretaria o asistente.

Un ejemplo básico. Cuando el asistente convoca una reunión en nombre del jefe, las confirmaciones llegan al jefe. En Outlook llegaban al asistente. Fácil de solucionar con un reenvío (o filtro) desde el buzón del jefe de todo lo que tenga asunto Aceptado o Rechazado.

Algo más serio: no se pueden compartir los contactos personales. Es decir, el jefe no puede llamar a su asistente para pedir el teléfono, la dirección o la fecha de cumpleaños de uno de sus contactos.

Servidor Blackberry

Bueno, esto hemos conseguido que funcione. Gracias a esfuerzo personal de un amigo que nos ayudo casi, en sus ratos libres, y a mucha prueba-error. Creo que debemos ser una de las poquísimas empresas en España (o en Europa) que tiene un servidor BES con GApps funcionando.

COROLARIO

Pero hay un corolorio que es el principal. Y que sigue siendo la principal ventaja de Microsoft, la capacidad comercial basada en la red de partners.

Un buen partner técnico podría resolver o, al menos dar las pistas, para que todo esto pasara casi desapecribido. Y la realidad que hemos percibido es que, hoy por hoy, ni siquiera pagando puedes encontrar una empresa sólida que te ayude con una implantación de GApps. Y esto si que es algo que puede resolver Google España sin depender de los equipos de desarrollo de Google.

Queda un post, el de lo "bueno"...coming soon.

La foto es de precipice, en flickr.

Llevo tiempo posponiendo los post sobre los resultados reales de la migración de Exchange a GApps. La razón fundamental no era sólo la falta  de tiempo, sino que no tenía claro cómo iba a terminar el proceso. De hecho, aún no tengo certeza absoluta del éxito del mismo.

No pretendo hacer un manual de migración, ni mucho menos. Sólo contar nuestro proceso, por si sirve de ayuda a alguien. Y, sobre todo, explicar los puntos débiles que hemos visto en esta migración. Por parte de casi todos los implicados (y los no implicados). Desde Google a Telefónica e incluso RIM. Para no dejar un ladrillo enorme, hoy voy a comentar sólo el proceso y los problemas encontrados en él. Los defectos de funcionalidad o de utilización los detallaré más adelante.

La parte de contratación es sencilla, especialmente desde que en enero de este año, Google generó los contratos en español y bajo legislación española. Anteriormente estaban en inglés y sujetos a legislación irlandesa, lo que podía echar atrás a los más escrupulosos o cuidadosos. La alternativa era contratar con un revendedor o partner, pero no fue necesario.

De hecho, conviene aclarar que la migración de 400 cuentas de correo la hemos realizado totalmente de forma interna, sin soporte de partners externos y sólo con el "soporte" de Google (del que hablaremos en otro momento).

La puesta en marcha de un entorno de pruebas también es sencilla, y el soporte de la gente de Google en esa etapa también es bueno. En nuestro caso, básicamente consistió en crear un subdominio (algo así como usuario@tudominio.com.google.es), al que redirigir todo lo que llegaba al Exchange. La salida de los mensajes desde ese usuario si era directa.

Esta opción también fue la elegida para la migración. Una vez creados todos los usuarios en el nuevo entorno, se cambia los registros MX (y su peso) y el dominio gestionado por Google se convierte en el principal. No me quiero entretener mucho en estos detalles, sobre todo porque ahora parece que hay nuevas herramientas de migración.

Para subir los mensajes de cada usuario, utilizamos GSync, que sincroniza el Outlook de escritorio con la cuenta de GApps. De esta forma, la bandeja de entrada y resto de carpetas de cada usuario se incorporaba a la cuenta de Google.

La principal pega en este proceso viene con la incorporación de ficheros pst. Directamente, podemos decir que no funciona (y hay una nota de Google al respecto: http://code.google.com/p/google-email-uploader/issues/detail?id=40). Perder los remitentes o destinatarios es algo poco aceptable. Ojo con este tema si tenéis usuarios de los que guardan todo en este tipo de ficheros. Es mejor no tocarlos y seguir accediendo a ellos desde Outlook.

De esta parte hay poco que comentar. No es complicada, pero no conviene alargarla mucho. Nosotros tardamos varias semanas y eso genera problemas simples pero molestos como no tener la libreta de direcciones actualizada, no poder acceder a los calendarios de usuarios sin migrar, etc...

En todo caso, creo que se puede concluir que el proceso de migración del correo es sencillo.

Además, la mayor parte de nuestros primeros usuarios paso directamente al acceso web. Perfecto. Ni una pega tras minisesiones de formación de 90 minutos. Los calendarios y documentos compartidos casi desde el primer día son la prueba del éxito de estos usuarios "avanzados".

Hasta aquí, todo perfecto. La migración es fácil, y la herramienta de acceso recomendada (web) es impecable. Pero las características "avanzadas" que se utilizan en un sistema de correo electrónico son las que generan problemas, algunos de ellos no resueltos.

Estas características "problemáticas" son:

• Uso de carpetas compartidas: la típica atencionalcliente@tudominio.es que Exchange gestiona como carpeta (no como usuario). Esto no está bien resuelto en GApps.
• Jefe-Secretaria (suena machista, pero es como se suele llamar esta característica): el compartir calendarios, convocar agendas o el acceso a los contactos también es mejorable, cuando no inexistente.
• El uso vía Outlook, medianta GSync, genera algunos problemas de tráfico. Especialmente combinado con las dos características anteriores.
• Blackberry: el acceso directo desde muchos terminales es muy sencillo (iphone o Android, por ejemplo). Pero si tienes un servidor BES, prepárate a sufrir.

Para no alargar demasiado el post, el próximo día detallaré estas cuatro incidencias y como se pueden solucionar (más o menos).

(Este post es un poco viejuno y había quedado como borrador. Pero quiero retomar esto y retocar algo es más fácil que empezar de cero. Poco a poco).

Hoy he tenido una experiencia que hacía mucho que daba por desaparecida del mundo consultoril, tras ser la práctica habitual hace 10-15 años (yo la viví desde el otro lado).

Me refiero al consultor "sabelotodo" que intenta vender una solución integral, sofisticada y definitiva para un problema que no tienes. En este caso particular, buscábamos soporte a un pequeño piloto de reporting y agregación de información entre sistemas y nos quería vender la cojo-aplicación de Business Intelligence, con Data Mining y lote completo de Informes dinámicos, broadcasting, forecasting. En términos "de gerente", yo necesitaba una persona a tiempo parcial un mes (incluso algo menos) para dar soporte sobre un producto opensource y él me quería colocar dos personas dos meses (más el overhead) y un producto de primera línea mundial (y licencias en k$).

Es cierto que hay que ser ambicioso cuando lanzas un proyecto y que tienes que intentar mirar un poco más allá de tus necesidades actuales. Pero no creo que Raúl haya contratado un almacén robotizado de 20.000 metros cuadrados y trilaterales filoguiadas para gestionar el stock de Triopic. Sería fantástico para él, pero hoy por hoy creo que no lo necesita (ójala dentro de poco si, y que nos lo subcontrate a nosotros).

Recuerdo que está actitud de vender el lote completo era habitual hace 15 años. Llegabas a un cliente y le colocabas lotes completos de productos en los que sólo llegaba a utilizar el 25% de la funcionalidad. No digo que engañaras al cliente, pero si es cierto que le proporcionabas un cañón para matar moscas. Quizás, te justificabas, un día tuviera que luchar contra Stukas.

En la mayoría de los casos, tu comprador era un experto en el negocio con un desconocimiento importante de la tecnología. Además, los productos eran más difícilmente modulables y la implantación completa, mucho más cómoda que la parcial. Para completar la jugada, el número de opciones era muy limitada.

Pero ahora creo que eso es más complicado. Los productos son, casi todos, más modulares. Además, existen más alternativas (basadas en productos open o en cloud). Y, sobre todo, cualquier persona (vale, casi cualquier) que está en un negocio tiene una base tecnológica, aunque sea sólo basada en la experiencia, que hace complicado "colar" algo injustificable.

Por eso me ha sorprendido tanto este regreso al pasado. No sé si el tipo nos ha considerado muy jóvenes e inexpertos (está mal decirlo, pero no aparento los años que tengo ;-) ) y ha querido apabullarnos. O está loco por vender y ha buscado el lote completo a la primera. Pero desde luego, ha conseguido desacreditarse por completo.

Hasta aquí, lo escrito antes de Navidad. Hoy me envía un correo que me confirma que no entendió nada, proponiéndome montar el proyecto en una factoría de Sudamérica. El coste de montar un equipo para empezar algo así es imposible que se justifique para lo que yo necesitaba, aunque si para lo que él quiere vender.