Improve your software product delivery process performance using metrics (II)

This is the second article of the series. Please read the first post before this one.

During the previous article I explained the process to follow, using the simplest possible model to describe a software product delivery process, to measure and improve its performance, following a data driven improvement kata as a way to promote a continuous improvement culture .

Despite providing extremely valuable information, once we have gone through the described process for a few iterations, the limitations of such a simple model will become evident. We will need to add complexity into our model, getting closer to the real software product delivery process.

Add complexity to approach reality.

If you have a clear map of your real delivery process, you can skip this step. If you do not, the first thing I recommend is to run a value stream workshop to discover and describe your delivery process. Visualizing it as a group is a great exercise, not just for those involved in the workshop, but also for the rest of the organiza­tion. If you are not able to draw the flow of the code end to end, identifying what happens where and who is responsible for what, trying to measure the performance of the process is often pointless.

How should the model be enriched?

For our purpose, we do not need a great level of detail as outcome of the value stream workshop, just enough to create your new model. Let’s assume for now that one of the outcomes of such workshop is a drawing like the one below, which I took from an exercise for an automotive platform. Only the “green criti­cal path” is shown here. I hope you get an idea of what is needed.

Based on this diagram, you can see clearly that the delivery process can be divided in three or four stages. Try to do it in three, again, for simplicity. For this example I will divide it in four since, in automotive, the validation/verification stage is rele­vant in terms of effort, complexity, throughput and specially stability.

So our richer model can be expressed in the following way:

This new model is a better approximation to our real delivery process.

Mathematical construct and quantitative analysis

Once we have described our system using a richer model, the question is, do we need to change our mathematical construct?

As you can guess, the answer is no, we do not. We just need to enrich it. The construct used to characterize the simplified model would have been very limited if now we would have needed to modify it.

Again, Steve Smith provides in his book “Measuring continuous Delivery” what we need to extend the metrics. The overall idea is to use the same metrics and measures for the entire process (as we did with the simpler model) and for each stage (corresponding to this new model). This is essentially the case for any linear process, like the one we created. S. Smith refers to these “extensions” of the metrics and measures as indicators.

It becomes now harder to define the events to extract the data sets from since the data probably needs to be extracted from different tools. I recommend to invest time in describing these events, how the data sets are extracted from the affected tools, how to convert such data into the right units… You will also need to describe accurately which events determine the beginning and end of each stage. All this effort will allow you to iterate in the process creating more complex models.

The methodology to measu­re, process, plot and analyze the different data-sets will be analogous to the one described in the first post of this series. The only difference is that now it should be done for each stage, in addition to the overall process.

Qualitative analysis

It is easy now to realize why we tried to keep our scale simple. The number of combi­nations we need to work with increa­ses now. The scenarios for each stage are consistent with those described for the previous (simpler) model, so the qualitative analysis done for both models complement each other.

The definition of the scenarios can be personalized and adapted to your needs. Since you will also use those scenarios as a communication tool, make sure they are described in away that resonates to your workforce. Reduce their number to those that make sense to you and ignore the others.

You should execute the same qualitative analysis for each stage of the delivery process to describe in simple words the scenario that better describes the current performance of your delivery process as well as the target scenario. Please remember that the goal is to improve the performance of the overall process not to optimize any specific stage. If an improvement done in a specific stage does not have a positive impact in the overall process, you need to question the consolidation of such improvement.

Data Driven Improvement Kata

This step will require changes. Now that our system model is more complex, the methodology to improve performance of the delivery process will need to consider the company organi­zational structure as well as the cycles in which the business, product and development teams operate.

At scale, these katas cannot be structured in a single cycle, but in several ones. The book “Leading The Transformation. Applying Agile and DevOps principles at scale” by Gary Gruver and Tommy Mouser provides an idea of how to approach this continuous improvement process for larger organizations.

I suggest to consider two cycles whenever you can. In my example (very academic, to explain the process) I have consided three: business cycle, product cycle and experiments cycle.

