您在此处：
常见问题和建议实践
本表说明了从 Salesforce CPQ 过渡到收入管理(以前称为 Revenue Cloud)期间经常出现的问题,以及根本原因和避免这些问题的建议做法。
| 问题 | 原因 | 推荐实践 |
|---|---|---|
| 将项目作为迁移而不是重新设计来处理 | 团队专注于复制 Salesforce CPQ 功能，而不是重新考虑流程。 | 对于每个流程，在设计等效收入管理之前，请考虑当前设计背后的目的。 |
| 跳过目录合理化 | 团队低估了产品目录臃肿，推迟了合理化。 | 在开始任何技术配置之前，定义您的商业产品分类和技术产品分类之间的区别。 |
| 迁移无效定价规则 | 团队会在没有审核的情况下移动无效或冗余的 Salesforce CPQ 定价规则。 | 审核评估阶段中的所有定价规则。归档没有进程积极执行的规则。 |
| 低估报价计算插件 (QCP) 的复杂性 | 团队通常没有很好地记录 QCP 逻辑。QCP 逻辑在定价输出中不可见。 | 使用 AI 解释工具，将每个 QCP 映射到其业务目的。通过使用涵盖一系列代表性场景的一组小引号来验证输出。 |
| 忽略数据质量先决条件 | 属性命名不一致、重复产品和孤立记录会保留在收入管理中。 | 在迁移开始前，投资于数据质量补救。对所有属性值运行规范化传递。 |
| 报表重新设计不足 | 上线后，团队发现他们必须为 Revenue Management 的数据模型重新创建基于自定义对象的 Salesforce CPQ 报表 | 在上线前确定关键报表。在 Sandbox 中，在收入管理对象上重新构建它们，并在切换前进行验证。 |
| 对变革管理和培训的投资不足 | 技术团队专注于系统，而最终用户直到上线才做好准备。迁移小组低估了CPQ和收入管理之间的实质性架构差异,假设现有的Knowledge直接转移。 | 在上线前尽早开始最终用户启用。使用真实数据的实践研讨会非常有效。确保管理迁移的所有团队成员在配置开始前完成基础收入管理培训。理想情况下，让经过认证的团队成员进行生产维护。收入管理的架构需要新的思维模型，而不仅仅是熟悉 UI。 |
本文章是否解决您的问题？
请与我们共享您的想法，以便我们进行改进！
