7 erreurs courantes de mise en œuvre du logiciel CPQ

Table des matières

    Partagez cet article

    Obtenez une démo

    Dans mon rôle de directeur R&D et d'architecte logiciel, j'ai été impliqué dans différentes étapes d'un certain nombre de projets d'implémentation de logiciels. J'ai commencé avec de petits projets en Italie, et au fur et à mesure que ma carrière a progressé au cours des 20 dernières années, les projets sont devenus de plus en plus gros – se propageant aux États-Unis et en Europe.

    Evidemment, en tant que Directeur R&D chez KBMax, je parle déjà quotidiennement avec des développeurs et des intégrateurs système. Je crois également fermement que je devrais parler directement avec les clients réels et potentiels, pour comprendre leurs besoins et ensuite trouver la meilleure solution pour leur ensemble unique de défis. De ce fait, je demande parfois à notre équipe commerciale de m'impliquer dans leurs rendez-vous clients.

    Besoin de plus d'informations sur la façon de démarrer votre projet de mise en œuvre de CPQ ?

    Get more insights and best practices on standing up your CPQ solution…

    Obtenez notre guide complet de mise en œuvre du CPQ

     

    Erreurs de mise en œuvre du logiciel CPQ

    UNE CPQ projet est souvent le « dernier logiciel » car généralement l'entreprise dispose déjà de systèmes tels que : CRM, ERP, PLM, etc. KBMax est généralement le « ciment » de tous ces systèmes et le « fil rouge » de nombreux services : Ventes, devis bureau, service technique et atelier.

    Je considère mon point de vue en quelque sorte comme un observateur extérieur de la mise en œuvre d'un projet, mais toujours très proche de tous les « acteurs ». La liste suivante n'est pas exhaustive, mais agit comme un ensemble de pièges dont j'ai été témoin, et bien souvent, ils sont évitables avant d'être pleinement réalisés. Comme le dit le livre « L'art de la guerre », « L'art suprême de la guerre est de soumettre l'ennemi sans combattre » – dans ce cas, nos ennemis sont ces pièges de mise en œuvre.

    1. Donner la priorité à la sélection de la technologie plutôt qu'aux processus et aux personnes

    L'une des questions les plus courantes que les gens me posent est. « Quel est le meilleur produit pour choisir un configurateur ou Solution CPQ?" En toute honnêteté, ce n'est pas une question de produit à choisir, mais de personnes et de processus métier auxquels vous vous adressez.

    Il existe des produits parfaitement adaptés à « être paramétrés », mais soit les entreprises n'ont pas de process, soit leur process est inutilement complexe. Cela se produit généralement parce que plusieurs couches sont ajoutées au fil du temps. Il est souvent très difficile de simplifier le processus, car cela implique de réduire ces couches de complexité et le pouvoir de certaines personnes ou équipes de l'entreprise qui s'en occupent. Par exemple, si l'équipe commerciale veut vendre ce que le client désire, cette absence de contraintes va sans aucun doute créer un désordre dans le reste de l'entreprise, en termes d'ingénierie, d'approvisionnement, de production, etc. Ces problèmes ne peuvent être contrôlés si il n'existe aucun processus (et, espérons-le, pris en charge par un logiciel) qui puisse aider à atténuer ce risque.

    I sometimes see products that the technical department has practically made as ‘custom’, but might landed here because they’ve introduced a number of completely unnecessary options. As you try to understand why there are so many options, you discover that they exist because many years ago, a potentiel customer asked for them. It seems to some teams that by creating options and making the process complex, it communicates to their other teams and leadership, “Hey, look how smart we are!”.

    Je pense que maintenant vous voyez le défi : simplifier un processus ne signifie pas donner un service inférieur au client, mais plutôt se battre au sein de l'entreprise pour contrôler l'ego de chaque département. Vous pourriez reconnaître cette lutte comme la gestion du changement. Ce recadrage du processus commercial critique de la vente et de la production doit rester concentré sur l'entreprise dans son ensemble, plutôt que sur des départements ou des individus isolés.

    As these existing processes are discovered, and new, optimized ones conceptualized, often the idea of automation will come to mind.  But be careful not to introduce this concept too early, before a process is fully thought through. Automating a bad process only makes a bad process run faster. If a CPQ software implementation begins replicating existing, ego-driven processes, it is easy to foresee a disaster where automation is simply more quickly compounding your problems.

    2. Trop de personnalisation des processus

    Complètement lié au point ci-dessus : parfois les entreprises ont des processus très étranges. Il s'avère qu'ils ont réinventé la roue – mais ce faisant, ils ont réinventé la roue en tant que carré. J'ai souvent entendu des entreprises s'exclamer fièrement que « nous n'avons jamais été en mesure de trouver des logiciels qui nous satisfont, nous avons donc dû développer les nôtres ». Cela peut être le cas pour des secteurs verticaux hautement spécialisés tels que le calcul technique. Cependant, lorsqu'une catégorie entière de logiciels existe sur le marché et que vous ne pensez pas s'appliquer à vous, cela peut être une indication de quelque chose de plus gros qui ne va pas et qui est probablement motivé par l'ego de quelqu'un.

    When a customer asks for a customization in CPQ software, one should really go to the root to find why they think it is required. Generally, we find that the needed customization is most often hiding a process problem. Software customizations are very expensive for all parties and can add fragility. So, never give a blanketed “yes” to a software customization without asking first, “why”?

    3. Manque d'implication des parties prenantes pour favoriser l'adoption

    Impliquer toutes les parties prenantes est très important, mais peut aussi être dangereux. La partie prenante ultime est l'entreprise. Cependant, ne pas planifier l'adoption par l'utilisateur ou obtenir l'adhésion de l'utilisateur final dans le cadre du processus de prise de décision garantira l'échec.

    Dans le même temps, vous ne pouvez pas non plus laisser les utilisateurs décider unilatéralement de la solution. Comme l'a dit Henry Ford : « Si j'avais demandé aux gens ce qu'ils voulaient, ils auraient répondu des chevaux plus rapides ».

    La clé ici est équilibre. La direction, les chefs de service et les membres de l'équipe doivent tous avoir leur mot à dire dans la conception du nouveau processus. L'équilibre est souvent ce qui distingue une mise en œuvre réussie d'un logiciel CPQ d'un échec.

    4. Ne pas chercher le meilleur produit MVP

    Vous pouvez trouver la définition de MVP (Minimum Viable Product) partout, donc je ne veux pas trop insister ici en ajoutant une autre définition. Le produit le plus complexe de l'entreprise n'est pas un bon candidat comme ce n'est pas un bon candidat, un produit trivial. Le meilleur candidat est probablement un nouveau produit de complexité moyenne, car c'est celui qui a le moins de biais.

    5. Sous-estimer la quantité d'effort

    Cet écueil est généralement dû au fait de ne pas avoir soigneusement rassemblé les exigences du projet. En tant que technicien, je pense qu'il est très facile de sous-estimer le temps requis. En général, je multiplie ce que je pense être l'effort par un facteur de deux. Pourquoi? J'ajoute cela comme « temps politique ». Il est très facile de se perdre dans les discussions et les réunions en tirant des informations sur les gens, au lieu de fournir des exigences correctement documentées à l'avance. Les gens aiment les réunions longues et improductives et je ne sais pas pourquoi.

    6. Ne pas comprendre l'intention et les limites des applications

    Lorsque de nombreuses applications logicielles sont impliquées et connectées dans le cadre d'un processus, d'un département ou d'une entreprise, il est souvent difficile de comprendre « qui fait quoi ». Je ne parle pas de simples zones d'ombre. Je suggère que chaque application logicielle soit utilisée pour ce pour quoi elle a été conçue. Par exemple, il est très courant d'oublier le but d'un outil ETL (Extract Transform Load) et de prétendre que chaque logiciel est responsable de pousser et d'extraire des données. Lorsque de nombreuses applications sont utilisées, vous constaterez que certaines sont plus flexibles, là où d'autres ne le sont pas. Il est évidemment plus facile de plier un logiciel plus flexible pour effectuer des tâches qu'il n'est pas censé faire. Cependant, cela ne signifie pas nécessairement que vous devriez le faire.

    7. Ventes excessives

    Ici, je parle de nous – KBMax en tant qu'éditeur de logiciels. Nous ne vendons pas de rêve. Nous constatons que le problème de survente est considérablement diminué depuis notre transition des licences perpétuelles traditionnelles vers un modèle cloud (SaaS).

    En règle générale, lorsqu'un vendeur vend une licence perpétuelle, il souhaite que la transaction logicielle soit terminée et qu'un premier projet réussi soit lancé avec son client. Après cela, le client n'est plus « le problème du vendeur ». Dans un modèle SaaS, cependant, la vente doit être à la fois un gain initial et un gain continu. Seuls les clients disposant d'un logiciel puissant exécutant une implémentation réussie reviendront pour les renouvellements, ce qui est le seul moyen pour les entreprises SaaS d'être rentables.

    Autres tueurs de projets classiques

    Il existe une multitude d'autres problèmes d'implémentation qu'un projet d'implémentation de logiciel CPQ peut rencontrer : budgets bas/évolutifs, mauvaise gestion de projet, manque de plans de maintenance, mauvaise connaissance de la technologie, mauvaise qualité du logiciel, etc. Ceux-ci sont dangereux et importants à surveiller. car ils peuvent facilement faire planter un projet, mais ils sont assez évidents et faciles à repérer à mon avis. En tout état de cause, ils ne sont pas spécifiques à la mise en œuvre du CPQ en particulier.

    Partager une meilleure façon de mettre en œuvre le logiciel CPQ

    KBMax dispose d'excellentes ressources pour vous aider à démarrer votre projet CPQ. Nous avons un excellent livre électronique et une série d'articles de blog qui mettent en lumière certaines des meilleures pratiques pour vous aider à démarrer :

    Luigi Ottoboni

    Luigi Ottoboni

    Luigi a écrit son premier logiciel à l'âge de huit ans. Il a lancé sa première entreprise, le premier fournisseur d'accès Internet de la région, alors qu'il était encore à l'université. Il a obtenu un diplôme en génie mécanique et a fondé six autres entreprises technologiques. En tant que co-fondateur de KBMax, Luigi dirige notre recherche et développement car il aime trouver de nouvelles technologies pour garder KBMax « à la pointe de la technologie ». Il est fier de dire qu'il a vu plus les États-Unis et la Grèce qu'un résident américain ou grec moyen.

    Publié dans: CPQ
    fr_FRFrench