Google - el diablo sigue avanzando II

Google sigue pasito a pasito hacia el dominio de los sistemas personales.

Se ha conocido otro indicio que indica que Google quiere ofrecer una suite ofimática en Internet. Se puede ver en google.dirson.com

Consultor funcional

Éste es el título/nombre que le hemos puesto al perfil profesional que estamos buscando para que se incorpore a la empresa dentro de un segundo nivel.

Ahora estamos a plena ocupación (cargabilidad casi del 100%), lo que aparentemente es muy bueno pero que en realidad es una trampa ya que no tenemos tiempo para la acción comercial.

El objetivo de incorporar un segundo nivel, además de liberar al primer nivel para poder hacer acción comercial, es pasar de un modelo de mucha dedicación individual en pocos clientes (que ha sido muy útil en esta etapa inicial) a un modelo de dedicación media en más clientes y así conseguir un efecto multiplicador de nuestra experiencia.

Es una buena oportunidad para personas con alrededor de 4 años de experiencia en consultoras de negocio o departamentos de organización, y que quieran tener un trabajo que les permita interactuar con niveles altos de nuestros clientes (directores de área funcional) en proyectos medianos y pequeños, no necesariamente tecnológicos.

La dificultad mayor que estamos encontrando es diferenciarnos de las ofertas que hacen las consultoras grandes, aparentemente más atractivas, pero que en realidad son de puestos de menos nivel de responsabilidad y de menos contenido intelectual.

Ese es nuestro atractivo: responsabilidad, autonomía y crecimiento profesional e intelectual

Otros factores diferenciales del software Open Source

Se ha descrito bastantes veces la singularidad del software Open Source frente al software propietario: seguridad, factores sociales, factores económicos, etc. En este post me gustaría mencionar otros factores diferenciales que no son tan frecuentemente citados.



El software Open Source tiene una arquitectura más modular que el propietario

Una aparente debilidad del modelo de desarrollo de software Open Source como la dispersión y diversidad de los desarrolladores revierte en un beneficio: la dispersión obliga a construir el software Open Source en piezas que sean fáciles de interconectar. Esta conclusión es la que se desprende de un estudio del MIT (citado por Nicholas Carr y descargable aquí) tras un análisis comparativo de la arquitectura de Linux y la última versión de Netscape (origen de la primera versión de Mozilla).

Otra conclusión interesante del mismo estudio es que la arquitectura de un software propietario es un reflejo de la organización de los equipos que lo han desarrollado. Como son equipos muy cohesionados, las distintas partes del software tienden a estar muy interrelacionadas entre sí, por lo que cualquier cambio posterior de la aplicación tiene un gran impacto (los que tienen experiencia en desarrollo y mantenimiento de software lo entenderán muy bien).

Supongo que es por eso que cada vez que actualizas cualquier aplicación en entorno Windows te pide que reinicies la máquina.



El software Open Source no es viable para cualquier aplicación

Que se me entienda bien, no es que técnicamente sea inferior, es una limitación debida a la filosofía identitaria del software Open Source, ésto es: cualquier desarrollo sobre una aplicación Open Source debe ponerse a disposición del resto de la comunidad.

La primera vez que empecé a pensar en este factor diferencial fue a raíz de un comentario de Carmen Puras en un post que hice acerca de las aplicaciones de negocio que corren en Open Source.
Carmen dudaba que el modelo fuese válido en su entorno profesional (banca). Y tiene toda la razón: Si una empresa desarrolla una aplicación de gestión que no está disponible en el mercado y que supone una ventaja competitiva sobre su competencia (caso frecuente en el entorno bancario) lo lógico es que no quiera que la competencia se pueda beneficiar y por tanto es difícil que pueda utilizar como base un entorno basado en Open Source.

Lo que nos lleva a una interesante y creo que controvertida conclusión: El software Open Source sólo es viable cuando se construyen aplicaciones que no constituyen ventajas competitivas frente a la competencia. La historia de las aplicaciones Open Source parece corroborar esta conclusión: primero fue Linux, después aplicaciones básicas como Firefox y últimamente ERPs.

¿Está el software Open Source condenado a convertirse en una commodity?

La venta de proyectos y el contexto

Hay mucha literatura escrita sobre los procesos de venta: Que si las 5 Ps del marketing, que si la motivación de vendedores, el networking personal, la programación neuronal, la conversión de producto en servicio, bla, bla, bla ...

El otro día me encontré con una situación donde toda esta parafernalia, pues la verdad es que no es muy útil.

Resulta que fuimos a visitar al director de una empresa familiar mediana que quiere implantar un nuevo ERP. Anteriormente a nuestra visita, el buen señor, había consultado a alguien (no sabemos a quien pero sospechamos que a una empresa que vende ERPs) el "coste de poner un ERP en esta empresa".

La cantidad que le habían dado era objetiva y significativamente muy poco realista (por baja) y así se lo hicimos saber en ese momento. El hombre en principio se cerró en banda (fase de negación), después, cuando le hicimos cuatro razonamientos básicos, ya dijo que se lo tenía que volver a mirar (fase de evasión).

Finalmente descubrimos por una indiscreción suya, que ya le había comunicado al dueño de la empresa el coste que le habían dicho. El gran problema era que ahora a ver quien es el majo que va ahora al dueño y le dice "mire don Paco (me lo invento), que lo que le dije que valía 100, en realidad vale 300. Queee, ... estooo, ... me equivoqué con la cifra" ... (fase de ahora que hago).

Nuestro proceso de venta del proyecto se ha transformado del clásico (1) convencerle de que somos los que mejor le podemos buscar y gestionar la implantación de la aplicación informática que necesita su negocio y (2) ayudarle a vender internamente el proyecto, a además (3) hemos de darle la vuelta a un embrollo que bloquea la venta.

Después de darle varias vueltas sólo vemos posibilidad de vender el proyecto si conseguimos ayudarle a que se salga airoso de esta situación tan incómoda. Es una opción beneficiosa para las dos partes y es la que exploraremos en las próximas semanas.

La conclusión a la que quiero llegar contando esta batallita es que frecuentemente aparecen situaciones donde, como decía aquel, lo importante es el contexto.