Please check the references (at the end of the first article) to learn more about improvement kata. I will make some considerations about the above example for those of you less familiar with continuous improvement methodologies:

  • The overall idea is to synchronize the three cycles.
  • Business cycles are usually a year long. I would structure the business iterations in quarters.
  • Define the business goals for the product and relate them both, qualitatively / qualitatively with the metrics / scenarios.
  • Define the current scenario and the target scenario for the current quarter. Be concise.
  • Define the most suitable cycles for your product. Bare in mind that some effort in analysis, coordination and communication with the workforce will be required on each iteration so too short cycles might bring unnecessary overhead.
  • If the development teams work in weekly sprints, I would start with monthly iterations for the product level. If engineering teams work with two weeks sprints, then consider iterations of six weeks at product level.
  • As described in the previous article for the simpler model, I will use the boards to explain how the iterations are defined.

The first board correspond to the business cycle, the second one to the product and the third one to the technical experiments to be performed by development teams. Click the picture to enlarge and read the advises.


In this second article, we have enriched our model introducing more complexity (four stages). We saw how the mathematical construct should be extended to characterize each stage, which allow us to get a finer grain information, increasing the accuracy of our analysis. We have seen that Throughput and Stability remain useful as key metrics, as expected.

We have also discovered that, as it happe­ned with our quantitative analysis, the qualitative one is essentially an extension of the one introduced in our previous article for our simpler model. We have modified our approach to continuous improvement adapting the data driven improvement kata to a more complex environment. The proposed example. covers, in my view, large organiza­tions. Such data driven improvement kata has been summarized in three boards, one per level: business, product and technical.


These two articles represent a modest attempt to summarize and structure in 5 basic steps the process that an organization should go through to improve its delivery process performance at scale using Throughput and Stability as guiding lights.

Obviously writing about this topic is easier than implementing it so I am looking forward to read about your own experience and how it contradicts, modify, complements or support the described methodology and advises.

Consumir Software Libre es bueno. Producirlo es mucho mejor.

Las elecciones locales y autonómicas en España han vuelto a poner de moda el Software Libre debido a su inclusión como línea estratégica por parte de algunos partidos políticos.
Dejando a un lado el error que, a mi entender, significa politizar el Software Libre, ignorando pasados fracasos, me gustaría centrarme en otro riesgo que percibo, mucho más relevante.
A principios del presente siglo surgió en España un fuerte movimiento cuyo objetivo era el fomento del uso de Software Libre en España. Se trataba de aprovechar las ventajas más evidentes (y cortoplacistas) que aporta este “nuevo” paradigma.Todos los acores empujaron en una misma dirección…. y han tenido éxito.
Sabemos, no obstante, que el valor real del Software Libre para una sociedad reside no tanto en su consumo como en su producción. El hecho de poder pasar de consumidor a productor de tecnología sería lo que nos permitiría aspirar a ser una sociedad puntera en este ámbito.
España tuvo diferentes oportunidades en su historia de convertirse en productor de software. No las aprovechamos. El sector del software está en gran parte asociado a servicios basados en lo que otros producen. Empiezo a temer que este va a ser el camino predominante en el caso del Software Libre.
¿Cambiará el Software Libre la realidad de España como país asociado a servicios o podremos convertirnos en productores?
Los grandes consumidores de software en nuestro país deben asumir riesgos hoy para generar riqueza a su alrededor, que les permita ser más competitivos mañana. Y no hay mejor forma de conseguirlo que la de fomentar la producción de Software Libre entre sus proveedores, así como en sus propias organizaciones.
Los actores que una vez se unieron para alzar su voz en favor del uso del Software Libre  deben cambiar su discurso focalizándolo en los verdaderos beneficios de este movimiento, que, de nuevo, no vienen del ahorro de costes en su consumo, de las libertades asociadas a su uso y su distribución, sino de aquellas asociadas a su modificación y distribución de obras derivadas.
El esperado repunte en el consumo interno de tecnología que deberíamos ver los próximos años necesita acompañarse de estímulos para la producción propia, así como un cambio cultural que nos permita valorar en su justa medida a productores de software frente “al canal”.
El Software Libre es una oportunidad para cambiar nuestro estatus a nivel mundial como productor de tecnología. No veo signos claros de que lo estemos aprovechando. Consumir Software Libre es bueno. Producirlo es mucho mejor.

