斯迈尔齿科“顾问，我们把 Fiori 应用库翻了三遍，还是不知道到底该先上线哪几个。”这句话我在 SAP 项目里听客户说过太多次了。确实，打开 Fiori Apps Library，上万个 tile 平铺在那里，每一张看起来都“有用”，但预算、人力、推广周期都有限，Fiori 的落地绝不能靠拍脑袋。我自己做 Fiori 规划时，反而不太愿意从应用目录出发，更喜欢先拉一份系统里真实的事务清单出来，然后让 SAP 官方的 App Recommendations Analysis 帮我把这份事务清单翻译成一张 Fiori 迁移路线图。这篇文章就把这套思路和实操过程完完整整写出来，适合正在做 S/4 或 NetWeaver 系统 Fiori 推广规划、需要从数据出发确定首批应用范围的人。
1. 为什么“事务清单”比“Fiori 应用目录”更值得先看
很多人做 Fiori 需求收集时，第一反应是召集各模块 Key User 开会，问一句：“你们希望以后用 Fiori 做什么？”结果往往是一屋子人沉默，或者抛出一堆不痛不痒的“看报表”需求。原因很朴素：业务用户根本不知道 Fiori 有什么，他们只知道自己天天在 GUI 里敲什么事务码。
事务清单恰恰是业务真实行为的数据快照。它记录的是“这家公司每天到底在做哪些操作、做多少次、谁在做”，不掺水分，不需要访谈，也不会因为某个 Key User 的表达能力强弱而扭曲需求。SAP 在 NetWeaver 7.5 和 S/4HANA 里内置了一套分析能力，俗称 Fiori App Recommendations（分析类应用），它直接把“传统事务码使用统计”和“Fiori 应用目录”做匹配，告诉你：你现在每天跑的这些 Tcode，在 Fiori 世界里分别对应哪些 App，哪些值得第一批迁移，哪些还找不到替代品。
用个生活化类比：事务码是旧小区的门牌号，门牌号背后住的是谁，物业系统里都有登记；Fiori Apps Library 则是一张新小区的导览图，把每个房间的功能都标得清清楚楚。App Recommendations Analysis 就相当于一个中介，拿着旧小区的入住登记表，对着新小区的户型图，帮你把每户人家该搬到哪套房一一对应起来。所以这个工具的输入其实非常朴素——你系统里跑了多久、跑了哪些事务，输出却很实用——一张按优先级排序的 Fiori 应用迁移候选清单。
这个分析还有个容易被忽略的价值：它能在 Fiori 规划的早期帮团队建立对“应用化程度”的清醒认知。很多项目做到一半才发现某个核心流程根本没有标准 Fiori 应用，只能回头做 Fiori Elements 开发或 BSP 扩展。与其后来后悔，不如在需求盘点阶段就让数据把所有“暂时无替代”的事务码暴露出来，提早评估开发量和技术方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据准备：让系统自己说出每天在跑什么
App Recommendations Analysis 最关键的输入不是你的业务蓝图，而是事务使用数据。我第一次用这个工具时犯过一个错误：在刚激活用量测量后第二天就跑去跑分析，结果推荐列表稀稀拉拉，几乎全是“No recommendation available”。后来才意识到，系统要有足够的历史执行数据，推荐才有意义。
2.1 三个数据来源，分别适合什么系统
第一是标准的事务用量测量（Usage Measurement）。SAP 在 NetWeaver 7.0 之后提供了这套机制，通过事务码 USMM 或对应的 Web Dynpro 界面激活，激活后系统会定期把用户执行的事务统计写入后台表 USR41，里面记录用户名、事务码、执行次数和最后执行日期。这个机制适合任何来源的老系统，尤其是 ECC 或已经稳定运行多年的 S/4。
第二是工作负载分析，也就是事务码 ST03N 里的事务使用统计。ST03N 本身是给 Basis 做性能分析用的，但它同样能按日期范围、按用户组、按系统客户端输出事务代码的执行次数。这套数据的优势是历史保留时间长，而且不需要专门激活什么测量开关，很多 Basis 团队本来就开着 workload collection。劣势是它侧重性能统计，字段粒度不如 USR41 细，但用来做 Fiori 迁移排序已经足够。
第三是 Fiori 推荐分析自身读取的标准输出。这个准确说不是独立来源，而是工具在运行时从系统里抽取上述数据后，加上 Fiori Apps Library 的元数据，生成推荐结果。严格讲，全新的 S/4HANA 系统如果上线时间短、用户操作量小，所有来源的数据都会很薄弱，这时候不要强行跑推荐，先把系统跑上一个月再说。
2.2 激活用量测量这件事，建议尽早做
如果你所在的系统还没激活 USMM，我建议尽早做，别拖到项目启动以后。激活本身不复杂，大致步骤是：运行事务码 USMM，在界面里维护分析客户端、技术用户和时间范围，然后保存激活。不同支持包版本之间界面字段差异挺大，具体以你系统现状为准，但核心逻辑一样——激活后它会创建一个后台采集任务，把每天的事务执行情况沉淀下来。
激活后不是立刻生效，而是从下一个采集周期开始记录。所以如果你计划三个月后做 Fiori 首批范围盘点，最好现在就激活。等到盘点前一周才想起来，数据就只覆盖了几天，那些月度业务（比如月末结账、批次结算）往往不会被捕捉到，推荐结果自然失真。
提示：千万别在生产系统上手动去跑大批量的统计 SQL 反复核对推荐结果，分析工具本身已经是读统计表，不是直接扫应用表，不建议人为制造额外负载。
2.3 用一张表快速核查数据是否“够厚”
正式跑推荐分析之前，我习惯先直接查询 USR41 看一眼数据覆盖度。最简单的方式是在 SE16N 里输入表名，按执行次数倒序排列，看看排名靠前的事务码是不是符合这家公司的行业和主营场景。
如果系统没有激活 USMM，也可以通过 ST03N 的导出功能把近 90 天的事务使用记录拉出来，整理成一个 CSV，后续做推荐结果交叉验证。需要注意，ST03N 的事务统计里可能包含很多开发机、测试机的噪音数据，分析之前建议先按客户端或用户组过滤掉非生产业务流量：
sql复制-- 示例：检查 USR41 中主要事务码的使用热度（仅示意，字段以实际版本为准）
SELECT TCODE, UNAME, COUNT(*)
FROM USR41
WHERE UNAME NOT IN ('SAP*', 'DDIC')
GROUP BY TCODE, UNAME
ORDER BY COUNT(*) DESC
LIMIT 50;
一句话总结：数据准备阶段不要急着“跑工具”，先回答两个问题——系统已经记录了多久的事务使用？数据里的业务形态是否完整覆盖日、周、月不同周期的操作？这两个问题有了答案，推荐分析才有价值。
3. 跑一次 App Recommendations Analysis，并把匹配逻辑讲清楚
数据够厚之后，分析本身反而很快。我通常打开 Fiori Launchpad，在 App Finder 里搜索 “App Recommendations” 或直接通过事务代码 /UI2/APPREC 打开（不同版本入口名称略不同）。打开后它会要求你确认分析实例、分析客户端和时间段。建议第一次跑的时候选最近 90 天，因为 90 天基本能覆盖三个月内的月结、季结业务。时间选太长，比如一年，结果里会混入已经被替代掉的旧流程；选太短，低频高价值事务又会被漏掉。
3.1 运行过程中的几个选项，分别控制什么
- 分析实例：选择要分析的后端系统。如果是集中部署的 Hub 架构，可能同时有多个后端接入同一个 Fiori 前端，这时候要选对系统，否则推荐结果全错位。
- 客户端：默认是当前登录客户端。但如果你的生产数据在另一个客户端，就要显式切换到那个客户端。这个选项特别容易忽略，我见过同事在 QAS 上跑推荐，结果把测试客户端里刷出来的垃圾数据当成生产需求。
- 时间范围：前面说了，推荐用 90 天。理论上系统会统计这段时间内的事务执行频次，然后与 Fiori 应用目录做匹配。
点击执行后，系统会在后台做匹配，不是瞬间完成。数据量大时可能需要几分钟。完成后会看到一个推荐列表，通常能直接导出为 Excel，这个 Excel 是后续所有路线图讨论的底稿。
3.2 别把推荐结果理解成“事务码一对一翻译”
这是整个工具最容易被误解的地方。很多人看推荐结果时，期待的是“Tcode FB50 → Fiori App 管理日记账”，但实际结果往往不是这么干净的线性对应。SAP 的匹配逻辑是基于业务场景和用例，而不是基于事务码名称。一个 Fiori 应用可能替代多个传统事务码，反过来，一个事务码也可能对应多个 Fiori 应用——因为传统事务码往往承担了多个职责，而 Fiori 应用把职责切成了更细的流程片段。
举例说，MM01（物料主数据创建）在传统 GUI 里是个大杂烩事务码，什么都干；但 Fiori 应用目录中，物料主数据相关的 App 可能按“创建物料”“更改物料”“查看物料”等场景拆开，工具会把推荐的 App 对应到不同场景下。所以看推荐结果时，要注意它的“推荐理由”字段。里面通常会写明“该应用基于您系统内 xx 事务码的使用情况推荐”，这个理由就是匹配逻辑的线索。
3.3 导出之后，第一轮清洗和过滤
分析做完后我会马上做一轮人工清洗，原则有三：
- 剔除开发类事务码。SE80、SE11、SM30 这类技术性事务码即使使用频率很高，也不应该作为 Fiori 推广的候选。原因是这些是 IT 人员才用的功能维护入口，跟业务用户没有关系。
- 剔除配置类事务码。很多顾问在项目前期用配置事务码，比如 SPRO 相关，在系统里留下大量使用记录。它们没有 Fiori 化价值，应该直接从清单里划掉。
- 关注低频高业务价值事务码。有些事务码一个月只用几次，但是结算、关账、审计这类关键业务。推荐工具的排序会偏向高频操作，而人工复核时要把这类“低频但重要”的找回来。
做完这三件事，清单才算真正具备了做优先级排序的基础。
4. 推荐结果不是终点：把它翻译成迁移优先级
拿到推荐清单后，很多团队会犯一个错误：直接按照工具里的推荐顺序排期，推荐在前面的就先迁移。这是把“使用频次”和“业务价值”混为一谈了。使用频次高只代表它天天被点，不代表迁移它就能带来明显的效率提升。真正该做的，是把推荐结果放到一个“迁移优先级矩阵”里重新排序。
4.1 用“使用频率”和“替代程度”两个轴做分类
我习惯把推荐清单里的每一项都打上两个标签：
- 使用频率：来自 USR41 或 ST03N 的事务执行次数，直接取数即可，高、中、低三档。
- 替代程度：看推荐结果里是否有高匹配度的 Fiori App，并且该 App 是否已经可以直接上线，高、中、低三档。
两个轴交叉后，得到四种典型策略：
| 使用频率 | 替代程度 | 处置策略 |
|---|---|---|
| 高 | 高 | 首批迁移，直接替换 |
| 低 | 高 | 不单独推，等角色整体切换时顺带迁移 |
| 高 | 低 | 需要重点评估，要么开发扩展，要么调整流程 |
| 低 | 低 | 暂时保留在 GUI，不做消耗 |
这个矩阵是我在几个项目里反复调出来的实用分类法。它解决了一个核心矛盾：Fiori 推广范围不能只看“哪个 App 有”，也不能只看“哪个事务码点的多”，而是看两者的交集是不是足够大、足够高。只有“用得最狠、替代最现成”的那批，才值得放进第一批上线清单。
4.2 为什么推荐列表里还会有“找不到替代”的事务码
遇到“高使用频率 + 低替代程度”时，我不建议急着把它定义为项目失败，而是先看它属于哪种情况。
第一种情况是事务码本身就是技术运维类，永远不会有 Fiori 替代，这个直接排除。第二种情况是这个事务码代表的业务在标准 Fiori 应用目录里确实没有覆盖，但它的业务场景可以通过自定义 Fiori Elements 列表报表实现。第三种情况是系统版本太老，对应的 Fiori App 只在更高的 S/4HANA 版本里提供，需要先升级再谈迁移。搞清楚这三种情况，项目范围决策就清晰多了：第一种不投入，第二种排进开发池，第三种联动系统升级计划。
4.3 人工复核时，别漏了“事务码背后的角色”
还有一次，我在做推荐结果的优先级标注时发现，清单里一个采购类事务码使用频率很高，推荐工具给了一个非常好的 Fiori 应用，但我们对这个应用的上线时间定得很晚。后来去翻业务流程才发现，这个事务码只属于仓库管理员的夜间收货场景，用户数量极少，工具统计的“高频率”完全来自少数几个用户每天重复操作。高频确实是真的，但影响面很窄，优先级不该靠单纯频率定，而是“频率 × 影响用户数 × 业务重要度”的综合值。
所以我在推荐结果上会再多加一列“影响用户数/角色数”，从 SUIM 的用户分配或角色事务码里拉出来填进去。这步看起来费劲，但能避免把资源浪费在只有三个人用的高频事务上。
5. 从推荐清单到 Fiori 路线图：分组、排期与落地
标题里写的“路线图”不是什么高深的战略，落到项目里就是一张带时间和责任人的实施计划。我的经验是，推荐清单必须经过分组和排期，才能真正变成团队能执行的东西。
5.1 四类分组的落地逻辑
我习惯把清洗后的推荐清单分成四组，这里直接在计划里体现为四个标签：
- Migrate：替代程度高，直接迁移为标准 Fiori App，不进开发。
- Enhance：没有标准替代，或标准替代与业务有差距，需要做 Fiori Elements 或 UI5 扩展开发。
- Bundle：有替代但使用频率不高，不单独排期，等某一批角色上的多个 App 一起切换。
- Park：暂时没有替代或业务优先级低，继续留在传统 GUI，每个季度重新回看一次。
这个分组的核心思想是：不让“没有标准 App”阻塞整体路线图。一个 Route 里可能 70% 是 Migrate，20% 是 Bundle，10% 是 Enhance。做计划时，Migrate 和 Bundle 可以划为一个实施批次，Enhance 单独作为一个开发批次。
5.2 四阶段路线图，可以直接拿去改
我常用下面的阶段结构来组织一张 Fiori 推广路线图：
| 阶段 | 主要任务 | 产出物 | 典型周期 |
|---|---|---|---|
| Phase 0 数据盘点 | 激活用量测量，抽取 90 天事务使用数据，核查数据质量 | 事务清单、使用频率报表 | 1-2 周 |
| Phase 1 推荐分析 | 运行 App Recommendations，清洗推荐结果，按矩阵分组 | 迁移候选清单、优先级矩阵 | 1 周 |
| Phase 2 试点上线 | 挑 2-3 个高价值场景，做小范围推广和用户反馈收集 | 试点应用、用户反馈、性能基线 | 3-4 周 |
| Phase 3 批量推广 | 按角色、组织单元分组切换，配合培训与超时管理的调整 | 上线应用全集、日活报表 | 按批次 1-2 月 |
| Phase 4 回评与迭代 | 用 Fiori 使用统计看真实采用率，更新 Park 清单 | 采用率报表、下一批迁移候选 | 每季度 |
这个过程里，很多人只关心前三阶段，其实第四阶段才是让路线图保持生命力的关键。Fiori 上线不是一次性的“搬家”，而是持续行为引导。我每季度都会在系统中看一次 Fiori 使用统计和事务代码使用统计的对比，看哪些传统 GUI 事务码还在被高频点击，如果某个已经迁移了的事务码在 GUI 端仍然高频使用，说明用户在绕道，推广或关闭旧路径的策略有问题。
5.3 路线图不是静态 PPT，而是一个持续更新的队列
这一点是我最想强调的。很多项目把路线图做成一页倒排期甘特图，然后锁进共享盘，半年没人更新。其实 Fiori 推广路线图应该像一个滚动 backlog：每季度跑一次 App Recommendations 分析，每半年重新排一次优先级，新上线的业务模块随时可以插入到后续批次里。推荐工具的价值就在于，它不需要你重新做需求访谈，只需要定期重新拉取系统使用数据，就能自动更新候选清单。
6. 实测中容易踩的坑：Debug、沙盒启动与 403 CSRF
Fiori 规划不是跑完推荐工具就结束，到了试点上线的阶段，我们必然要和前端联调打交道。这里把我踩过几次的坑集中写出来，很多都和前面“从清单到落地”的过程直接相关。
6.1 Fiori 前端怎么 Debug：别只按 F12
Fiori 页面报错，第一反应是打开浏览器开发者工具看 Console，这没问题，但前端报错往往只是“结果”不是“原因”。完整的思路是：先看 Network 标签里的 OData 请求是否成功，如果某个请求返回错误，要记录下请求的 URL、请求体、响应体；随后到后端事务码 /IWFND/ERROR_LOG 查网关错误日志，这里面能看到 OData 服务的具体异常堆栈。
对于 Fiori Elements 应用，我推荐在 URL 后追加 ?sap-ui-debug=true 进入调试模式，可以获得更详细的组件加载信息，包括 controller 和 manifest 的报错位置。记住一个原则：Fiori 前端调试要三层联动——浏览器、网关错误日志、ABAP 应用日志。只盯 F12 很容易被误导。
6.2 沙盒启动白屏：先检查服务和代理
这个问题在开发环境尤其常见。“沙盒启动”通常指本地 mock 数据或单人测试环境。启动时若遇到白屏，最常见的原因有三个：SICF 服务没激活、CORS 跨域配置没放开、mock 数据服务没启动。快速排查顺序是：浏览器 Network 里看静态资源是否正常加载；再检查 launchpad 对应的 SICF 节点是否激活；最后确认有没有配置对前端的代理转发规则。很多团队因为漏了 SICF 激活，折腾一下午，最后只是点一个“激活服务”按钮的事。
6.3 接口返回 403 CSRF：写 OData 请求一定要带 token
Fiori 应用里如果做自定义扩展，比如在 UI5 里直接调用 OData 服务的 CREATE 或 UPDATE 操作，大概率会撞上 403 CSRF 保护。这是网关服务默认的安全机制，本质是要求写请求先通过一次读请求获取 CSRF Token，再携带 Token 发起真正的写操作。
具体流程是：
- 先发一个 GET 请求到目标 OData 服务，Header 带上
x-csrf-token: fetch。 - 服务端会在响应 Header 里返回一串 Token，例如
x-csrf-token: 9D1C...。 - 把这个 Token 放进 POST/PUT/PATCH/DELETE 请求的 Header 里，请求才会被正常处理。
如果用了 Fiori Elements，框架在大多数场景下会自动处理 token 获取，但当你用 Ajax 或自定义 fetch 直接调服务时，就要自己实现这个两段式流程。遇到 403 时，先检查 Token 是否为空、是否过期、Header 名是否和网关配置完全一致，这三个位置几乎覆盖了九成以上的 403 问题。
调试 CSRF 时一个小技巧：先用 Postman 手动跑通“GET 取 token → POST 带 token”的完整流程，再回代码里排查。如果 Postman 也 403，说明问题在服务端配置或权限，不是前端代码问题，省得在浏览器控制台里干瞪眼。
最后再分享一个我觉得非常实用的小技巧：拿到 App Recommendations 导出的 Excel 后，不要只按推荐顺序看，加两列辅助字段——“对应事务码执行次数”和“影响角色数”，然后先按“业务价值=高”筛选，再按执行次数降序，最后按影响角色数降序。这样排出来的前 20 项，基本就是最稳妥的第一批 Fiori 上线清单。这个排序方法看起来土，但在多个项目里都比工具自带的默认排序好用得多。