Vous êtes ici :
Phase 1: Comprendre votre état actuel
Terminez la phase 1 avant de prendre des décisions stratégiques. Les résultats de cette phase informent la sélection de la stratégie à la phase 2.
Sécuriser le parrainage exécutif
Sans parrainage visible de la direction, les projets ont tendance à piétiner lorsque des décisions importantes ou des compromis sont pris. Avant de vous engager dans une stratégie, identifiez un sponsor exécutif nommé qui comprend l'ampleur du changement, a approuvé l'engagement en ressources et peut engager des parties prenantes dans les domaines des ventes, des finances, du droit et de l'informatique.
Formation de l'équipe de base
Attribuez une petite équipe transversale capable de consacrer du temps cohérent au projet. Évitez de diviser l'attention entre les autres priorités pendant les phases actives du projet. Une équipe de base typique comprend :
- Administrateur Salesforce : Gère la configuration, les organisations sandbox et l'exécution technique.
- Propriétaire du produit ou du catalogue : Comprend la structure des produits commerciaux et a un pouvoir décisionnel sur les modifications du catalogue.
- Responsable des opérations de revenu ou analyste commercial : Traduit les exigences métiers en décisions de conception Salesforce.
- Architecte informatique ou intégration : Propriétaire du paysage d'intégration et de l'inventaire de code personnalisé.
- Commanditaire exécutif : Fournit une visibilité, supprime les blocages et maintient le projet aligné sur les priorités métiers.
L'équipe principale doit comprendre le cycle de vie complet du produit à l'encaissement et toute la technologie sous-jacente.
Évaluation de votre organisation Salesforce CPQ
Avant de définir l'étendue ou l'approche de migration, évaluez votre organisation Salesforce CPQ actuelle. Utilisez les outils de migration disponibles, notamment ceux des premiers utilisateurs tels que Forsys, IdeaHelix ou Prodly, pour évaluer la complexité de votre organisation Salesforce dans les dimensions les plus pertinentes pour la planification de la migration. L'évaluation doit répondre à ces questions.
- Combien de produits, d'offres groupées, de règles produit et d'attributs existent dans le catalogue, combien sont activement utilisés et le catalogue est-il rationalisé ?
- Quelles règles de tarification, quels scripts de plug-in Apex calculateur de devis sont en place, et quelle logique métier contiennent-ils ?
- Combien d'abonnements et d'actifs actifs existent, combien sont prêts à être traités et quelle est leur structure de données ?
- Quels codes personnalisés et présentations de page sont utilisés ?
- Quelles intégrations référencent des objets CPQ et quelles données transitent par eux ?
Documenter les points douloureux d'implémentation CPQ
Avant de commencer la migration, documentez les limitations et les contournements de votre implémentation CPQ actuelle. Ces informations définissent les critères de réussite du projet. Capturez ces points.
- Problèmes de performance ou d'évolutivité : Temps de calcul des devis, délais de chargement des pages et blocages de l'approbation.
- Lacunes dans les fonctionnalités : Des exigences métiers que CPQ ne peut pas satisfaire ou ne peut satisfaire qu’avec un développement personnalisé important.
- Solutions de contournement CPQ : Étapes manuelles, feuilles de calcul hors ligne ou systèmes fantômes qui compensent les limitations de CPQ.
- Frottement d'intégration : Des données qui ne circulent pas correctement entre CPQ et les systèmes en aval.
- Améliorations des processus : Processus qui doivent être mis à jour ou optimisés avant la migration. Les processus complexes migrés en l'état resteront tout aussi complexes dans le nouveau système. Utilisez cette opportunité pour les rationaliser.
Ces points douloureux deviennent les critères de réussite de la migration. Déterminez vos critères de réussite avant de passer à la phase 2.
Début de la correction de la qualité des données
Les Problèmes de qualité des données sont plus coûteux à résoudre pendant la migration qu'avant. Commencez tôt la correction, quelle que soit la stratégie de migration que vous sélectionnez. Concentrez-vous d'abord sur ces domaines.
- Produits dupliqués ou retirés qui sont toujours marqués comme actifs dans le catalogue.
- Nommage incohérent des attributs entre les gammes de produits ou les unités commerciales.
- Examinez les données du catalogue de coûts CPQ pour détecter les doublons potentiels. Pour conserver les enregistrements de coût historique, créez un champ personnalisé pour la date de fin effective et remplissez cette date avant la migration.
- Les enregistrements orphelins, tels que les abonnements sans compte parent ou les lignes de devis sans devis parent.
- Créez une série d'enregistrements d'abonnement qui doivent être migrés ensemble. Il n'est pas nécessaire de migrer les abonnements annulés.
- Enregistrements d’actifs incomplets ou incohérents, qui peuvent affecter la migration de Customer Asset Lifecycle Management (CALM).
- Le champ ProductSellingModelId dans les enregistrements Entrée au catalogue de prix est en lecture seule après la création initiale des enregistrements Entrée au catalogue de prix. Si vous migrez vers Gestion du revenu sans spécifier de modèle de vente de produits lors de la création, les enregistrements Entrée au catalogue de prix ne peuvent pas être corrigés après la migration sans créer d'enregistrements. Assurez-vous donc que les modèles de vente de produits sont correctement mappés avant la migration. Contactez le Support client de Salesforce si vous avez besoin d'un accès en modification pour changer le modèle de vente de produits dans les enregistrements Entrée au catalogue de prix.
- Alors que CPQ utilise des types d'enregistrement pour identifier les enregistrements associés à CPQ, Gestion du revenu utilise les enregistrements Attribution d'utilisation d'applications pour identifier les enregistrements générés par Gestion du revenu. L'enregistrement Attribution d'utilisation de l'application doit être rempli pour tous les enregistrements transactionnels, tels que les devis, les commandes et les actifs, pour que les opérations du cycle de vie des actifs réussissent.
- Dans Salesforce CPQ, les attributs peuvent être directement attribués à des produits. Dans Gestion du revenu, les attributs à hérités via une classe de produits. Comme les utilisateurs de CPQ n'ont pas de classes de produits, elles doivent être systématiquement créées pendant la migration en regroupant les produits avec des ensembles d'attributs identiques.
- Dans Salesforce CPQ, vous pouvez créer plusieurs entrées de coût pour chaque produit et chaque devise, y compris des entrées de coût unitaire nul. Dans Gestion du revenu, vous ne pouvez pas créer des enregistrements Entrée au catalogue de coûts dupliqués ou le même code ISO de devise. Cette différence entraîne des erreurs de migration.
Liste de contrôle de la phase 1
Avant de passer à la phase 2, vérifiez que vous avez effectué les tâches ci-dessous.
- Le parrainage de la direction est en place et l'engagement en ressources est approuvé.
- Une équipe de base est en place avec des rôles définis et des capacités suffisantes.
- Une évaluation de l'organisation Salesforce CPQ est terminée et l'équipe comprend le profil de complexité.
- Les points douloureux avec l'implémentation actuelle de CPQ sont documentés et l'équipe a une définition commune de la réussite.
- D'importants Problèmes de qualité des données sont identifiés et des mesures correctives ont été prises.
- Votre chargé de compte Salesforce est engagé, et les options de licence et de support sont comprises.
Lorsque vous avez terminé tous les éléments de la phase 1, passez à la phase 2.