¿Por qué España no es una potencia en software?

¿Por qué España no es una potencia en la industria de software?

Una explicación se encuentra perfectamente reflejada en este artículo: Management is not a promotion.

De vez en cuándo me realizan esa pregunta o algunas similares. Mi respuesta a menudo es:

¿Cuántos ingenieros de software de 50 años conoces en España que sigan echando código? ¿Y cuántos de ellos trabajan más allá de multinacionales y la Universidad?

Durante los años en los que participé activamente en el nacimiento y consolidación del tejido empresarial relacionado con el Software Libre en España insistía, junto a algunos de mis compañeros de viaje, en la idea de la promoción de la carrera profesional de ingeniero de software dentro de las empresas como vehículo de cambio.

Creo que las empresas de Software Libre tienen la oportunidad de ser pioneras, no sólo en el área de la tecnología o de los modelos de negocio, sino tambíen en este apartado. Creo firmemente que no es posible adquirir la cultura colectiva necesaria para convertirnos en productores de software si no reconocemos:

  • Que la excelencia requiere pasión y años de experiencia. La excelencia debe reconocerse tanto como la productividad.
  • Que si no estableces una camino para que los ingenieros promocionen dentro de tu empresa como lo que son, ingenieros, la mayoría de ellos se pasarán a la gestión o se irán a empresas (más grandes), donde puedan seguir haciendo lo que más les gusta. En ambos casos todos perdemos.

Some previous ideas about building new ecosystems around free software projects (I)

There are a few free software projects out there that have been very successful through the years in attracting developers and building awesome development environments. KDE is one of them. Every new version of our KDE 4.x series is the result of a complex proccess made by hundreds of people working remotely as a well structured group of coordinated teams. We haven’t stop growing during our 15 years of existance and the impact and scope of our work is now wider than ever. Several other free software projects are experimenting similar behaviors.
The result of our huge work has a great technical and commercial value. It is also a good testing/learning field for the people involved. Their professional careers add value by becoming part of projects like KDE. Big corporations are aware of this and it is common to see them hiring people in community events or trying to influence free software projects in many ways. 
Relations between mature free software projects and big companies have been always complex. Along with the growth of free software in market, conflicts are increasing since corporations are adding more pressure into community projects. Many of them are commercializing products/services based on technologies supported or developed by these communities and we do not always have the same goals. The recent conflicts between GNOME/Canonical, KDE/Nokia, Kernel/Google, MeeGo/Nokia-Intel, LibreOffice/Oracle, MySQL/Oracle are just some examples. More are yet to come.
On the other hand, these multinational companies had put resources and money on our projects allowing us to become what we are now. By using and building their strategies around our/their work, they have helped us to reach millions of users. We do have a huge impact because of them too.
Smaller companies: new players
During the last few 3-4 years we are experimenting how some smaller companies are becoming part of our ecosystem. Some of these companies fit very well because they were founded by community members, but some others simply understand the benefits of building their products and services staying close to the decision forums, adding resources to the development proccess, so they ensure they know the technology. This small but innovative companies usually have a strong free software culture. Their size do not allow them to have their own strategy around the technology so becoming part of our ecosystem is a major goal for them, not a temporary effect of his own strategy.
The irruption of these smaller companies is also good news for corporations. It is easier for them to build a commercial and development channel laying in companies that participates in the development of the technology they use. Since software is getting more and more important, every helpful hand is welcome.
So it is easy to end up thinking about how good it would be to increase the number of smaller companies involved in our free software projects.
Grow locally
In parallel to this, KDE, and other community projects, are increasing their efforts of reaching potential contributions and users in their own language, taking in consideration the local culture. Some community projects are getting so big that some actions in the management/organization side must be taken to keep being efficient and flexible.
Like others, KDE is going through a process of organizing local communities around legal entities related with the matrix. The experience is telling us that some advantages and positive effects are taking place as a result of reducing the barriers for people to get involved in the project. There are many, but language and culture are huge ones. Another one that is not frequently mentioned is that people wants to relate to each other face to face, at least once in a while. National events, like Akademy-es, represent a definitive step for a developer to end up contributing actively to the global project.
Like in economy, the communities are built around poles that get connected to each other. If some developers are in the same geographical area, personal relations allow a pole to grow faster and stronger. We have a very good example of this process in Spain with Barcelona or in France with Toulouse. Also this helps to explain why we haven’t been able yet to become in the US as successful as in other parts of the world.
It is easy to think how would it would be to speed up this process since the results look promising.
Non-profits as key partners
Every mature free software project have relation with some stakeholders that, eve though are not communities of developers, they are key players: non-profit organizations. These relations are not structured and too often have lay on personal efforts. Free software communities are very technology centric and most of those non-profit don’t, so relations are not based on personal interest most of the time, but in the defense of free software (general idea).
But both, those non-profits and free software projects, are aware of how important is to stay close to each other, specially with so many viruses out there waiting to infect us.
But beside those non-profits that are very related directly on indirectly with free software,there are many more that we can contacted to build a very valuable relation. International cooperation or science centered organizations are among them.
So once again, it is easy to end up thinking how good it would be to increase the number and intensity of our relations with non-profit organizations.
Colleges: strategic partners
Most of the new contributors free software project attract are students from colleges. They have the time and energy to learn. Projects like KDE are perfect for them to develop new skills, useful in their professional careers. Only in very few companies a student can become part of such a complex environment, using such innovative tools, surrounded by high skilled people…..for free (not even paying, probably).
Teachers play a key role for us. Experience tell us that, where there is a teacher involve in our project, many new contributors arrive. Colleges are usually involve with local companies and somehow influence in the decisions they take related to technology. In order to create poles, they are the perfect host.
Every free software project have relations with colleges, but most of those relations are also based on personal relations between community members and some teachers. Maybe the same person plays both roles.
So, yes, again, it is easy to end up thinking how good it would be to increase our relation with colleges around the world.
Building a new ecosystem 
In order to ensure our independence in the future, keep growing and increasing our impact, we will need to find out ways to establish structured relations with these 3 type of organizations:
  • smaller companies (SME from now on)
  • non-profits
  • colleges (including similar institutions).

