El modelo de «software extraído»

Suele ser la tónica habitual que los desarrollos de software realizados a medida se queden en propiedad del cliente. En realidad, da igual si se quedan o no, porque lo que se desarrolla suele estar hecho tan a medida que es imposible en la práctica reutilizarlo en otro sitio. Más aún, yo he visto muchos proyectos de software desarrollado internamente con la intención de venderlo también fuera después y casi siempre es un fracaso. Existen algunas excepciones, por ejemplo Stephen O’Grady menciona en un post cómo la base de datos IMS de IBM surgió del Programa Apolo de la NASA, a esto O’Grady lo denomina el modelo del software extraído.

El modelo del software extraído es extraordinariamente atractivo para el emprendedor ya que es una alternativa a la financiación de capital riesgo. Es por ello que repasaré a continuación en qué se basa.

1º) Un cliente no va a hacer un desarrollo a medida parecida a ningún software estándar que ya esté en el mercado. Entonces, mi primera idea es que no se puede «extraer software» de un nicho de mercado que ya esté «commoditizado».

2º) Para que un proyecto a medida se apruebe internamente, debe proporcionar una ventaja competitiva muy clara, o, alternativamente solucionar un problema muy perentorio y preocupante. Ello suele conseguirse mediante el empleo de alguna novedosa tecnología o técnica procedimental. Segunda idea pues, no se puede extraer software empleando sólo tecnología madura. No quiero decir con ello en absoluto que lo contrario sea cierto, que sólo se deba emplear tecnología experimental. Nosotros mismos hemos extraído mucho software Java y .NET, es más, resulta más sencillo extraer Java o .NET que extraer Ruby o Python. Lo que sí sucedía es que dicho software además de estar escrito en un lenguaje maduro, contenía innovaciones técnicas y de proceso de negocio que sí eran claramente diferenciales.

3º) El proyecto debe empezar por algo pequeño por lo que sólo un puñado de gente apueste un céntimo y, si el piloto tiene éxito, entonces extenderlo rápidamente. Esto es porque si el software a extraer empieza con un megaproyecto de alcance corporativo entonces empezarán a implicarse demasiados departamentos cada uno arrimando el ascua a su sardina y al final lo que salga será un híbrido que hará todo pero no servirá para nada por ser el fruto de que en comercial querían un Ferrari y en producción querían una furgoneta. Además, si el proyecto es grande, se convertirá en objetivo de los tiburones de consultoría quienes argumentarán que es demasiado grande e importante como para que lo haga una startup.

4º) El cliente debe ganar más cediendo el software al proveedor que manteniéndolo él mismo en solitario. Hay varias formas de regular esto. Cliente y proveedor podrían pactar un acuerdo de reparto de beneficios por la venta. Pero yo creo que lo mejor es persuadir al cliente de que se quede con una parte y permita que el proveedor tome propiedad del resto con la condición de liberarlo como Open Source. Esto es porque a fin de cuentas el negocio del cliente no es vender software, ergo un acuerdo de reparto de royalties puede provocar que la agenda de desarrollo y comercialización de futuras versiones dependa de intereses del cliente contrarios a los del proveedor.

5º) Los competidores deben de poder adoptar el software sin que ello resulte lesivo para ninguna de las partes. Se suele tener mucho miedo de que la competencia copie mejores prácticas, y es una preocupación razonable. La mala noticia es que lo van a hacer de todas formas. Ninguna ventaja competitiva ganada invirtiendo en tecnología dura para siempre. La única oportunidad que tiene el primer cliente es la de llevarle entre 3 y 5 años de ventaja a la competencia en cuestiones de eficiencia tecnológica. Por otro lado, el ecosistema de clientes debe de ser de tal naturaleza que les permita compartir software. Compatir secretos técnicos siempre parece a priori del todo inviable, pero recordemos que hasta las armas más modernas están disponibles en el mercado para quien pueda pagar su alto precio.

6º) El software debe estar diseñado, desarrollado e implantado desde el principio para extraerlo. Ello implica que debe ser más modular de lo que sería un software a medida estrechamente acoplado a las necesidades del cliente. Y también que todos los interfaces entre los módulos deben de estar totalmente exentos de «dependencias raras». Por último, hay que hace run esfuerzo mayor en generar documentación durante el proceso de desarrollo que sirva como guía para los implantadores que vendrán detrás.

Si se cumplen las condiciones anteriores, el software extraído puede ser una forma fantástica de lanzar una empresa porque cuando el primer proyecto termina, la startup tiene:

1º) Una estructura de costes que se autofinancia con los ingresos del cliente.
2º) Un producto terminado.
3º) Una referencia comercial importante.
4º) Cero deuda.

Sólo hay que tener cuidado con una cosa más, cuando termina el proyecto del primer cliente, hay que reducir los gastos al mínimo, siendo frecuentemente necesario reducir plantilla (a veces es posible hacerlo fácilmente traspasándo mano de obra al cliente). Esto es debido a que aunque la startup sepa cómo fabricar software y ponerlo a funcionar, corre el peligro de escalar demasiado pronto cuando aún desconoce otros aspectos clave por ejemplo sobre cómo contratar comerciales y hacer marketing para ganar prospectos. Tras el primer proyecto exitoso puede ser un buen momento para coger deuda, pero dicha deuda no debe utilizarse para mantener a un equipo sobredimensionado de programadores ociosos mientras esperan a que alguien cierre la siguiente venta.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Esta entrada fue publicada en Adoptando Sw Libre en una Organización, Mercado y Oportunidades de Negocio, Modelos de Negocio, Organizando la Comunidad. Modelos de Desarrollo. Guarda el enlace permanente.