Article traduit de https://www.linkedin.com/pulse/case-aginst-custom-developments-fabien-pinckaers/

La clé des implémentations d’ERP : Gérer les attentes des clients

Je suis un développeur. J’aime développer, c’est amusant et intellectuellement stimulant.

Mais, en tant que PDG d’Odoo, je sais aussi que, pour les projets de mise en œuvre d’ERP, les développements sur mesure doivent être évités autant que possible.

Ce n’est pas aussi facile qu’il n’y paraît quand les clients pensent souvent qu’ils ont besoin de développements personnalisés. D’autre part, les sociétés de services d’implémentation sont heureuses de facturer des jours supplémentaires pour ces personnalisations. Mais je dois avertir les deux parties, les développements sur mesure ne sont pas bons pour vous !

Pourquoi minimiser les développements sur mesure ?

Pour les clients, les développements sur mesure ajoutent des coûts et du temps au projet d’implémentation, parfois au point de mettre le projet en danger. De plus, le développement sur mesure entraîne une dette technique que vous aurez à payer dans les années à venir : plus de coûts de maintenance et de mise à niveau. Une telle dette technique coûte environ 25% des coûts de développement CHAQUE ANNÉE (~17% en maintenance + ~8% en amélioration).

Chaque développement peut sembler simple et abordable. Mais la complexité d’un projet augmente avec le carré du nombre de personnalisations, pas linéairement. Vous voulez probablement résoudre ce que vous n’aimiez pas dans votre logiciel précédent ; mais ne serait-il pas préférable de standardiser vos processus d’affaires et de mettre en œuvre le projet 2 fois plus rapidement et à moindre coût ?

Pour les partenaires, les développements sur mesure ont généralement un coût élevé, pour une faible valeur client. Combien de fois avez-vous estimé à 10 jours le temps nécessaire pour développer une fonctionnalité ; le client pense que c’est trop pour une fonctionnalité si basique que vous ne chargez que 8 jours ; mais vous finissez par passer 12 jours. Oh, et quand nous découvrons des problèmes/changements plus tard parce que vous avez dû le faire rapidement, le client ne paiera pas pour la journée supplémentaire car c’est votre faute. Ce qui aurait dû être un service à 35 % de marge est maintenant une perte de service de 6 % !

Pour croître, il est plus facile de se concentrer sur des services de valeur ayant de meilleures marges et de réduire le risque d’heures non facturables. Ces services comprennent la gestion de projet, l’analyse d’affaires, la personnalisation sans développement, la gestion du changement et la formation.

Si vous ne développez pas une mentalité de réduction des développements personnalisés, tôt ou tard, vous deviendrez non compétitif. Les concurrents qui gèrent mieux les attentes des clients auront des coûts de mise en œuvre du projet plus faibles. Avez-vous déjà perdu un projet parce que le client a dit “vous êtes trop cher”, pour découvrir que le client a acheté beaucoup moins que ce que vous auriez livré ?

Bien sûr, des développements sur mesure sont parfois nécessaires pour gérer l’entreprise. Mais, d’après mon expérience, la majorité des demandes des clients ne valent pas le coût pour eux, ne sont pas pertinentes une fois qu’ils commencent à utiliser Odoo, ou ils peuvent s’en passer car cela ne fait pas partie de leur utilisation principale. Acceptez-vous ces demandes ou non ? Tout dépend de votre méthodologie d’implémentation et de l’état d’esprit de votre entreprise.

Le client n’est probablement pas un expert du produit, et probablement pas non plus dans les projets de mise en œuvre. Ils ne peuvent donc pas facilement équilibrer le coût d’une caractéristique particulière en fonction des recettes qu’ils en tirent. Les demandes des clients sont basées sur les défis qu’ils ont eus avec leur ancien logiciel ou leur façon actuelle de travailler. La plupart de ces problèmes sont atténués ou ne s’appliquent plus une fois qu’ils sont passés à l’utilisation d’Odoo.

Il n’est pas facile de définir le bon équilibre entre les développements standard et personnalisés. Ce qui n’en vaut peut-être pas la peine pour un client peut être très précieux pour un autre.

Si vous demandez aux entreprises de services, elles vous diront toutes qu’elles ne développent que ce dont le client a besoin (et elles pensent vraiment qu’elles le font). En réalité, il est très difficile de s’évaluer soi-même et de savoir si l’on est bon pour évaluer le rendement des investissements et résoudre les problèmes avec des conseils commerciaux plutôt qu’avec des développements.

