开发访问一人占两个 FUE，是四档用户类型里最贵的一档，而且它经常不在开发组的名下，而是混在业务角色的授权清单里。本文依据 SAP 官方 FAQ 与 2024 年产品材料的互证，加上项目里的角色清理实测，讲这笔账怎么算、坑藏在哪里。
四档换算逻辑
官方口径的换算关系是：1 Developer 等于 2 FUE，1 Advanced 等于 1 FUE，5 Core 折 1 FUE，30 Self-Service 折 1 FUE。官方 FAQ 给过一个算例：10 个开发者、53 个高级、20 个核心、90 个自助，合计 10×2＋53＋20÷5＋90÷30 等于 80 FUE，订阅只有 60，缺口 20。这里有个容易读反的地方。FAQ 权重表写的是「每 1 FUE 可折算的用户数」，Developer 一栏是 0.5，乍看像开发者只占半个，实际是 0.5 个开发者折 1 FUE，每个开发者占满 2 个。我们项目上最初也按直觉记反过，三份官方材料互证后才定案，方向别再搞错。
这个算例值得展开推一遍。10 个开发者贡献 20，53 个高级贡献 53，20 个核心折 4，90 个自助折 3，合计 80，对上 60 的订阅，缺口 20。补缺口时各档的兑换比差别很大：高级往核心降，5 人才抵 1 个 FUE；核心往自助降，6 个换 1 个；而剥离一个混进业务角色的开发授权，直接回收 2 个 FUE，等于 2 个高级、10 个核心或 60 个自助的量。开发档的杠杆最大，值得单独当成一条优化线来排。
开发档贵类型许可
官方产品资料对四档的权利关系有一条逐字原则，越贵的使用类型总是包含越便宜类型的能力。Advanced 含 Core，Core 含 Self-Service，每一档都带 Display Use Rights，可以查看全部事务数据与主数据。主数据维护由 Core 与 Advanced 覆盖，Self-Service 不含。但开发访问不在纵向嵌套链上，买了 Advanced 不等于自动获得开发能力，它是独立品类，这也解释了它为什么单独计价、单独翻倍。还有一句要记，用户类型的法律终局定义在 Service Use Description 里，产品资料与价目表页都不是最终法律依据，条款冲突时以 SDG 为准。顺带把 G 系其余类型交代全，GE 是支持访问，GF、GG 是技术类与技术使用，走各自判定，不挤占前四档的换算。
业务角色混入的贵类型许可
开发访问贵不贵，关键看它长在哪里。S_DEVELOP、SE16 这类编辑类授权混进普通业务角色，持角色的业务用户就会被规则判成开发者，按 2 FUE 计价。规则集的 Step 10 内置 #DEV# 开发者检测，这不是事后统计，是分类层自动扫的。角色清理时把开发类授权对象从业务角色里剥离出去，是与 GB 降 GD 并列的第二条优化线，两条线各自独立，可以并行推进。
剥离的操作路径，项目上走的是四步。先拿分类报告的 Step 10 判定名单，圈出被判成开发者的全部用户；再逐个定位其授权来源，区分真开发者与被污染的业务用户；然后把开发类授权对象从业务角色里拆出去，归入专用开发角色或工具账号；最后重跑分类，确认判定落回应有的档位。风险也有两处。剥得过猛会伤开发效率，传输与排障依赖的临时授权要有替代出口；工具类账号与技术用户的归属口径要先定好，别在清理时把系统账号一并卷进去。
对账工具也要开发授权
还有个容易忽略的细节。官方 FUE 明细对账工具 ZR_FUE_VERIFY 的前置条件，恰好是 S_DEVELOP 授权加开发包加传输请求。也就是说，想在对账上掌握主动，先得把开发授权的边界理干净：该给工具账号的给工具账号，该从业务角色剥离的剥离。生产系统每月计量后跑一遍对账，分类争议就能在 SAP 开口之前自己先看到。
工具本身出自 Note 3795409，SAP 提供的是 ABAP 报告源码附件与一份用户指南，客户在 SE38 自建程序、贴入源码、走传输、再到目标系统执行，不需要额外采购授权。输出给每个用户两列判定，一列是按当前规则集本应分到的类型，一列是月度计量实际采用的结果，两列对不上的行就是分类争议点。执行位置有个讲究，Developer 用户只在开发系统被分类，部分 Advanced 用户也可能落在开发系统，所以生产与开发要各跑一遍，只看生产会漏掉半个开发档。月度计量本身每月 1 日自动触发，遇周末或德国公共节假日顺延，只计生产与开发系统，QA 不在计量范围。
数字怎么到 SAP 手里也值得知道。计量把用户按哈希过的 User ID 匿名化后传出，SAP 在中央 LAW 里做合并，FUE 按用户名跨系统归并，再叠加合同权益生成 Consumption 看板。多系统客户留意，同名账号跨系统的用量会被并到一起算。官方另有一份 FUE Calculation Tool 的 Excel，适用两个私有云价目表，FAQ 里的直链已经失效，现在要经客户团队或支持渠道获取。手工估算用换算公式就够了，工具的价值在于给谈判留一份可以来回调参的底稿。
低于四十个 FUE 的另一种谈法
换算之外还有一道采购结构题。私有云两个价目表的最低采购门槛都是 40 FUE，测算下来需求不足 40 的客户，谈判焦点就从压单价变成凑门槛还是砍范围。官方口径里留了一条合规通道，FUE 订阅内可以跨类型再分配用户，先按高类型买少量、随优化推进把用户往低档调，不会造成买多了的沉淀。另有一个与账面直接相关的坑，计量组件的补丁纪律。此前出现过自动分类规则集失效后系统回落默认分类、FUE 虚高的先例，对应的修正 Note 出在 2025 年初，订阅客户每月拿到数字异常时，先核补丁再谈分类。
先清污染，再谈降级
本文首发于 sapzx.com，版权归 河.南-赛‧锐•信•息·科_技‧有.限-公·司 所有，未经授权请勿转载。
FUE 账上的杠杆值得单独记一笔。开发档单人计 2 个 FUE，是核心档单人的十倍，一个混入业务角色的开发授权吃掉的量，靠高级降核心攒回来得用两个半降级名额，所以清污染源永远排在降级次序前面，GB 往 GD 降与开发授权剥离是各自独立的两条线，可以并行推进，别只盯着前一条。对账别只跑生产，开发系统那一遍才是开发档的主战场。审计底账怎么搭，见《SAP 许可审计中的计量分类与 FUE 对账》；角色层面的职责分离审查方法，见《SAP 权限审计实战：如何有效进行职责分离 (SoD) 审查》。
随着 SAP 产品从 ECC → S/4HANA → RISE with SAP（S/4HANA Cloud Private Edition, PCE）的持续演进，SAP 许可模式已从传统的永久授权、模块化计费，全面转向以 FUE（Full Use Equivalent）为核心的订阅化、精细化授权体系。这一变化深刻影响了企业的用户角色设计、权限治理、合规审计以及长期 IT 成本结构。在 PCE 模式下，FUE 许可的计量方式更加依赖实际使用行为，对企业在账号分配、权限控制、并发使用与审计合规方面提出了更高要求。
赛锐信息深耕 SAP License 审计与合规治理领域，长期服务于 SAP ECC、S/4HANA 及 RISE with SAP 客户，在 SAP 官方审计流程、FUE 许可优化策略及账号资产精细化管理方面积累了丰富的咨询与实施经验。依托自主研发的 SAP License / FUE 资产优化软件产品（AMS-V），我们帮助企业在满足 SAP 合规要求的前提下，提升 FUE 许可利用率、降低订阅成本、控制审计风险。欢迎随时联系我们，获取 SAP FUE 许可优化咨询服务，并申请产品试用与方案演示。让 SAP 投入真正服务于业务增长，而非成为成本负担。
