报告核心信息 - 报告类型：白皮书，探讨软件公司范围三使用阶段排放的核算挑战与潜在解决方案 [1] - 报告发布方：BSR (Business for Social Responsibility) [5] - 报告基于：S34S (Scope 3 for Software) 圆桌会议的研究成果，成员包括 AVEVA, Coupa, Sage, SAP 等领先软件公司 [3][4][5] 核心观点 - **关键挑战**：软件产品使用阶段的范围三排放（温室气体核算体系类别11，C.11）核算面临重大挑战，主要源于方法论不清晰、云服务提供商数据透明度不足以及“运营控制权”界定模糊 [13][14][15] - **问题重要性**：软件使用阶段排放，尤其是AI和云工作负载驱动的排放，正快速增长，已成为软件公司碳足迹的重要组成部分，估计占ICT行业全生命周期影响的**56-80%** [16][18] - **当前现状**：软件行业在C.1（采购的商品与服务）与C.11的核算上做法不一，多数公司将云相关排放计入C.1，导致公司间碳足迹难以比较，并掩盖了关键的减排杠杆 [13][23] - **未来方向**：解决此问题需要生态系统各利益相关方（标准制定机构、监管机构、云提供商、软件公司）协同努力，以澄清核算指引、标准化方法并提高数据透明度，从而推动行业脱碳 [21][58][65] 研究主要发现 - **核算方法分歧**：软件公司在C.11核算上存在分歧，方法差异很大，很少有公司主动计算C.11，主要原因是缺乏对云基础设施的运营控制权、无法获取产品级粒度数据，以及缺乏清晰一致的标准和指引 [23][24] - **部署模式决定核算**：托管环境驱动核算决策，保留本地部署基础设施的公司倾向于计算C.11，而主要利用云托管的公司则更关注C.1 [25] - **方法与数据可变性**：在与软件公司和温室气体核算提供商的讨论中，发现以下方面存在显著的方法和数据可变性 [26]： - 供应商特定因素：排放因子获取方式不同，常依赖行业平均值或代理数据 [27] - 基于位置与基于市场的核算：选择不同会实质性影响报告的排放量 [27] - 区域托管与排放因子：工作负载跨区域分布，但位置透明度有限，常被迫使用区域或全球平均值 [27][28] - 年度与月度排放因子：使用月度数据能更好反映电网强度季节性变化，但并非总能获得或使用 [30] - 电力消耗数据：难以获取可归因于特定产品、客户或工作负载的可靠、细粒度电力消耗数据，云提供商常报告代理指标 [30] - 客户使用云与本地环境：混合部署增加了方法论复杂性，难以应用单一、一致的方法 [30] - PUE可比性：PUE的定义和包含内容无统一标准，且它衡量的是非计算基础设施的效率，而非计算本身的效率 [29][30] - **数据获取挑战**：从云提供商获取相关数据仍是关键挑战，缺乏直接的客户实际使用数据访问权限，且云提供商可能因商业敏感性不愿共享基于位置的排放和能源数据 [31] - **AI的影响**：AI的普及加剧了对这些核算问题的关注，AI驱动的工作负载正实质性增加软件公司及其客户的范围三排放 [32] 案例公司实践 SAP：区分C.1与C.11排放的核算 [35][36] - **核算原则**：根据部署模式（本地部署 vs. 云）和运营控制权进行排放分配 [37] - **本地部署软件**：计入范围三 C.11，基于对大量客户系统配置的估计计算年度电力消耗，并使用基于位置的电网排放因子转换，若客户提供可再生能源使用证明则采用基于市场的计算 [38][39][41] - **云软件**：若SAP运营云基础设施，相关排放计入其范围一和范围二；若运行于第三方超大规模云提供商，则按现行做法将电力消耗和采购基础设施的嵌入排放计入C.1 [42][43] - **避免重复计算**：通过按部署模型分离排放（本地软件排放仅出现在C.11，云软件排放出现在自身运营或上游类别）以及明确客户-供应商排放映射来确保可比性和避免重复计算 [46][48] Sage：通过生命周期评估和基准测试衡量范围三使用阶段排放 [35][47] - **研究方法**：与学术及咨询机构合作，使用过程型生命周期评估和混合生命周期评估方法，评估其云托管和本地部署的软件产品 [49] - **关键洞察**：评估结果受以下因素显著影响 [49][50]： 1. 输入数据质量：供应链数据呈现方式缺乏一致性 2. 排放归属：共享基础设施和开发活动的排放分配方式，例如云原生产品因基础设施效率通常排放较低，但总减排量取决于排放归属方式 3. 边界定义：是否包含本地设备的嵌入排放和软件开发排放对结果影响很大 - **后续行动**：该研究帮助公司确定了针对性工作流，包括改进客户和云提供商的数据收集、为同事提供培训、减少产品开发排放以及深入研究Sage AI架构以降低其环境影响 [51] AVEVA：识别和实施范围三使用阶段排放的脱碳杠杆 [35][52] - **挑战**：使用阶段排放占其范围三足迹的最大份额，但缺乏对客户实际配置和使用模式的可见性 [52] - **方法**：对产品组合进行结构化评估，以建立各产品系列的能源强度基准，并与研发部门合作，基于绿色软件基金会的研究识别潜在的脱碳杠杆 [53] - **关键发现**：通过基准测试为大部分产品组合建立了能源强度基线，早期分析表明能源需求因产品、部署类型和客户配置不同而存在显著差异 [54] - **战略转变**：认识到软件相关排放高度依赖客户基础设施决策，因此从纯粹以测量为中心的方法转向将量化与影响力（如提供指南、设计原则和建立合作伙伴关系）相结合的方法 [56] 生态系统解决方案与建议 - **标准制定机构**：应澄清软件使用阶段与上游云排放的边界，并标准化核算方法；更新产品碳足迹计算标准以确保可比性；支持目标设定，明确效率提升和使用阶段减排如何贡献于气候目标 [59] - **监管机构**：应通过披露模板、数据层级和验证指引实现透明度和可比性；认可实用的报告方法；使鉴证期望与实际数据时间和可用性保持一致 [60] - **云提供商与行业联盟**：应提供标准化的服务级排放数据及清晰的分配方法；提供一致的合同数据访问；标准化跨提供商的报告实践以实现可比性 [61] - **软件公司行动**：应跟踪并分离软件使用阶段排放与上游云排放；使内部报告与新兴标准、模板和监管期望保持一致；与提供商和行业联盟合作以获取标准化数据 [61] - **脱碳路径**：软件公司可采取的脱碳途径包括：在可证明效率提升的情况下将工作负载从本地迁移至云环境；与产品开发团队合作提高软件和系统设计的能效；加强对生命周期排放的理解以指导产品现代化和更换决策 [62] - **云提供商角色**：通过持续提高数据中心效率、扩大可再生能源采购、以及提供更透明、有助于决策的数据来推进系统级脱碳 [63]