Pour comprendre les différents états d’esprit, examinons la structure de mise en œuvre de deux sociétés de services.

Cas 1

Si une entreprise a 8 développeurs pour 2 chefs de projet, leur objectif est de faire des développements sur mesure. Leur méthodologie est probablement scrum (ou une autre agile), et leur chef de projet passera le plus clair de son temps à écrire des spécifications et à tester des développements. Ils satisfont les clients en développant, mais cette approche conduit inévitablement à une augmentation du coût et de la rapidité du projet (et non à dessein, bien sûr). Les clients sont satisfaits à court terme (car ils obtiennent tout ce qu’ils demandent), mais pourraient être insatisfaits à mesure que les coûts et les délais augmentent.

Cas 2

Une entreprise comptant 2 développeurs et 8 hommes d’affaires (analystes ou chefs de projet) se concentre sur les services aux entreprises : gestion du changement, ingénierie des processus d’affaires, recherche de solutions standard aux problèmes commerciaux, formations. Ils auront des comptables, des gestionnaires d’inventaire ou d’autres experts dans leur équipe qui pourront contester les demandes des clients. Ils satisfont les clients parce qu’ils fournissent une valeur très élevée à un très bon prix. La plupart des clients aimeront l’approche, mais certains pourraient être frustrés à court terme lorsque vous remettez en question ce qu’ils demandent. En revanche, ces clients seront très satisfaits à moyen terme à mesure que le projet avancera.

Quel est le juste équilibre entre Cas 1 et Cas 2 ? Malheureusement, il n’y a pas de point de repère.

Chez Odoo, nous disposons d’un département de service composé de développeurs, de chefs de projets et d’experts métier. Au fil des ans, nous nous sommes concentrés sur l’amélioration de la rapidité des projets, plutôt que d’essayer de vendre plus de services à l’avance.

Voici la taille de notre équipe pour nos projets d’implantation directe :

• Pour les petits clients (1-50 utilisateurs), nous avons 11 développeurs pour 80 chefs de projets et analystes d’affaires. Ainsi, 12 % ont un profil de développeur.
• Pour les grands projets (>500 utilisateurs), notre ratio est plus proche de 50% de développeurs, 50% de non-développeurs.
• Ou, vous pouvez le voir d’une autre façon ; sur les projets de petite et moyenne envergure, en moyenne, 12 % de notre temps facturé est consacré au développement, 88 % aux services aux entreprises.

En tant que client, cette simple astuce de vérification de la taille des équipes vous aidera à évaluer votre partenaire potentiel en fonction de vos attentes. En tant qu’entreprise de services, faites le calcul avec votre propre taille d’équipe. Ce ratio vous indiquera si vous avez des marges d’amélioration pour augmenter vos marges et la vitesse de votre projet.

Si votre ratio est 2 fois plus élevé que celui-ci, il vaut la peine de réfléchir à vos méthodologies, votre modèle économique et le profil de vos prochains recrutements. Un bon point de départ est la “méthodologie d’implémentation” d’Odoo.

Comment répondre aux demandes spécifiques des clients ?

Lorsque vous traitez avec des clients, n’oubliez pas qu’il y a une différence entre les objectifs des parties prenantes et les besoins des utilisateurs clés. La plupart des décideurs vous diront que leur priorité est le temps et le budget, tandis que les utilisateurs clés réfléchiront surtout en termes de caractéristiques spécifiques à développer. Comme ces objectifs se contredisent, c’est à vous de décider : qui voulez-vous satisfaire ?

Je pense que vous devriez toujours faire ce que vous pensez être bon pour le projet ; cela signifie remettre en question ce que les utilisateurs clés demandent, au point de refuser de le faire si vous pensez que cela ne vaut pas la peine. Essayer de satisfaire la demande des utilisateurs clés en faisant tout ce qu’ils demandent est un état d’esprit à très court terme ; il est préférable de se concentrer sur le succès du projet.

J’utilise le cadre suivant pour traiter les demandes de développement personnalisé :

• Est-ce vraiment nécessaire ?
• Vaut-il la peine d’en supporter le coût (de développement et de maintenance) ?
• Le gain est-il assez important ?
• Pouvons-nous servir le même objectif, avec une approche différente ?
• Si vous en arrivez à la conclusion que le développement d’une fonctionnalité spécifique n’en vaut pas la peine, vous devriez vous efforcer de convaincre le client. Il y a différentes tactiques pour cela : expliquer le “pourquoi”, le mettre en phase après la mise en ligne, le faire passer à un manager (bien que ce ne soit pas idéal, c’est parfois nécessaire).

