许可证优化 - 模式
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 组织 | ✅ 许可证类型与实际用户需求和使用模式匹配（不是职务） |
| 平台 | 组织 | ✅ 仅访问自定义对象的用户会收到平台许可证，而不是完整的 Salesforce 许可证 |
| 平台 | 组织 | ✅ 外部用户（客户、合作伙伴、社区成员）使用 Experience Cloud 许可证，而不是内部许可证 |
| 平台 | 组织 | ✅ 仅需要身份验证而没有数据访问权限的用户会收到身份许可证 |
| 平台 | 组织 | ✅ 季度许可证审计将仅访问自定义对象的用户识别为平台许可证候选人 |
| 平台 | 组织 | ✅ 自动季度报表识别 90 天内登录次数为零的用户、仅访问自定义对象的用户以及拥有内部许可证的外部用户，以便进行系统调整大小 |
| 平台 | 组织 | ✅ 许可证分配根据角色变化进行审查和调整，而不是多年保持不变 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 组织 | ⚏ 完整的 Salesforce 许可证根据职务而不是实际的系统使用模式分配给所有员工 |
| 平台 | 组织 | 仅访问自定义对象的用户会收到完整的 Sales Cloud 或 Service Cloud 许可证，而不是 Platform 许可证 |
| 平台 | 组织 | 外部用户消耗内部许可证容量，而不是 Experience Cloud 许可证 |
| 平台 | 组织 | ⚏ 初始部署期间的许可证分配集在三年内保持不变，尽管角色发生了变化 |
| 平台 | 组织 | ⚠ 从未进行许可证审计；40% 的许可证未使用或未充分利用 |
| 平台 | 组织 | 每月登录次数少于 的用户不会识别为许可证回收的候选项 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 安全性 | ✅ Shield 组件（平台加密、事件监控、现场审计跟踪）会根据它们是否满足特定的合规需求进行单独评估 |
| Data 360 | 架构 | ✅ Data 360 投资基于对跨系统身份解析、实时客户数据访问或细分激活的要求 |
| AI | 业务 | ✅ AI 投资要求在定义的测量期内展示 ROI，而不是假设未指定的值 |
| 平台 | 行业云 | ✅ 根据自定义开发成本和上市时间要求评估行业云（金融服务、健康、制造、Net Zero） |
| 平台 | 行业云 | ✅ Industry Cloud 评估承认标准工作流的实施速度提高了 40-60%，但考虑了自定义，从而节省了时间 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 安全性 | ⚠ 购买所有 Shield 组件时，不评估特定组件是否满足实际合规或安全需求 |
| Data 360 | 架构 | 购买 Data 360 时没有评估更简单的集成方法是否满足要求 |
| AI | 业务 | AI 投资缺乏可衡量的业务价值度量或 ROI 演示 |
| AI | 业务 | AI 投资假设价值将在不定义特定测量期或成功标准的情况下交付 |
| 平台 | 行业云 | ⚏ 购买 Industry Cloud 时，没有与自定义开发成本进行比较，也没有验证上市时间加速 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 配置 | ✅ 新用户配置工作流会自动为仅访问自定义应用程序的用户分配平台许可证 |
| 平台 | 配置 | ✅ 新用户配置工作流队列外部用户，用于基于电子邮件域的 Experience Cloud 许可证分配 |
| 平台 | 配置 | ✅ 分配策略根据用户角色和平台使用要求定义许可证类型的明确标准 |
| 平台 | 配置 | ✅ 批准工作流需要高级许可证类型的业务理由 |
| 平台 | 配置 | ✅ 在配置时实施适当的许可证分配，而不是追溯性地纠正错误分配 |
| 平台 | 组织 | ✅ 回收流程自动识别不活动用户（60-90 天），并回收未使用的许可证进行重新分配 |
| 平台 | 组织 | ✅ 基于登录的报表根据组织策略识别 60-90 天内不活动的用户 |
| 平台 | 组织 | ✅ 季度回收防止许可证浪费在员工更换角色或离开组织时累积 |
| 平台 | KPI | ✅ 使用率监控仪表板跟踪登录频率、功能使用模式和许可证类型适当性 |
| 平台 | 业务 | ✅ 与业务领导共享利用率数据，以在续订计划期间做出数据驱动的许可证投资决策 |
| 报表和仪表板 → 许可证利用率仪表板 设置 → 用户 → 活动用户 | ✅ 模式:许可证利用率仪表板显示活动许可证与非活动许可证、登录频率分布、按许可证类型划分的功能使用情况和许可证类型分布 ✅ 使用率仪表板显示需要审查的非活动用户、过度许可用户和许可证类型不匹配 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 配置 | 许可证分配策略不存在；每个请求都是临时处理的 |
| 平台 | 配置 | 批准工作流不需要对高级许可证类型进行业务论证 |
| 平台 | 组织 | ⚠ 不活动用户识别是手动和不常见的，而不是自动化的 |
| 平台 | 组织 | 许可证回收仅在年度续订期间进行，而不是每季度 |
| 平台 | 组织 | ⚠ 许可证浪费会随着员工更换角色或离开而没有许可证回收而累积多年 |
| 平台 | KPI | 使用率监控仪表板不存在；使用模式未知 |
| 平台 | 业务 | ⚏ 业务领导在续订计划期间缺乏许可证利用率数据的可见性 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 合同 | ✅ 用户数量承诺由业务计划支持，而不是乐观的预测 |
| 平台 | 合同 | ✅ 停机坪计划将投资与实际用户加入时间表相匹配，而不是提前为未使用的容量付费 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 合同 | 过度承诺用户计数会立即造成浪费，因为未使用的许可证会消耗预算，而不会带来价值 |
| 平台 | 合同 | 如果增长预测被证明不正确，签署多年期协议时没有评估灵活性需求 |
| 平台 | 合同 | 调整时间与业务计划周期不匹配；调整落后于实际人数变化 |
| 平台 | 合同 | ⚠ 组织携带了 200 个未使用的许可证，为期 18 个月，因为招聘计划会在承诺实现数量折扣后延迟 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 架构 | ✅ 集成架构规划项目 API 消耗，并评估 Enterprise 或 Unlimited Edition 是否提供了更好的 TCO |
| 平台 | 架构 | ✅ 版本成本比较模型每个用户保费与包含的功能（API 限制、存储、Sandbox 分配、Premier 支持） |
| 平台 | 架构 | ✅ Edition 决策模型根据两个定价模型预测的使用情况，以及支持未来重新评估的文档化假设 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 架构 | 版本选择根据预算约束默认设置为最高或最低级别，而不分析架构要求 |
| 平台 | 架构 | 选择 Enterprise Edition 是为了最大限度地减少每个用户的成本，而不会预测集成要求和 API 超额成本 |
| 平台 | 架构 | ⚏ 部署后，集成要求超出限制，导致 API 超额加上架构返工的成本增加 2 倍 |
| 平台 | 架构 | ⚏ 版本决策是在没有根据定价模型或文档假设对实际使用情况进行建模的情况下做出的 |
| 平台 | 组织 | 版本选择仅基于每个用户的年订阅成本，没有建模架构约束 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 架构 | ✅ 在采用多组织架构之前，评估单组织优化方法（共享规则、权限集、记录类型） |
| 平台 | 架构 | ✅ 多组织 TCO 模型显示了 2-3 倍的运营成本增长，包括管理、发布管理、监控、事件响应和合规性 |
| 平台 | 架构 | ✅ 多组织架构仅在监管要求（GDPR 数据驻留、财务分离）抵消增加的成本时采用 |
| 平台 | 架构 | ✅ 多组织理由文档记录了具有权限边界的单个组织无法满足的真正隔离要求 |
| 平台 | 合同 | ✅ 多组织许可证成本模型为每个丢失批量定价并需要重复管理许可证的组织建立单独的许可证池 |
| 平台 | 架构 | ✅ 跨多个实施的多组织运营成本模型并行维护增加了开发和运营工作量 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 架构 | 采用多组织架构，因为业务部门“需要独立性”，无需建模成本倍增 2-3 倍 |
| 平台 | 架构 | ⚠ 采用多组织时，没有评估具有共享规则的单个组织是否能够以很小的成本满足实际需求 |
| 平台 | 架构 | ⚠ 多组织 TCO 模型不包括运营成本成倍增长（对于管理员、发布管理、监控、合规性而言是 2-3 倍） |
| 平台 | 架构 | ⚠ 多组织架构缺乏有据可查的业务理由，证明价值超过永久性和复合成本倍增 |
| 平台 | 合同 | 多组织许可证成本分析不考虑失去批量定价好处的单独许可证池 |
| 平台 | 架构 | ⚏ 多组织操作负担未建模；部署后发现跨组织的并行维护 |
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 集成 | ✅ 多组织 TCO 包括 MuleSoft 许可（每年 20 万到 20 万美元以上）、集成开发、持续维护和 API 容量规划 |
| 平台 | 集成 | ✅ 跨组织集成成本建模明确显示 MuleSoft 投资、开发工作和持续运营成本 |
| 平台 | 架构 | ✅ API 消耗倍增模型：跨组织事务同时消耗多个组织 5-10 次 API 调用 |
| 平台 | 集成 | ✅ 用于维护跨组织同步参考数据的数据一致性开销包括开发工作、监控和解决冲突 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 集成 | 多组织架构基于许可证成本比较进行批准，无需建模每年 24 万美元的集成成本 |
| 平台 | 集成 | 跨组织集成成本没有明确建模；单个组织将完全消除这些成本 |
| 平台 | 架构 | 容量规划不考虑跨组织调用的 API 消耗成倍增长 |
| 平台 | 集成 | 同步参考数据的数据一致性开销不包括在多组织 TCO 模型中 |
模式
| 何处查看 | 好样的 |
|---|---|
| 设置 → Sandbox → 环境策略 DevOps → Sandbox 分配计划 | ✅ 模式:团队使用 Developer Pro Sandbox 进行模拟数据的功能开发，使用目标客户进行集成测试的部分复制 ✅ 保留完全复制，仅用于生产前 UAT 和性能验证，在架构上需要完整数据量时 |
| 设置 → Sandbox → 平衡策略 财务 → 环境预算 | ✅ 模式:15 人的开发团队实施平衡的策略，包括 15 个 Developer Pro Sandbox（每月 750 美元）、3 个并行工作流部分复制（每月 900 美元）、1 个 UAT 完全复制（每月 3000 美元） ✅ 每月总计 4650 美元，符合实际开发模式，而不是为理论上的最大并行度过度配置 |
| 设置 → Sandbox 模板 → 数据选择 设置 → 部分复制配置 | ✅ 模式:部分复制 Sandbox 模板包含过去 12 个月的业务机会和个案，但不包括归档数据 ✅ 提供 5 GB 容量内的代表性测试数据，而不是要求完全复制，通过战略性数据选择实现低成本 Sandbox 类型 |
| 进程 → Sandbox 生命周期 设置 → 临时环境跟踪 | ✅ 模式:临时 Sandbox 管理会跟踪为特定项目创建的环境，其中包含记录的删除日期 ✅ 实施需要续订理由的到期策略，以维护超出初始范围的临时环境，防止永久状态偏移 |
| 设置 → Sandbox 刷新计划 日历 → 刷新优化 | ✅ 模式:刷新节奏优化使 Sandbox 刷新与实际数据新鲜度要求保持一致，而不是任意计划 ✅ 当测试模式不需要每月刷新时，每季度完全复制刷新就足够了，为额外的 Sandbox 释放了容量 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 过度配置 → 浪费的投资 | 反模式:组织购买了五个完全复制 Sandbox，为每个开发团队提供专用环境 当部分复制满足大多数测试要求时，乘法的成本是原来的 5-10 倍；完全复制应该保留给需要完全生产保真度的场景 |
| 无策略 → 高级默认设置 | 反模式:15 人团队购买高级策略，其中包含 30 个 Developer Pro 和 5 个完全复制 Sandbox（每月 $18,000），因为“环境越多越好” ⚠ 没有分析表明开发速度受到环境可用性的限制；平衡策略将以每月 4650 美元的速度提供 |
| 未筛选模板 → 强制升级 | 反模式:部分复制模板包含所有对象，无需筛选，消耗 5 GB 容量，历史数据与测试无关 强制购买完全复制，因为战略数据选择能够以每个 Sandbox 5-10 倍的成本实现部分复制的使用 |
| Sandbox 蔓延 → 永久临时 | 反模式:在项目 Sandbox 无正当理由地过渡到永久状态时，临时 Sandbox 激增 ⚠ 没有到期策略或续订要求，允许临时环境无限累积消耗预算 |