Pues si llega un momento, en que empiezas a dudar de tus creencias y empiezas a reflexionar en otro sentido, y aunque se que algun bloguero piratoso me dirá que no, tengo que decir lo que pienso..
Tras las últimas sonadas compras de MySql y BEA, la única conclusión unánime es que toda compañía de SW, independientemente de su modelo de negocio, puede ser comprada. Y diciendo esto digo todo lo que justifica que empieza a dudar de los productos Open Source, el Open Source más que nunca se está volviendo en un modelo de negocio. Me explico.
Una compañia detecta una oportunidad de negocio, a partir de ciertas ideas de desarrolladores, patrocinado un proyecto Open,y/o fundándolo. El fin de toda compañía es ganar dinero, por lo tanto, calcula el coste de realización y de expansión del producto, "Si hago algo mejor que el de la competencia y encima lo doy gratis, me hago con una cuota de mercado, además mis comerciales son los círculos de desarrolladores".
En el siguiente paso, necesita unos ingresos recurrentes para intentar mantener el producto y mejorarlo, hasta que sea lo suficientemente madura para competir de tú a tú con otros del sector. Para ello doy soporte, formación, etc.. Pero no cobro licencia porque pierdo imagen.. Casos de JBoss y MySQL por ejemplo..
Llegados a este punto, tenemos un producto de calidad y con una cuota de mercado aceptable. ¿Como recupera la compañía la inversión y los socios maximizar el beneficio? Que me compren.. y todos ganamos.. Nos hemos valido del mejor sistema de venta , el boca a boca del desarrollador enamorado de sus creencias Open..
Al final se enriquecen igual los empresarios y accionistas que cualquier compañía que mantiene las licencias sobre el código. Y una vez vendido es necesario convertir el modelo Open en uno licenciado, sino como recupero la burrada que he pagado por ello ??
Ahora en este punto alguien dirá, que no hombre que no, que JBoss sigue siendo Open.. Después de visitar Red Hat y hablar con la responsable de JBoss no sigo pensando que sea tan Open.. vale que no lo llaman licencia pero te "empujan" a comprar un soporte que tiene casi o precio de licencia, lo llaman soporte o algo parecido y no te recomiendan en ningún caso usar el servidor sino lo tienes.
Después de JBoss, MySQL, creo que le puede llegar el turno a Alfresco, Spring, ..
Puede que lo "Open" haya dejado de ser lo bueno, para convertirse en lo menos malo..
... y SUN cogió su fusil
Tras la noticia de BEA llega SUN y se queda MYSQL, cual será el siguiente movimiento corporativo?? apuesto por SAP !!
http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html
http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html
Oracle compra BEA, y una lagrima en la arena.
Una lagrima mía esta claro, compran uno de mis favoritos... supongo que para comprar mercado, tecnología o las dos cosas. Espero que no la desmantelen, pero aún así me da mucha pena..
Cada día nos encontramos más abocados a los monopolios, en un sector en que los peces gordos tienden a comerse a los chicos (que normalmente hacen mejor las cosas), hoy hemos sufrido un reves al menos los que creemos que la forma de evolucionar tecnológicamente viene dada por la competencia.
Ahora que contaremos con menos servidores donde elegir y aún menos suites BPM, se ve más claro que al final quedarán solo Oracle y Microsoft, sin olvidar a la IBM de mis amores, o eso parece, al menos en el mercado de las aplicaciones empresariales.
Otros jugadores invitados a esto son Google, pero ya veremos cuanto y Apple que cuenta con enormes beneficios de sus ventas ipod, iphone, y las últimas series de portatiles y sobremesas. Tienen la cartera llena e intentarán crecer.. aunque esta claro que sus estrategias y sectores son diferentes.. de momento.
Y SAP, se puede permitir quedarse solo?? Le puede pasar como a Rational, BO, FileNet, Siebel etc.. o es un pez demasiado grande. No lo creo.
Cada día nos encontramos más abocados a los monopolios, en un sector en que los peces gordos tienden a comerse a los chicos (que normalmente hacen mejor las cosas), hoy hemos sufrido un reves al menos los que creemos que la forma de evolucionar tecnológicamente viene dada por la competencia.
Ahora que contaremos con menos servidores donde elegir y aún menos suites BPM, se ve más claro que al final quedarán solo Oracle y Microsoft, sin olvidar a la IBM de mis amores, o eso parece, al menos en el mercado de las aplicaciones empresariales.
Otros jugadores invitados a esto son Google, pero ya veremos cuanto y Apple que cuenta con enormes beneficios de sus ventas ipod, iphone, y las últimas series de portatiles y sobremesas. Tienen la cartera llena e intentarán crecer.. aunque esta claro que sus estrategias y sectores son diferentes.. de momento.
Y SAP, se puede permitir quedarse solo?? Le puede pasar como a Rational, BO, FileNet, Siebel etc.. o es un pez demasiado grande. No lo creo.
Modelos de Software Factory. (primera parte)
Durante una serie de artículos voy a reflexionar sobre los tipos de "Fábrica de Software" que podemos encontrar así como sus modelos de trabajo.
El primer objetivo de una Software Factory es saber a que se dedica. La respuesta sencilla, es la inmediata, a desarrollar SW pero evidentemente no es tan simple.
En función del tipo de SW, las Tecnologías y las Metodologías elegidas debemos generar el modelo de negocio. El modelo de negocio debe responder a tres "sencillas" preguntas:
- ¿Que vendemos?
- ¿A quien se lo vendemos?
- ¿A cuento lo vendemos para ganar dinero?
¿ Que vendemos?
A este pregunta suele contestar cualquier MBA llegado a un "Fábrica de Software", está muy claro vendemos Horas, no vendemos productos. Estoy de acuerdo, siempre y cuando no vendamos productos SW, que queremos vender n veces. En ese caso no podemos cobrar a un cliente el número de horas totales sino marcar un número de ventas para amortizar los costes. Pero esa es otra historia.
En este articulo vamos a a hablar del modelo "Fábrica de Software" como aquel que proporciona un servicio relacionado con el SW que se tarifica en horas con un precio hora asociado.
El primer error a cometer, es intentar vender el modelo como un Bodyshopping, sobre el cual no queremos tener ninguna responsabilidad. Bien, se puede dar el caso pero entonces que vengan los JP del cliente ha dirigirlo, porque lo que va a pasar es que no van a estar satisfechos con lo que hacen, y al final se acaba aportando al JP, los Sistemas, y personas no dimensionadas y todo gratis. El Bodyshopping es lo que es, si lo hacemos hagamoslo bien.
Vamos a ver los modelos de "Fábrica de Software" que podemos tener, evidentemente son compatibles entre si, pero debemos diferenciarlos, para saber cual es nuestro objetivo de venta y nuestro precio de salida.
A. Desarrollo de Proyectos.
En este modelo la "Fábrica de Software" es la encargada de realizar un desarrollo concreto, normalmente independiente de otras aplicaciones pudiendo basarse en arquitecturas del cliente o las propias.
En el modelo clásico de Desarrollo de Proyectos, el cliente realiza la especificación funcional (Análisis) y la "Fábrica de Software" todo el desarrollo tecnológico del proyecto, trabajando conjuntamente con el cliente en la fase de validación.
Puntos a cerrar en el proceso de lanzamiento/transición con el cliente a nivel operativo:
- Política de precios / hora.
- Acuerdos por volumen, continuidad.
- Acuerdos respecto a picos y valles.
- Garantía.
- Productividad.
- Política de Facturación
- Acuerdos de nivel de Servicio y penalizaciones.
- Condiciones de salida y cierre.
- Gestión de riesgos (a nivel interno).
Puntos a clave cerrar en el proceso de lanzamiento/transición con el cliente a nivel de ingeniería:
- Estimadores del proyecto.
- Formación del equipo en arquitectura cliente.
- Modelo de Análisis.
- Modelo de Validación.
- Modelo de Gestión del Cambio.
- Plan de Gestión de la Configuración.
El buen cierre o acuerdo en los puntos anteriores minimiza los riesgos y encauza hacia el éxito, la indefinición acerca al beneficio 0 o perdidas.
Evidentemente existen el resto de tareas habituales (Planificación, Riesgos, Dotación de personal, etc) pero ya las enmarcamos dentro del proyecto y las anteriores son previas.
En función de los puntos anteriores o de las previsiones que tengamos de los mismos junto al estudio previo debemos calcular las previsiones de costes, en cuanto a recursos humanos (numero y perfiles necesarios), recursos HW y costes adicionales (desplazamientos, coste de lanzamiento, formación) etc. Tras este cálculo debemos aplicar el % de beneficio que queremos conseguir para el proyecto.
Consideraciones:
- Un proyecto de esta tipología puede estar enmarcado dentro de otros modelos de relación más amplios que se hayan adquirido por un determinado cliente.
- Las tecnologías típicas en que nos encontramos este modelo son, Java y MS .net.
- Son proyectos con más riesgo por lo general que un mantenimiento y se debe marcar % de beneficio más alto o con una previsión de sobrecostes más alta.
- Cada proyecto es diferente al anterior, no hay aumentos de productividad significativos en los grupos de recursos asignados a los mismos.
- El % de Seniors es más alto que en proyectos de mantenimiento. Por tanto son proyectos con mayor coste.
En próximos articulos hablaremos de Mantenimientos (AM), BPO's, Bodyshoping, Test Factory`s y alguno más..
Suscribirse a:
Entradas (Atom)