Est-ce vraiment nécessaire ?

Supposons que vous ayez une demande pour le développement personnalisé suivant :

Le client dispose d’un site développé avec Magento Commerce et ne souhaite pas changer son site car il y a déjà beaucoup investi. Mais ils aimeraient qu’Odoo soit complètement intégré à leur site Magento (produits, coupons, suivi des paniers abandonnés, etc.).

La meilleure façon d’évaluer si c’est nécessaire est de vérifier si le client possède déjà cette fonctionnalité dans son ancien logiciel. Si le client enregistre toutes les commandes manuellement dans son ancien logiciel, il peut le faire de la même manière avec Odoo. Je recommanderais alors d’entrer en production sans développer d’intégration avec Magento, d’utiliser Odoo pendant 3 mois, puis de revoir les priorités et de décider si cela en vaut la peine (à ce moment-là, vous avez 50% de chance que le client aime tellement Odoo qu’il optera pour Odoo eCommerce plutôt que pour un connecteur pour Magento. :)

En matière de gestion du changement, il est toujours préférable de déployer progressivement les changements de processus d’affaires, plutôt que de tout mettre en œuvre en une seule fois. Avec la modularité d’Odoo, il est logique de déployer en plusieurs phases : 1/ Avec ce dont le client a absolument besoin pour exploiter l’entreprise et seulement après le passage à 2/ Autres caractéristiques pour améliorer l’efficacité.

En réalité, les priorités de développement du client changent lorsqu’il entre en production. Les raisons en sont les suivantes :

• En utilisant le logiciel, ils découvrent de nouveaux développements plus importants et redéfinissent l’ordre de priorité de celui-ci.
• Après avoir dépensé de l’argent pour la mise en œuvre, ils sont satisfaits du résultat et préfèrent réduire les dépenses pour des fonctionnalités inutiles.
• Lorsque le client commence à utiliser Odoo en production, son état d’esprit change au fur et à mesure qu’il développe son expertise sur le produit.

Cela vaut-il la peine d’en supporter le coût ?

Deuxièmement, vous devez évaluer l’avantage ; combien de jours-homme par mois le client économisera-t-il grâce à cette fonction. Souvent, le client ne tient compte que du temps qu’il consacre actuellement à ce genre de tâche et des économies qu’il pense pouvoir réaliser à l’avenir. En réalité, ils devront encore enregistrer toutes les données nécessaires au calcul, traiter manuellement les exceptions, etc. Même si le client développe un connecteur Magento, il devra tout de même résoudre tous les conflits, enregistrer les remises de prix dans les deux solutions logicielles, gérer les conflits d’inventaire car la synchro n’est pas en temps réel, etc.

Ensuite, vous devez évaluer le rapport coût-efficacité. Souvent, le client ne voit que le “coût de développement unique”. En réalité, vous pouvez facilement multiplier ce coût par 2 ou 3 car vous devez prendre en compte de nombreux facteurs : temps de test, bugs et retards supplémentaires sur le projet, adaptation de la documentation car elle n’est pas standard, maintenance et mises à jour futures sur les 5 prochaines années.

Notez que l’utilisation d’un module communautaire vous permet d’économiser le temps du développement initial, mais vous aurez toujours les tests, la maintenance, les retards du projet et la mise à niveau pour tenir compte du coût. Un module communautaire est aussi une dette technique.

Le gain est-il assez important ?

Supposons que vous ayez une demande pour le développement personnalisé suivant :

Lorsque nous confirmons une commande de vente pour un projet de construction, nous voulons créer une série de tâches basées sur un ensemble de règles qui dépendent des produits, du client et des emplacements.

Lorsque vous avez une demande de personnalisation, votre premier réflexe devrait être de questionner les volumes : combien de projets de construction gagnez-vous par mois ? Disons que le client gagne 10 de ces projets par mois. Il faut probablement 10 minutes pour créer et mettre à jour les tâches en dupliquant et en mettant à jour les modèles de projet.

Vaut-il la peine de lancer un développement complexe pour économiser moins de 2 heures ou travailler par mois ? Sûrement pas, cette fonctionnalité coûtera environ 10 jours de développement, plus 25% de cette somme chaque année.