Some of the principles and procedures we are using now successfully in our relations with developers from our own projects and other communities might not work perfectly with these organizations. They talk different languages and we will need to find ways to create a new field with different rules, so they they join our game, a game based in our classical strong principles.
If we agree that engaging developers is easier if you have a strong local structure, it make sense to think that maybe the same aproach can work with organizations.
This new ecosystem, within our community, will be the result of going through a new process that will have, at least, three different phases:
  1. Creating a structured and coordinated program (the rules).
  2. Building up a network with those organizations (the field).
  3. Evolving into an ecosystem (the game).

We have to be aware of the difference between an ecosystem and a community. It seems to me it will be a basic element to consider. 
All the above is quiet obvious and, like in KDE, almost every free software project has been taking steps toward this direction. The recent MeeGo/Tizen affaire has made the need to push forward these kind of actions even more obvious.
How do we design that structured and coordinated program? How do we make it compatible with our goals? It will be possible with our limited resources? What do we want from these organizations? What can we offer to them? How do we make such a program sustainable? How do we handle our differences? Is such a new ecosystem going to affect us? How? Are we prepared?
I’ll write about some ideas I have in the following days related with the above questions.

Software Libre: reducción de costes mediante el análisis preventa

¿En cuántas ocasiones has adquirido un software que no ha satisfecho tus expectativas?¿Cuántas veces has adquirido un programa que luego tus empleados no usan?¿Cuántos sustos te has llevado al comprobar ciertas incompatibilidades de tu nuevo programa con otros que ya tenías?¿Cuántas veces te han vendido un software tecnológicamente obsoleto?¿En cuántas ocasiones has debido cambiar de máquina al adquirir un nuevo programa sin tras implantarlo?¿En cuántas ocasiones has adquirido servicios asociados a un programa que no necesitabas?¿en cuántas ocasiones, buena parte de los problemas detectado en tu software son lo suficientemente simples de resolver como para que lo haga tu propio personal?¿Cuántas veces has tenido que pagar grandes cantidades de dinero para que el vendedor te realice una consultoría completa previa orientada a conocer la idoneidad de un producto y los problemas que se te pueden presentar en un futuro, teniendo personal cualificado en casa para hacerlo?
En un sector en el que el negocio estaba basado en la exclusividad y la limitación al acceso de información, el comprador estaba completamente a merced del vendedor, del canal. La tiranía del proveedor comenzaba desde el minuto en que el comercial ponía el pie por primera vez en tu empresa, antes incluso. Él lo sabía todo y tú no sabías nada. Cualquier persona con cierta habilidad y experiencia sabe sacar provecho de esa situación. En general, el análisis preventa era realizado por la misma empresa que te realizaba la venta o, en casos donde la inversión era alta, por entidades “independientes”. En muchas ocasiones, esas entidades, para poder realizar consultorías de verdad sobre un producto o tecnología, tenía que ser parte del propio canal del fabricante, lo supiera el cliente o no.
¿Cómo iban a acceder a la información clave de otro modo?
No parece razonable abrazarse al vendedor por completo disponiendo de un departamento de informática en tu empresa. La estrategia en la adquisición de Software de cualquier empresa debería contemplar mecanismos por los cuales un potente análisis de preventa fuera requisito indispensable como paso previo a la selección de tecnología, producto, servicio y, en último extremo, de proveedor. Un buen análisis preventa ahorra costes en multitud de ámbitos en el ciclo de vida de un programa que se implanta en la empresa. En caso de no disponer de dicho departamento, no ser experto en el área que se pretende cubrir, o no disponer de tiempo para dicho análisis, poder acudir con confianza a entidades externas, que nos puedan realizar dicho análisis con total independencia, es una garantía de éxito. Si la inversión pretendida es alta, una combinación de ambas estrategias es, con seguridad, la mejor opción.
Esta estrategia de adquisición de Software tiene un impacto mayor en el apartado de costes si se apuesta por el Software Libre. Ese impacto se multiplica si la apuesta es por Software Libre liberado.
¿Por qué?
Identificación de tecnologías/productos que responden a priori a la definición de requerimientos
Tras la realización del correspondiente análisis de necesidades, si dispones de un departamento de informática, su personal podrá buscar en la red soluciones que se ajusten a las necesidades detectadas en multitud de casos. Utilizando los recursos más populares de búsqueda de soluciones (ver apartado 3.3. del artículo publicado en mi blog el pasado mes de junio, por ejemplo ) es probable que puedan encontrase distintas soluciones que, aparentemente, puedan cubrir buena parte o completamente, las necesidades detectadas.
Se puede solventar así un primer problema de difícil resolución si no se está muy encima de la oferta del mercado. Muchos alegan desde el mundo privativo que el exceso de oferta es un problema del Software Libre, que cuesta dinero al cliente. A mi me cuesta pensar que el aumento de oferta aumente costes si se analiza todo el ciclo de vida del Software. Es cierto que, si la oferta es baja, el proceso de toma de decisión es más simple y cuesta menos, pero a medio plazo aumenta los costes…seguro.
Uno de los puntos más relevantes a la hora de definir una estrategia de adquisición de Software en el que el análisis de preventa se realice internamente es que los indicadores habituales en los que se basaba este análisis deben complementarse con otros nuevos que son determinantes. No es posible analizar los productos libres utilizando únicamente la mismas variables con las que se analizaba el privativo. Deben introducirse nuevos indicadores y otros tradicionales pierden relevancia (no desaparecen).
Echo aquí de menos una apuesta firme de CENATIC para, junto al sector, realizar un estudio de definición y análisis de estos nuevos indicadores, con casos prácticos, y el impacto que sufren los indicadores tradicionales en el ciclo de vida del software, pero muy especialmente, en el proceso de adquisición. Este tipo de trabajos tendrían un impacto enorme en el mercado, si se apoyan en la experiencia del sector.
Para quienes no entiendan a qué me refiero, pueden ver el apartado 3.1 del artículo publicado en mi blog el pasado mes de junio 
Asumamos que el departamento de informática posee alguna persona que conoce en profundidad los modelos de desarrollo y comercialización de Software Libre, de modo que sabe identificar y analizar estos nuevos indicadores. Así, tras un análisis previo de los mismos, la selección de tecnologías y productos posibles que cubran las necesidades de la empresa se reducen en gran medida. Si no es así, acabas de identificar un problema a resolver de cara a cambiar tu estrategia a medio plazo, adaptándola a lo que dicta el mercado. El Software Libre está aquí para quedarse y puedes aprovecharlo, pero necesitas personas cualificadas en este ámbito.
Descarga, instalación, realización de pruebas y análisis de las tecnologías y productos candidatos
Una vez identificados los candidatos (Software Libre) podrás descargar, instalar y analizar tecnologías y productos finales o bien, versiones básicas de los productos que finalmente vas a adquirir. Cuando hablo de versiones básicas, no me refiero a versiones limitadas, sino a productos sobre los que las empresas construyen personalizaciones y adaptaciones a cliente. Es decir, es posible o incluso probable en algunos casos que no dispongas del producto final, pero desde luego vas a disponer de algo cercano sobre el que poder basar tu análisis con absoluta confianza.
El proceso de pruebas técnicas de los productos identificados como “posibles soluciones” debe complementarse con otro tipo de análisis por parte de otros departamentos de la empresa. Por ejemplo, es importante que las personas encargadas de la formación del personal analicen los productos que han pasado la criba técnica con el fin de predecir los costes que, en este ámbito, deberá soportar la empresa para cada solución. También es posible realizar internamente tests previos de usabilidad, con el fin de analizar superficialmente el impacto en los usuarios de las opciones planteadas. Puedes evaluar la integración con otros servicios ya disponibles en la empresa…
En definitiva, hay multitud de “costes ocultos” que es posible predecir en mayor o menor medida como parte del análisis preventa si se opta por la adquisición de productos libres, más allá de los derivados directamente de indicadores técnicos.
Llamo la atención sobre el hecho de que las empresas tienen cierta tendencia a abrazarse a una única tecnología, lenguaje o marca. Las condiciones de mercado que imponía el software privativo convertía esta estrategia en la más inteligente….hasta el momento en que algún factor externo daba al traste con ella. Poner todos los huevos en la misma cesta es bueno para el proveedor y, a través de una política de costes de adquisición “ventajosa”, se lo hacía creer al cliente. El Software Libre permite flexibilizar esta política permitiendo a las empresas reducir los riesgos derivados de factores externos y estableciendo una política que, a medio plazo, le ahorre costes. Reducir riesgos no tiene por qué costar más dinero. Sí implica disponer de más control y eso requiere personal más cualificado. Ese personal más cualificado, si dispone de acceso a la información clave, tiene mayores posibilidades de tomar buenas decisiones, y eso siempre ahorra dinero.
Y si no lo hace, será por errores propios, no por decisiones ajenas.
Digo esto porque son muchos los departamentos de informática de empresas que tienen muy arraigada esta política “monomarca”, y proveedores también, incluso dentro del Software Libre. El análisis preventa puede estar tremendamente condicionado por esta circunstancia. El mismo destornillador no sirve para todos los clavos en todas las superficies.
Las pruebas técnicas a realizar son innumerables. Desde el análisis del propio código hasta pruebas de carga, pasando por la interoperabilidad con los sistemas ya consolidados en la empresa, la documentación asociada al propio código o la adición de funcionalidad en forma de módulos o desarrollo propio. Asimismo, es posible realizar análisis de nuevos indicadores, igualmente relevantes a la hora de determinar cual es la mejor opción. En definitiva, con la cualificación adecuada, es posible que la empresa pueda conocer una determinada tecnología o producto en detalle antes de iniciar el proceso de identificación de proveedor, análisis de su experiencia y estudio de oferta. Insisto en el hecho de que es muy recomendable acudir a expertos que complementen ese análisis desde la experiencia demostrable y la independencia.
Pero las ventajas del Software Libre en lo que a reducción de costes a lo largo del ciclo de vida del software se refiere gracias a un buen análisis de preventa, no acaba con el análisis de la solución y la tecnología sobre la que está hecha. Incluye también la identificación y análisis del proveedor.
Identificación y análisis de modelos de negocio basados en Software Libre.
En una relación personal, es necesario conocer las motivaciones de la otra persona, sus inquietudes y miedos, para poder entender sus reacciones, y actuar en consecuencia. Es un elemento clave para comprender la relación y convertirla en estable y duradera, esto es, en satisfactoria. En las relaciones profesionales pasa lo mismo. Es necesario entender las motivaciones, los riesgos, las fortalezas y las debilidades del proveedor para actuar en consecuencia, de modo que la relación sea estable … o no sea.
La transparencia es un elemento clave para la generación de confianza. Las relaciones de canal han estado tradicionalmente basadas en la confidencialidad de los términos de la relación. En el mundo del software, además, los principales beneficios del canal venía dados por el lock-down del cliente, generando la la venta continuada de servicios “de repetición” sobre un producto cuya venta dejaba un escaso margen al vendedor. La “fidelización” del cliente a través de un producto no surgía por casualidad. El fabricante diseña esa estrategia y el canal la ejecuta…y muy bien por cierto.
El análisis preventa puede y debe averiguar en gran medida cómo es la relación entre quienes fabrican el producto/tecnología, quienes la personalizan y quienes la comercializan. Esto permitirá a la empresa cliente conocer cómo es el modelo de negocio del proveedor, comprender la oferta que realiza éste, donde están los puntos fuertes de la misma y los puntos débiles, más allá del precio. Se podrán así analizar, comprender y, en último extremo adaptar, las condiciones que impone el proveedor, dentro de un marco asumible por ambas partes, en beneficio de una relación estable. Si la empresa asume una estrategia de toma de control en el ámbito TIC una inadecuada negociación con el proveedor puede dar al traste con la misma. Incluso en el caso de que se adquiera Software Libre. Ahora, con Software Libre existen proveedores, no sólo dispuestos a asumir esa estrategia del cliente, sino a promocionarla, de modo que puedan, además de convertirse en proveedores de sus tecnologías/productos/servicio, participar como elemento clave en su evolución tecnológica, transfiriendo conocimiento y experiencia en ambas direcciones de un modo imposible con anterioridad.
Este tipo de conocimiento de los modelos de negocio asociados a la tecnología/producto/servicio que una empresa quiere contratar, tras el pertinente análisis previo realizado, ayuda enormemente en la negociación y suele ser bienvenido entre los proveedores, contrariamente a lo que pueda parecer. Casi todos ellos han adaptados sus modelos de oferta a un mercado acostumbrado el Software Privativo, pero eso no significa que no se sientan cómodos con clientes que pretenden establecer relaciones comerciales basándose en otros modelos, más adaptados a sus propios mecanismos de producción de software y prestación de servicios derivados. Es más bien al contrario.
Identificación de proveedores y análisis de oferta.
Finalmente llegamos al proceso de identificación de proveedor y negociación de la oferta. Un buen análisis preventa acerca la demanda a la oferta. Hasta ahora, a menudo ese análisis previo lo venía realzando el propio proveedor. ¿Alguien duda de que se repercute en el precio de ese análisis en el coste del producto/servicio? Pues se hace siempre que se puede, en el momento de la adquisición En ocasiones, para ser competitivos, se repercute en los costes de mantenimiento u otros. Cualquier proveedor desea que el posible cliente tenga un buen análisis de preventa realizado, sepa lo que compra, por qué lo compra y, sobre todo, sepa con cierta exactitud lo que quiere. Ahorra tiempo, esfuerzo, costes….y genera confianza. No conozco ninguna empresa que no quiera trabajar con empresas de ese estilo. El desconocimiento y la ingeniería no se llevan bien.
El análisis de preventa es un valor de mucha importancia en la selección previa del proveedor porque ahorra tiempo y esfuerzo a ambas partes. Asimismo, permite una mejor identificación de los proveedores expertos y consecuentemente, ayudará a elegir entre las diferentes opciones que se plantean con mayor precisión. Todo esto tiene repercusión en el coste de manera inmediata o a medio plazo. en cualquier caso, reduce los riesgos y, en caso de conflicto, se dispone de una información muy valiosa de cara a la necesaria toma de decisiones.
En el Software Libre existen fórmulas para identificar proveedores más allá de las que determina el canal. Estas fórmulas no son perfectas ni generalizables a todos los casos, pero son eficaces. Sabemos que los canales tradicionales en el mundo del Software privativo vienen tan determinados por los volúmenes de venta como por la excelencia. Estos factores pueden estar relacionados…o no. Conocer estrategias y técnicas orientadas a identificar proveedores de productos/tecnologías que hemos analizado y queremos adquirir es un elemento básico para optar al mejor producto/servicio. Si no sabemos o queremos hacerlo, podemos apoyarnos en entidades intermedias como ASOLIF o en consultores externos.
Una vez identificados los posibles proveedores, se inicia la fase de negociación de ofertas. Quizás el factor que más influye en este apartado, además de conocer con cierta exactitud lo que el cliente quiere/necesita, es la flexibilidad. Dado que las condiciones de canal en el caso de proveedores de Software Libre son más flexibles o nulas, el resultado de la negociación tiene más posibilidades de adaptarse a los requerimientos de ambas partes. Ya no sólo puedes negociar el precio. Ahora la negociación puede abrirse a otros muchos apartados.
Una vez más, desde el mundo privativo, se ataca al sector del Software Libre acusándole de su falta de paquetización de la oferta, lo que limita sus posibilidades de venta a gran escala. Siempre me ha hecho gracia este argumento. La flexibilidad nunca es negativa, ni para el proveedor ni para el cliente, como punto de partida. Te permite elegir. Hasta ahora, las empresas de Software Libre en España han crecido atendiendo una demanda insatisfecha, debido en cierta medida, a la rigidez del mercado del software impuesta por el modelo privativo basado en canal “con escaso valor tecnológico”. Pero eso no quiere decir que sector de fabricantes de Software Libre no sea capaz de adaptarse a modelos de oferta rígida (paquetización de la oferta) para venta a gran escala, incluso internacional. De hecho, comienzan a aparecer ejemplos en España que confirman esta idea.
Una de las enromes ventajas que aporta el Software Libre al cliente es la posibilidad de realizar un estudio de preventa detallado encaminado a tomar decisiones de manera interna en materia TIC, acordes con una estrategia de adquisición de mayor control y flexibilización de costes.
Apoyar esa estrategia con la adquisición de Software Libre, realizando un análisis previo, es decir, un análisis de identificación de requerimientos, identificación de posibles soluciones, realización de pruebas técnicas y funcionales de las tecnologías/productos candidatas, identificación de costes ocultos, identificación de proveedores y adaptación del proceso de negociación previo a la compra, tiene un impacto enorme en la inversión realizada por la empresa en un software a lo largo de todo su ciclo de vida. Ese impacto debe ser compatible con aquella estrategia en materia TIC, si así lo desea el propio cliente. Y si quiere delegar parte o la totalidad de esas decisiones, el Software Libre le permite acudir a terceros que puedan realizar ese análisis de modo independiente al canal.
Muchos departamentos de informática han vivido siempre bajo la política de la delegación en el proveedor de multitud de decisiones que afectaban de manera crítica a su empresa. Consciente de lo vulnerable de su situación, el responsable de la compra recurría a menudo a la selección de “proveedores fiables” que formaban parte de un canal basado en ventas, fundamentalmente. Ese modelo era rígido y derivaba con frecuencia en costes poco sostenibles en el tiempo. Como hablamos de software, hecho por personas, esta política no garantiza tampoco inmunidad a errores y, dependiendo del volumen de la inversión del cliente, no favorecía una atención personalizada de garantías.
El Software Libre abre la puerta a modelos diferentes. Uno de los elementos clave para implantar esos nuevos modelos es la inclusión dentro de nuevas estrategias de análisis de preventa, como paso previo e ineludible a la recomendable toma de control de las decisiones críticas en el ámbito TIC por parte de las empresas.