成本治理和决策 - 模式
了解有关架构良好的资源和成本优化的更多信息 → 成本监控和治理
模式
| 何处查看 | 好样的 |
|---|---|
| 设置 → 公司设置 → 系统概览 报表和仪表板 → 成本利用率文件夹 | ✅ 模式:创建主管仪表板，显示分布在 1200 个许可证（每周活动 68%）、450 GB 存储（容量 72%）和 15 个 Sandbox（有效使用 11 个）中的 Salesforce 年投资 210 万美元 ✅ 仪表板通过操作度量显示无效许可证和未使用 Sandbox 中的 40 万美元优化业务机会 |
| 报表和仪表板 → 投资仪表板 设置 → 公司信息 | ✅ 模式:投资仪表板显示按业务部门或成本中心划分的支出、按开发团队划分的 Sandbox 和环境成本、带有利用率度量的附加产品成本 ✅ 基于当前增长趋势的项目支出,有助于预算问责和分配讨论 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 仅会计系统 → 发票记录 | 反模式:财务团队有显示总支出的发票可见性，但没有显示利用模式或优化业务机会的操作度量 如果没有操作仪表板，就无法识别无效许可证、未使用的 Sandbox 或容量浪费 |
模式
| 何处查看 | 好样的 |
|---|---|
| 报表和仪表板 → 许可证预算提醒 设置 → 许可证分配 | ✅ 模式:许可证预算按部门确定分配目标，并在接近容量时发出警报 ✅ 通过 Proactive Monitoring，防止不受控制的配置造成仅在续订时发现的预算超支 |
| 设置 → 存储空间使用情况 → 提醒规则 流 → 存储警告自动化 | ✅ 模式:存储利用率达到 70% 的自动警报触发器，在达到限制之前提供 4 个月的准备时间来实施归档策略 ✅ 通过具有足够响应时间的主动通知，防止紧急数据删除或昂贵的超额费用 |
| 系统概览 → API 使用警报 事件监控 → API 阈值警告 | ✅ 模式:API 预算根据限制跟踪消耗，并在示例利用率阈值时发出警报，例如 70% 和 85% ✅ 在限制导致集成失败或用户中断后，启用主动优化，而不是反应性应急响应 |
| 设置 → Sandbox 管理 → 预算控制 流 → Sandbox 请求批准 | ✅ 模式:Sandbox 预算通过其他环境的分配限制和审批流程来控制环境的扩散 ✅ 防止团队在没有正当理由的情况下创建向永久状态过渡的无限临时环境 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 无预算控制 → 不受控制的支出 | 反模式:没有许可证预算或批准工作流，允许在没有支出模式可见性的情况下在部门间无限制地配置 ⚏ 当由于不受控制的增长导致总支出超过计划投资 30-40% 时，续订时发现的预算超支 |
| 无存储警报 → 反应性超额 | 反模式:在续订协商期间发现的存储过量，需要立即以保费价格购买，而没有时间进行归档评估 ⚠ 缺少可在超额发生前实施归档的提前警告，导致成本增加 2-3 倍 |
模式
| 何处查看 | 好样的 |
|---|---|
| 报表和仪表板 → 显示报表 报表 → 按业务部门划分的成本 | ✅ 模式:季度展示报表显示 Sales Cloud 消耗 45% 的许可证投资，Service Cloud 30%，运营 25% ✅ 支持主管讨论投资分配是否符合业务价值优先级和战略重点领域 |
| 财务系统 → 按存储容量使用计费分配 报表 → 部门成本分配 | ✅ 模式:分配规则适当地分配成本：按用户部门分配的许可证成本，按拥有开发团队分配的 Sandbox 成本 ✅ 按消耗集成服务的业务流程分配的集成成本，按请求项目资金来源分配的开发成本 |
| 报表和仪表板 → Sandbox 成本报表 设置 → Sandbox 使用情况（按团队） | ✅ 模式:Sandbox 和环境成本由拥有环境管理直接问责制的开发团队分配 ✅ 团队看到他们的 Sandbox 投资支持有关环境请求和生命周期管理的明智决策 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 仅限 IT 预算 → 没有业务部门可见性 | 反模式:分配到 IT 预算的所有 Salesforce 成本，没有业务部门可见性 业务利益相关者将平台视为“免费”，并在没有成本意识或投资优先级讨论的情况下提出请求 |
| 无使用属性 → 无法优化 | 反模式:总支出可见，但无法归因于做出优化决策的业务部门、项目或团队 ⚠ 无法识别哪些投资交付价值，哪些消耗预算而没有成比例的回报 |
模式
| 何处查看 | 好样的 |
|---|---|
| 协作 → FinOps 团队 会议 → 每月成本审核 | ✅ 模式:财务、架构和业务利益相关者之间的跨职能协作确保成本决策在考虑支出影响的同时考虑业务价值 ✅ FinOps 将财务专业知识带到架构讨论，将技术理解带到预算规划，创建平衡的决策 |
| 日历 → 优化审核 进程 → 常规节奏 | ✅ 模式:通过每月异常审查、每季度利用率审计和每年全面 TCO 评估，持续优化节奏 ✅ 定期审核周期防止成本漂移，并通过系统分析验证支出增长与业务价值增长是否对应 |
| 工具 → 许可证成本计算器 架构 → TCO 模型 | ✅ 模式:FinOps 团队为架构师提供许可证成本计算器，显示不同许可证类型选择的总拥有成本影响 ✅ 在架构阶段支持成本感知的设计决策，而不是在部署后发现更改成本高昂的成本 |
| 培训 → 成本意识计划 文档 → 成本影响指南 | ✅ 模式:成本意识教育确保团队了解架构决策如何影响总拥有成本 ✅ 架构师设计更好的解决方案来平衡能力和投资;开发人员编写更高效的自动化，遵守调控器限制和 API 消耗 |
| 自动化 → 成本监控脚本 仪表板 → 自动生成的报表 | ✅ 模式:自动监控利用率、优化业务机会和支出报表减少了手动工作 ✅ 具有组织复杂性的规模，没有线性人数增长，能够在不断增长的平台足迹中实现成本意识 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 仅限年度 → 无反馈循环 | 反模式:成本可见性仅限于年度续订讨论，不提供反馈循环 架构团队无法在更改成本最低时了解或优化设计阶段的支出模式 |
| 孤岛决策 → 无跨职能输入 | 反模式:在没有资金投入的情况下做出的架构决策，在没有技术理解的情况下做出的预算决策 在没有业务理由或预算削减的情况下，导致解决方案超出预算，从而消除了提供关键价值的能力 |
| 免费教育 → 不知情的决策 | 反模式:团队在没有了解成本影响的情况下做出架构决策，因为没有培训或可见性 ⚠ 通过数千个微观决策累积废物，这些决策看似微不足道，但却增加了大量支出 |
模式
| 何处查看 | 好样的 |
|---|---|
| 文档 → 架构决策记录 流程 → ADR 模板 | ✅ 模式:客户入口网站的架构决策记录包括许可证分析：10,000 个拥有 Customer Community Plus 许可证的外部用户（每个用户每月 6 美元 = 每年 720 万美元） ✅ 与带有 API 集成的自定义 Web 应用程序进行比较（初始价值 250 000 美元 + 年度维护价值 50 000 美元），推荐具有 2 年投资回报的自定义应用程序 |
| 治理 → 架构审查委员会 流程 → 成本审查条件 | ✅ 模式:架构审查委员会包含成本视角以及功能和非功能需求，从而做出更一致的投资决策 ✅ 成本是架构决策的一个输入，确保组织在重要的功能上进行适当投资，同时避免浪费 |
| 文档 → ADR 成本部分 模板 → TCO 预测 | ✅ 模式:在架构决策记录中包含成本影响评估，记录主要设计选择 ✅ 对于超过定义投资阈值（10 万美元或组织策略）的解决方案，需要 TCO 预测，并包含书面假设 |
| 流程 → 许可证影响审查 架构 → 高级功能分析 | ✅ 模式:在解决方案设计期间评估许可证含义，确定设计是否需要高级许可证或加载项 ✅ 在承诺影响 API 消耗或中间件许可要求的模式之前，评估集成成本影响 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 无成本考虑 → 紧急重新设计 | 反模式:未考虑成本的架构设计，在实施计划时发现建议的方法需要 72 万美元的年度投资 在时间压力下导致紧急重新设计，与从一开始就意识到成本的设计相比，结果较差 |
| 设计后成本发现 → 浪费精力 | 反模式:在成本分析揭示方法超出预算 3 倍之前完成架构 ⚏ 在项目开始时就知道的预算限制范围内进行团队重新设计时，浪费了设计精力并延迟了交付 |
模式
| 何处查看 | 好样的 |
|---|---|
| AppExchange → 解决方案评估 分析 → TCO 比较 | ✅ 模式:文档生成解决方案评估：AppExchange 选项，每个用户每月 15 美元(100 个用户每年 18 万美元),而自定义开发，初始构建 8 万美元 + 年度维护 15 万美元 ✅ AppExchange 在 5 年内实现突破，部署速度更快，商品功能风险更低 |
| AppExchange → 战略与商品 架构 → 功能分类 | ✅ 模式:从 AppExchange 购买的商品功能(文档生成、电子签名、地址丰富),解决方案成熟且审核性强 ✅ 专有定价算法提供竞争优势 构建自定义，完全控制路线图和差异化 |
| 电子表格 → 3-5 年 TCO 模型 分析 → 成本预测 | ✅ 模式:构建 TCO 模型，预测 3-5 年的总成本，揭示初始费用之外的完整投资情况 ✅ AppExchange 支持复合年度订阅，但包含维护；自定义需要一次性开发，外加 15-20% 的年度维护 |
| 集成分析 → 自定义与平台 TCO → 集成比较 | ✅ 模式:自定义集成开发：15 万美元的初始构建 + 3 万美元的年度维护 + 团队学习曲线与 MuleSoft 许可证：每年 75 万美元 + 更快的集成交付 ✅ MuleSoft 在所有集成中提供可重用的模式，随着产品组合的增长降低每个集成的成本 |
| 文档 → 构建与购买 ADR 流程 → 评估框架 | ✅ 模式:架构决策记录文档构建与购买评估，其中包含对战略价值、TCO、时间线、能力和退出成本进行加权的评分矩阵 ✅ 创建审计跟踪，以便在需求变化或供应商情况发生变化时进行未来重新评估 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 始终构建 → 浪费开发 | 反模式:构建自定义文档生成解决方案，因为“我们有开发人员可用”，无需建模 5 年 TCO ⚠ ️ AppExchange 为商品功能提供了更好的价值；自定义开发将容量浪费在无区分的功能上 |
| 始终购买 → 缺少差异 | 反模式:从 AppExchange 购买所有功能，包括战略优势，因为“部署更快” 使用相同 AppExchange 解决方案的竞争对手获得了相同的功能，从而消除了平台投资的竞争优势 |
| 单次会议决策 → 无分析 | 反模式:在没有系统评估或文档的情况下，根据初始成本比较，在单次会议上做出构建和购买决策 缺少战略价值评估、TCO 预测、时间表要求、能力评估和退出成本分析 |
| 不完整成本模型 → 隐藏成本 | 反模式:构建自定义集成，因为“我们已经有开发人员”而没有建模 5 年的维护负担 维护通常每年消耗初始开发成本的 15-20%，加上初始决策中不可见的平台兼容性工作 |
模式
| 何处查看 | 好样的 |
|---|---|
| 流程 → 战略价值评估 分析 → 差异矩阵 | ✅ 模式:通过一致的评估将构建与购买决策系统化，防止基于不完整分析的临时决策 ✅ 先评估战略价值：核心竞争优势保证定制投资;商品能力有利于以更低的总成本购买成熟的解决方案 |
| AppExchange → 解决方案成熟度审查 分析 → 供应商稳定性检查 | ✅ 模式:评估可用的 AppExchange 选项，审查解决方案的成熟度、客户评级、ISV 稳定性、功能一致性和定价模型 ✅ 客户较少的不成熟解决方案风险较高；优先考虑审核有力且供应商财务状况稳定的成熟解决方案 |
| 电子表格 → 灵敏度分析 TCO → 假设文档 | ✅ 模式:模型 3-5 年 TCO，适用于所有成本类别：许可证/订阅、实施工作量、维护负担、增强开发、平台兼容性 ✅ 使用电子表格对假设进行敏感性分析，显示如果增长率或利用率与预测不同，结果如何变化 |
| 时间线 → 市场时机分析 策略 → 价值实现时间评估 | ✅ 模式:评估时间线要求，显示自定义开发需要几个月到几年，这取决于复杂性，而 AppExchange 部署需要几周时间 ✅ 当竞争压力或业务机会需要即时能力时，尽管长期成本较高，但市场时机可能会推动购买决策 |
| 分析 → 退出成本评估 风险 → 供应商锁定评估 | ✅ 模式:评估退出成本和供应商集中风险，询问如果所选选项证明不足，切换的难度 ✅ 如果要求发生变化，考虑供应商收购或停产的风险和解决方案的可移植性，宁愿降低退出成本，提供战略灵活性 |
| 能力 → 诚实评估 团队 → 维护能力审核 | ✅ 模式:诚实地考虑组织能力，评估自定义解决方案是否可以长期保留 ✅ 自定义解决方案需要持续的内部专业知识进行维护和演进；缺乏这种能力的组织应该购买，尽管成本可能更高 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 没有框架 → 不一致的决策 | 反模式:构建与购买决策因项目团队的首选项而异，没有一致的评估标准 ⚏ 一些团队总是在构建，而其他团队总是在购买，这造成了架构上的不一致，以及跨平台的次优投资 |
| 构建一切 → 无差别的努力 | 反模式:构建一切自定义内容，因为“我们想要控制”，而不区分商品能力和战略优势 将开发能力浪费在成熟的 AppExchange 解决方案以更低的总成本提供的无差别功能上 |
| 仅初始成本 → 不完整分析 | 反模式:仅基于初始成本比较的决策：“AppExchange 是 20000 美元,自定义构建是 20005 美元,所以我们将构建” 缺少 3-5 年的 TCO，显示自定义解决方案的初始维护成本为 1500 美元 + 每年维护成本为 3000 美元，而 AppExchange 包含订阅中的所有维护 |
| 优化功能 → 失败的维护 | 反模式:选择自定义开发假设团队可以维护解决方案，尽管没有当前的能力或专业知识 技术债务会随着维护的推迟而累积；解决方案最终变得无法维护，需要昂贵的更换 |