斯迈尔齿科“顾问，我们把 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 做性能分析用的，但它同样能按日期范围、按用户组、按系统客户端输出事务代码的执行次数。这套数据的优势是历史保留时间