Les réflexions sur le Business Model conduisent naturellement à s'interroger sur la question de la valeur apportée par notre solution.
Pour bien comprendre cette notion, il est essentiel de considérer :
-
que cette valeur est toujours relative à une solution concurrente: notre solution de développement adresse un marché mature, où il existe pléthores de solutions concurrentes et où du développement spécifique est toujours possible. Il est donc important de bien savoir avec quelles solutions concurrentes la comparaison de valeurs est réalisée.
-
que cette valeur doit s'estimer du point de vue du client: elle s'exprime par les bénéfices moins les sacrifices perçus par l'usage de la solution. Ces sacrifices ne sont jamais nuls, il est important de les intégrer dans la comparaison.
-
que cette valeur est une valeur d'usage, qui doit intégrer un usage sur le long terme. Nous adressons des Systèmes d'Informations qui sont prévus pour durer, la valeur d'usage doit être projetée sur un axe temps. La mise en situation est essentielle pour permettre cette projection qui n'est pas évidente. Le vieillissement d'un SI est toujours très difficile à anticiper. 2 questions peuvent aider pour faciliter la projection dans le futur:
-
Comment pourrais-je faire évoluer mon SI face à n'importe quel changement demandé par les utilisateurs ?
-
Que vais-je pouvoir réutiliser dans des applications futures et Quels sont les éléments sur lesquels je vais pouvoir capitaliser ?
-
que cette valeur se mesure essentiellement en comparant et en chiffrant:
-
le coût du développement, qui se mesure essentiellement avec du temps passé, mais pas seulement; d'autres éléments interviennent, car notre approche a aussi des impacts sur l'organisation et la réduction des spécifications notamment.
-
la qualité du développement réalisé car une ligne de code écrite est toujours source potentielle de bug, et ce point est important lorsque l'on compare avec du développement spécifique.
-
le coût de la maintenance, car le code écrit ou généré est toujours plus difficile à faire évoluer que quand il n'y a pas de code du tout. Ce coût est évidemment plus important pour du développement interne que par rapport à l'achat de produit, qui sera mutualisé par plusieurs clients.
Depuis le début de notre développement, notre ambition et objectif se résume assez simplement à écrire le code "bête" une fois pour toute et à laisser le code "intelligent" à écrire pour l'application. Par code "bête", on désigne le code "technique", qui est connu d'avance, quasiment toujours la même chose, qui évoluera peu avec le temps, et par code "intelligent", on désigne le code "métier", qui est flou et peu connu d'avance, et qui évoluera fortement avec le temps. Notre valeur d'usage s'évalue donc par la quantité de code éliminé par notre solution, ce qui n'est pas immédiat, parce que notre approche est nouvelle, et on a souvent l'impression, à tort, que le code est la solution alors qu'il est souvent le problème.
Les solutions de références sont très diverses, il peut s'agir de développements spécifiques ou de produits, qui seront principalement des Frameworks ou des générateurs de code. Beaucoup de nos fonctionnalités n'ont pas d'équivalent dans des produits packagés et la solution de référence sera du développement spécifique. La plupart - on pourrait presque dire la totalité - des solutions de références ont pour paradigme une approche OO, ce qui est notre principal facteur différenciant et ce qui nous permet d'atteindre une séparation beaucoup plus nette entre code "technique" et code "métier". Nous pouvons aller beaucoup plus loin dans l'élimination du code technique, et évitons des taches fastidieuse et répétitives de développement. En ce sens, nous apportons de la valeur, puisque nous éliminons une charge de travail couteuse, et source de risques pour la qualité du projet.
Les différents compartiments de l'Application sur lesquels nous avons une proposition de valeur, sont logiquement découpés en fonction des différentes briques de notre solution. Nous aurons l'occasion d'y revenir en détail, les fonctionnalités à estimer peuvent être listées comme suivant. Bien entendu, chaque fonctionnalité doit être pondérée en fonction de la valeur qu'elle a pour le projet, et chiffrer pour chacune des solutions envisagées:
Nous pouvons ajouter également les sujets transverses suivants:
-
Organisation: notre approche permet un découpage plus facile du projet. En rendant les pièces indépendantes, il est plus facile de découper le projet en autant de sous-projets que nécessaire. On diminue ainsi l'entropie du Système; même si cela est très difficile à chiffrer, il est important de le prendre en considération.
-
Cycle de développement: notre approche permet d'atteindre une agilité réelle qui permet d'avoir des cycles de développement extrêmement courts, de l'ordre de quelques heures. Nous favorisons ainsi l'adoption d'une approche agile sans les contraintes imposées par les méthodes agiles actuellement en vogue.
-
Architecture: notre solution est une architecture "out-of-the-box" qui propose une architecture prête à l'emploi dès le premier jour. Elle permet de s'affranchir de nombreux points à mettre en oeuvre pour mettre en place une Architecture multi-tiers. Peu de solution de références offre cette fonctionnalité, la mise en place d'une Architecture est souvent une tâche dédiée sur un projet, qui est rarement capitalisée d'un projet à l'autre avec des composants prêts à l'emploi, et plus souvent issue de l'expérience des participants du projet.
-
Evolutivité: la réduction de code technique et la non-adhérence à des choix techniques permet d'envisager une évolution future vers d'autres environnement. Ainsi, une application WinForm pourra être portée facilement en WPF, une application Web pourra être portée plus facilement en SilverLight; par "facilement" nous signifions que la logique de l'Application n'est pas remise en cause, car la logique a été complètement isolée de la technique et donc de la technologie utilisée dans l'IHM. Ce point n'est pas souvent pris en considération car peu de personnes envisagent que cette évolution est possible.
-
Intégration: la cohabitation d'une Application avec le reste du SI peut être un point clé du choix des solutions, et il est nécessaire de vérifier que l'intégration avec des applications tierces est possible dans les deux sens. En ce qui nous concerne, nos applications sont nativement .Net, elles peuvent intégrer du code spécifique à tout endroit de l'application (la récupération des contrôles, données et traitements se fait facilement), et l'appel de n'importe quel traitement client ou serveur, est toujours possible.
Parmi les sacrifices identifiés, on distingue principalement les coûts de transferts vers une nouvelle approche et une nouvelle solution, qui peuvent se détailler ainsi:
-
L'apprentissage, qui sera capitalisé sur le long terme
- L'abandon de ce que l'on possède déjà, qui est souvent survalorisé par ce que ce qui est possédé est la résultante d'une décision passée, et qui se traduit par une impression de perte de contrôle. Cette impression doit être temporaire et vite comblée par l'apprentissage rapide de la solution.
-
Les changements dans l'organisation et la méthode de développement; même s'ils sont bénéfiques à terme, un changement est souvent perçu comme un sacrifice, on préfère continuer à maîtriser ses échecs que de prendre le risque de réussir.
-
Le risque perçu par le choix d'une Start-up: "Personne ne s'est fait virer en choisissant IBM ou Oracle !", à nous d'identifier les Early Adopter qui sont prêts à travailler avec une Start-up.
Plusieurs études montrent que l'on se focalise plus volontiers sur les sacrifices que sur les gains. Ceci est légitime, car le risque de ce que l'on ne connait pas est naturellement une source d'inquiétude toujours plus forte. Il y a une asymétrie de l'information, entre ce que l'on connait et ce que l'on ne connait pas, et donc un déficit presque naturel des sacrifices perçus. Combler cette asymétrie d'information et se mettre dans une position de connaissance équivalente des différentes solutions demandent un effort, lui-même assimilé à un sacrifice. C'est à nous de combler ce déficit et d'accompagner nos prospects pour leur permettre d'évaluer la valeur apportée par notre solution avec le maximum d'informations. Ne perdons pas de vue non plus tous les problèmes actuels de dépassement que connaissent la grande majorité des projets de développement. Les "Pain Point" que nous adressons sont bien des surcoûts que nous éliminons.
Finalement, la décision d'acquérir une solution innovante de développement se mesure par une mise en situation et la réalisation d'un projet pilote, qui permettront la mesure des différents gains et sacrifices des différentes solutions pour calculer la Valeur d'Usage de notre solution, et montrer qu'elle est supérieure aux solutions concurrentes.