Pouvons-nous servir le même objectif, avec une approche différente ?

Supposons que vous ayez la demande suivante du client :

Je veux synchroniser notre calendrier Outlook avec Odoo CRM.

Odoo a un connecteur avec Google Agenda en standard, mais pas avec Outlook. Mais le développement et la maintenance d’un connecteur peuvent coûter très cher. Cependant, il existe de nombreux services qui synchronisent Google Agenda avec Outlook. (comme l’IFTTT) Donc, une solution serait de s’abonner et de mettre en place un tel service pour chaque employé.

Ce n’est pas parfait car vous devrez modifier votre configuration à chaque fois que vous recruterez un nouvel employé. Mais la solution est prête en 2 heures, et cela ne prendra que 10 minutes par nouvel employé. C’est encore beaucoup moins qu’un nouveau développement, si l’entreprise compte moins de 100 employés.

Note : En réalité, Odoo a un connecteur Outlook dans les applications de la communauté, nous vous conseillons donc d’utiliser celui-ci à la place. Ce n’était qu’un exemple théorique.

Si je réduis les développements sur mesure, vais-je perdre des revenus importants ?

Si vous avez 80% de votre équipe en tant que développeurs et 20% en tant que chefs de projet, vous pourriez avoir le sentiment que des développements sont nécessaires pour soutenir vos revenus. Mais les entreprises ayant 20% de leurs équipes comme développeurs ont un point de vue exactement opposé ; les services aux entreprises sont nécessaires pour maintenir les revenus et les marges.

En réalité, les clients ont beaucoup plus besoin de services fonctionnels, souvent plus que de développements. C’est juste qu’il faut trouver la bonne façon de les vendre et de les entretenir. Habituellement, une fois que le client est en ligne, le nombre de demandes de développement diminue, tandis que la demande de services aux entreprises peut continuer, si votre approche est bonne.

Bien sûr, vous ne pouvez pas passer d’un jour à l’autre ; changer l’état d’esprit d’une entreprise et sa méthodologie de mise en œuvre prend du temps. Mais si vous pouvez passer de 80/20 à 70/30, vous améliorerez vos marges. Passez ensuite à 60/40 et vous ferez un pas de plus en avant.

Ma recommandation serait de :

• Travaillez sur votre méthodologie d’implémentation (commencez par la nôtre - c’est-à-dire Odoo - si vous n’en avez pas).
• Conservez votre équipe, mais recrutez progressivement quelques analystes commerciaux ou chefs de projet supplémentaires qui n’ont pas de profil développeur.

Choses à garder à l’esprit :

• Évitez les développeurs qui font aussi de la gestion de projet. Devenir un développeur expert est difficile et demande des années de pratique. Être un grand chef de projet demande aussi du temps et de l’expérience. Si vous encouragez les développeurs à devenir chefs de projet, vous aurez des gens de niveau moyen dans les deux rôles, pas excellents dans un seul ; et avoir des chefs de projet de niveau moyen sera préjudiciable à vos implémentations.
• Éviter d’utiliser des développeurs dans la relation client. Les développeurs peuvent tout faire ; ils trouvent facilement des solutions aux problèmes techniques. Par conséquent, il leur est facile de dire “Oui” pour un développement sur mesure, car ils ne ressentent pas la douleur d’avoir à le gérer. Quand Odoo n’avait que 10 employés (principalement des développeurs), c’est ce qui m’a permis de grandir plus vite : J’ai commencé à recruter des chefs de projet sans connaissances en développement et à mieux structurer le rôle de chacun.

Si le client a choisi Odoo, n’est-ce pas parce qu’il veut toutes ces personnalisations ?

Odoo est un logiciel étonnant. Rien qu’en utilisant le standard Odoo, l’entreprise du client sera massivement transformée, pour le mieux. La plupart des ministères seront plus efficaces et les employés disposeront d’un outil pour accroître leur productivité. C’est là que réside la valeur ; les développements personnalisés ne représenteront que 5% à 10% des fonctionnalités que le client utilisera à partir de la plate-forme.

Vous devez gérer les attentes des clients, avant même de faire une offre, et le client vous remerciera d’avoir remis en question ses demandes ; c’est ce qu’il attend généralement des grands chefs de projet. Cela vous permettra de réduire le budget initial et d’être plus compétitif, tout en limitant les développements coûteux pour vous concentrer sur les marges élevées associées aux services aux entreprises.

