Des milliers d’entreprises utilisent encore les progiciels gérés SteelBrick CPQ (Configure, Price, Quote) ou Salesforce Industries (anciennement Vlocity). Alors que ces plateformes arrivent en fin de commercialisation, Salesforce a transféré plusieurs des fonctionnalités avancées de ces applications (particulièrement Vlocity) vers « Core » sous la forme d’Agentforce Revenue Management (anciennement, et aux fins du présent document, appelé Revenue Cloud Advanced ou RCA), où elles peuvent être utilisées plus largement dans les solutions Industries et Cloud. SteelBrick et Industries étaient des progiciels distincts, et maintenant, RCA sur Core remplace les deux.
RCA offre une base architecturale plus solide que les piles technologiques existantes. Le hic : la façon dont vous migrez vers RCA détermine la facilité de maintenance continue, la souplesse de configuration, la performance en production et, ultimement, le moment où le retour sur investissement (ROI) est atteint. Le simple fait de transférer la configuration de l’ancien système vers le nouveau préserve la dette technique. Repartir sur de nouvelles bases architecturales avec RCA permet d’implémenter ces fonctionnalités selon les meilleures pratiques de conception, avec des limites claires et un modèle d’exploitation plus facile à maintenir.
Les questions à poser maintenant!
Avant de poursuivre votre lecture, voici trois questions directes qui aideront à encadrer la discussion :
- Votre feuille de route d’adoption de RCA suppose-t-elle que la configuration copiée de SteelBrick ou Industries fonctionnera à peu près de la même façon sur RCA?
- Lorsqu’un fournisseur ou un intégrateur de services (SI) propose des « outils de migration », peut-il expliquer ce qu’ils transforment intelligemment (sémantique du catalogue, orchestration, règles, limites), plutôt que de simplement inventorier, copier et exécuter?
- Avez-vous identifié les points faibles de votre implémentation actuelle, et votre programme de « migration » peut-il expliquer comment la conception cible de RCA les résout plutôt que de les laisser persister dans la nouvelle plateforme?
Si ces questions vous mettent mal à l’aise, c’est généralement un signe qu’il faut revoir la planification de votre projet RCA et en redéfinir honnêtement la portée, plutôt que de s’engager dans une migration telle quelle en supposant que les points faibles connus pourront être corrigés dans une phase ultérieure. Après la mise en production, corriger une conception de catalogue et de processus étroitement imbriquée coûte beaucoup plus cher que de s’y attaquer dans votre plan de migration. Comme l’histoire l’a démontré, les organisations savent très bien établir un budget pour de nouveaux déploiements, mais beaucoup moins bien financer la dette technique après la mise en production.
Le parcours est exigeant, surtout lorsque des points faibles connus doivent être résolus avant que l’adoption puisse s’accélérer. RCA sur Salesforce porte ses fruits lorsque le programme repose sur une réimplémentation délibérée avec optimisation, et non lorsque la configuration existante est reprise avec un minimum de changements.
Une migration telle quelle n’est pas une transformation intelligente
Comme nous venons de le décrire, le malentendu potentiellement le plus coûteux à l’heure actuelle est de croire que les outils de « migration » équivalent à un parcours optimisé vers RCA. Ces outils peuvent tout de même aider à nettoyer légèrement certains aspects simples de la configuration (par exemple, repérer les enregistrements en double ou les multiples chemins de sortie dans les plans d’orchestration), mais l’élément essentiel est absent : la transformation intelligente. Il s’agit de remapper en fonction de la façon dont RCA fonctionne aujourd’hui, et non de réhéberger la façon dont les anciens systèmes fonctionnaient. Examinons cela de plus près.
D’abord, les outils existants analysent les configurations sources (SteelBrick CPQ ou Industries) (analyse avant la migration), font ressortir les erreurs de configuration et les violations des meilleures pratiques, et donnent une « idée » de l’ampleur des personnalisations dans l’environnement en comptant simplement leur nombre et leur taille. Cette analyse est effectuée dans le contexte des capacités et des limites de l’application existante, et non en fonction de RCA, qui comporte des considérations différentes en matière de conception et de performance. Ces produits encouragent un « nettoyage avant la migration ».
Ensuite, ces outils effectuent une copie en bloc des données (migration telle quelle) vers un environnement RCA (une copie d’objet à objet), puis appliquent quelques règles légères de meilleures pratiques à la configuration dans le contexte des limites prévues de RCA, dont plusieurs sont encore inconnues ou n’ont pas été publiées (analyse après la migration). C’est ensuite que le vrai travail commence, ce qui consiste généralement à exécuter et retester jusqu’à ce que les configurations semblent commencer à fonctionner. Enfin, les données réelles des clients sont migrées vers la nouvelle plateforme.
*Un processus de migration « tel quel » typique et non optimisé
Ce qui manque tout au long de ces processus, c’est la transformation intelligente : remapper la sémantique, reconstruire les modèles et réexprimer les comportements afin qu’ils fonctionnent de façon optimale sur RCA, et non simplement comme auparavant. Au fil du temps, les processus et configurations existants ont souvent été adaptés de façon peu naturelle afin de contourner les limites des applications et environnements existants. Ils doivent être déconstruits et réexaminés afin de déterminer ce qui peut être conçu de façon plus optimale sur RCA.
La question directe à poser à tout fournisseur offrant des outils de migration RCA (ou, plus largement, un programme de « migration » RCA) est donc :
Que transformez-vous (plutôt que de copier)?
Que reconcevez-vous pour RCA (plutôt que de réhéberger)?
Quelles nouvelles fonctionnalités de RCA activerez-vous que je ne peux pas utiliser aujourd’hui avec l’ancien CPQ?