Une fois que le client est en production et satisfait, il sera beaucoup plus susceptible d’acheter plus de vos services car votre rapport qualité/prix est excellent. Il y a tellement d’applications que vous pouvez déployer sur Odoo que le potentiel est presque illimité, vous pouvez toujours élargir la portée.

La plupart des entreprises pensent qu’elles sont uniques et spéciales, et se sentent justifiées dans leur désir de personnaliser. Ce n’est pas l’état d’esprit qu’il faut pour réussir un projet. C’est à vous de diriger le projet dans une direction axée sur la valeur qui aide le client, pas seulement ce qu’il vous demande de faire. Et ils vous récompenseront à long terme pour une telle approche. Odoo n’est pas seulement une plate-forme, ce sont les “meilleures pratiques commerciales” codées dans ce logiciel. Ces pratiques sont le fruit d’une longue expérience de travail avec les clients.

Vaut-il la peine de développer des fonctionnalités personnalisées, si elles peuvent être réutilisées sur plusieurs “futurs” projets clients ?

Dans le passé, nous avons essayé à plusieurs reprises de développer une fonctionnalité personnalisée pour un client, avec l’espoir de réutiliser cette fonctionnalité pour de futurs clients. Il a échoué dans la plupart des cas :

Les gens ont toujours l’impression qu’une caractéristique est assez générique et que beaucoup de gens la voudront. En réalité, les autres clients le voudront légèrement différent et vous finirez par gérer différentes versions de votre code personnalisé.

Cet argument est souvent utilisé par le client pour négocier un moyen de “partager” le coût d’une fonctionnalité personnalisée, ou par votre équipe interne pour justifier une fonctionnalité “non facturée”. Dans les deux cas, ce n’est pas bon pour les marges de l’entreprise.

Développer des fonctionnalités à vendre à plusieurs clients est le modèle économique d’un éditeur de logiciels (comme Odoo SA), mais c’est un modèle économique complètement différent de celui d’une société de services. C’est un modèle où vous avez besoin de 80% de marges sur vos produits pour couvrir les coûts de R&D très élevés. Il s’agit d’un modèle où plus de 50% de vos frais sont des développeurs en R&D, et non facturés aux clients.

Une entreprise de services efficace visera un taux de facturation d’environ 80 %. C’est ce dont vous avez besoin pour maintenir une croissance saine. Vous n’atteindrez pas ce niveau de taux de facturation si vous avez un modèle commercial mixte de développement de logiciels et de services.

Mes excuses

Je sais qu’un tel billet de blog pourrait ne pas plaire à tout le monde. Toutes mes excuses. Je ne veux faire de mal à personne. Je veux juste être utile. Et pour être utile, je dois être direct et transparent.

Veuillez ne pas lire ce blog comme le point de vue d’un “Software Vendor”. C’est en fait ce que nous avons appris au cours de l’année écoulée dans notre département de service, en nous concentrant sur la rapidité et la compétitivité du projet, en faisant ce que nous pensons être bon pour le succès du projet, et non ce que les utilisateurs clés nous demandent de faire. Il s’avère que ce département de service est maintenant aussi perturbateur et efficace que notre produit, au point qu’il est devenu un avantage concurrentiel énorme.

En partageant ce que nous avons appris, j’espère que cela aidera certains partenaires à accélérer leur croissance, tout comme SAP l’a fait il y a quelques années avec ASAP, la méthodologie de mise en œuvre accélérée de SAP. ASAP a joué un rôle majeur dans l’évolution de SAP et sa capacité à mettre en œuvre des entreprises complexes, dans les premières années. Un élément clé de leur approche est de s’en tenir à la norme, les “meilleures pratiques d’affaires”. Si leur approche permet de réussir des implémentations complexes avec un produit aussi merdique que SAP, imaginez ce que nous pouvons faire avec un logiciel aussi incroyable qu’Odoo !

Nous disposons d’un vaste réseau de partenaires très intelligents. Notre seule faiblesse : nous sommes plus jeunes, moins mûrs. Si nous parvenons à accroître notre maturité, nous perturberons le marché, plus rapidement que n’importe quel autre produit ne l’a jamais fait auparavant. Nous avons transformé la vie de 3,7 millions d’utilisateurs en quelques années. Mais pour atteindre 100 millions d’utilisateurs, un bon produit ne suffit pas, il faut construire, ensemble, le meilleur réseau de partenaires qui soit.