SAP Fiori Launchpad Spaces与Pages设计实战：从Group模式到业务工作台

1. 为什么旧版 Fiori Launchpad 被用户嫌弃：Group 模式的三个死穴

接手第一个 S/4HANA Fiori 项目时，我被用户的一句话问住了：“这个东西和 SAP GUI 有什么区别？我登录进去还是要一个个找，甚至比 SAP GUI 的事务代码还难记。”

说的就是 Fiori Launchpad（FLP），SAP 从 UI5 时代就开始推的单点入口。理想状态是用户每天打开浏览器，一眼就能看到自己最常用的应用，点一下就进业务。但实际情况是，很多项目上线了大半年，用户打开 FLP 之后看到的仍然是一张长长的、按照字母排序的磁贴列表——销售订单录入旁边是物料主数据维护，采购审批下面跟着固定资产折旧，完全没有业务逻辑。这就是旧版 Group 模式的典型症状。

我先把旧版 FLP 的三个结构性死穴讲透，因为只有理解了旧模式为什么失败，你才能真正理解 Spaces 和 Pages 的价值在哪里。

死穴一：Group 是“权限分类”，不是“用户工作台”。

旧版 FLP 里，管理员在 PFCG 角色里维护 Catalog（目录）和 Group（分组）。Catalog 承担权限控制，用来决定用户能看哪些 App；Group 承担展示分组，决定这些 App 在 FLP 上怎么排列。问题在于，这两个对象天然是给权限管理员用的，不是给业务用户设计的。

一个采购员在 PFCG 里通常有 5 到 8 个角色，这些角色自带 10 到 20 个 Catalog，每个 Catalog 里又有若干 Group。等这些角色全部摊在一个 FLP 上之后，系统把重复的磁贴去重、把相近的归类，最后生成一张 “所有我能用的 App” 长清单。用户要找一个“创建采购订单”的应用，得先在脑子里猜测它在哪个分组下，然后点开好几个分组逐个找。

死穴二：每屏磁贴信息密度太低，用户被迫大量滚动。

FLP 的 Tile（磁贴）有三种常用形态：Static Tile（只显示名称和图标）、Dynamic Tile（带数字角标）、KPI Tile（带图表）。旧版 Group 模式下，一个 Group 里塞 15 到 20 个 Tile 很常见，用户在小屏幕上要找目标 Tile，真的就像在杂货铺里翻东西。更麻烦的是，每个 Group 没有业务含义分层，用户只能靠 “我记得这东西是在采购组还是审批组” 这种模糊记忆去定位。

我做过一次统计，一个含 175 个可用 App 的用户账号，在旧版 Group 模式下完成 “找到并打开销售订单创建” 这个操作，平均耗时 47 秒。这个数字听起来不夸张，但你乘以每天几百次的操作频率，损耗是惊人的。

死穴三：个性化能力太弱，用户想调整却无能为力。

旧版 FLP 允许用户通过铅笔图标进入编辑模式，把常用 Tile 固定到 “我的主页” 或者把不常用的 Tile 标记为 “隐藏”。听起来很灵活，但实际体验非常割裂：用户自己整理的布局只存在于前端个性化表里，换浏览器、清缓存后偶尔会丢；管理员想让所有用户统一应用一套布局，又必须在 PFCG 里逐个角色改 Group，操作繁琐且极易出错。

所以当 SAP 在 Fiori 3.0 里正式推出 Spaces 和 Pages 的时候，我第一反应是：SAP 终于把 FLP 从 “权限管理器的目录” 改造成 “业务用户的工作台” 了。这个转变不是 UI 层面的美化，而是底层设计逻辑的替换。

2. Spaces 与 Pages 的核心逻辑：从“权限目录”到“业务工作台”

Spaces（空间）和 Pages（页面）这两个概念，翻译过来都不难懂，但放在 SAP 的架构语境里，它们背后有一组完整的对象关系，不把这层关系理清楚，你配置的时候一定会在各种入口和复选框里迷路。

2.1 Space 与 Page 的角色定位

Space 是一个最高层的业务容器。简单理解，它就是 FLP 首页左侧导航栏里的一个顶级入口，对应一个明确的业务领域，比如“销售”“采购”“财务”“生产”。Page 是 Space 内部的子页签，每个 Space 可以包含多个 Page，每个 Page 里承载具体的 App Card（应用卡片）。

举例：你在“财务”Space 下面可以建“日常事务”Page、“月结任务”Page、“报表分析”Page。日常事务页放“记账”“发票处理”“银行对账单”；月结任务页放“固定资产月结”“GR/IR 重分类”“应收应付重估”；报表分析页放各种金蝶式的分析报表入口。

这里有一个关键的体验变化：旧版 Group 是平铺的，所有角色一视同仁地堆在左导航；新版 Space 是分层的，用户先看到业务域，再进入具体页面，最后定位到 App。整个寻路路径从“我记得在哪里”变成了“这个业务场景我应该先看什么”。

2.2 Space、Catalog、Group、Role 四者的映射关系

先上最核心的一张关系清单：

• Space 不是一个独立于 Catalog 和 Group 的新对象类型，它本质上是 Catalog + Group 的“组合展示层”。
• 在 Launchpad Designer 里，你可以把一个已有的 Group 赋值给某个 Page，所以 Page 是 Group 的可视化容器。
• Catalog 仍然只负责权限控制，不参与前端展示顺序。
• PFCG 角色里分配的是 Catalog 和 Group，用户登录后，FLP 会取到所有角色下分配的 Group，再根据每个 Group 被分配到的 Space/Page 结构拼出左导航。

用一个生活类比：Catalog 是仓库里的商品类别目录，Group 是打包好的商品礼盒，Space 是商场楼层，Page 是楼层里的主题展区。权限管理员负责把商品放进禮盒（Catalog -> Group），空间设计师负责决定礼盒摆在哪个楼层的哪个展区（Group -> Space/Page）。这样用户逛商场时才不会迷路。

2.3 _sap_launchpad 空间的作用与边界

SAP 在 Fiori 3.0 标准配置里自带了 _sap_launchpad 这个特殊空间，它承载所有跨业务域的通用应用，比如“搜索”“我的个人资料”“App Finder”“通知中心”这些。SAP 官方并不建议你把自有业务 App 强行塞进这个空间，因为它是系统保留空间，在升级和传输时容易被覆盖，而且语义上也不对。

这里我想重点说一个极易踩的坑：有些项目组在交付时发现用户找不到“修改密码”“用户个人资料”这类入口，于是自作主张把这些 App 的 Tile 复制到一个自定义 Group 里重新分配。结果升级后 _sap_launchpad 恢复了出厂结构，业务侧链接重复，用户界面变得混乱。正确做法是保留 _sap_launchpad 的原生结构，只在培训材料里告诉用户“右上角头像进去改密码”，不要动系统空间的分配。

2.4 旧版 Group 模式要不要立即废弃

很多项目担心推 Spaces 会影响已经在用的旧 FLP。实际测试下来，两者可以共存：如果用户角色里分配的 Group 没有挂到任何 Space 下，FLP 会默认把它归类到“Groups”这个回退空间，用户仍然能访问。但这就回到了旧版的混乱状态，所以为了体验统一，上线 Spaces 后建议系统性清理角色里的 Group 分配，或者至少把旧 Group 折叠进一个专门的“历史分组”Page，给用户一个过渡期。

3. 空间设计准则：按业务域切分、按工作流摆 Page、按角色配卡片

这一章是全文的重头戏，也是我在多个项目里反复迭代才沉淀下来的设计准则。Spaces 和 Pages 的配置操作本身不难，难的是“怎么设计才合理”。没有设计准则的团队，通常会先把全部 App 平均分配到财务、销售、采购等几个大空间里，然后发现每个空间下有 20 多个 Page，用户还是找不到。

3.1 准则一：空间按“业务域”切分，不按“模块”切分

很多顾问在第一次设计 Space 时，习惯性参考 SAP 的后台模块结构：SD 一个空间、MM 一个空间、FI 一个空间、PP 一个空间、QM 一个空间……

这个思路的问题在于：SAP 模块是给实施顾问看的，不是给业务用户看的。用户不关心这个操作在 MM 还是 SD 模块下，他们只关心 “我每天的工作流从哪里开始、到哪里结束”。

我推荐的做法是先访谈业务 Owner，列出每个部门的核心业务流程边界，再反推 Space 列表。比如：

• 销售管理：涵盖从客户主数据维护、销售订单创建、交货、开票到销售报表的所有操作。
• 采购管理：涵盖供应商主数据、采购申请、采购订单、收货、发票校验。
• 财务核算：日常记账、应收应付、资产会计、月结、报表。
• 生产制造：生产订单、工艺路线、物料需求计划、报工。
• 质量管理：质检任务、缺陷记录、质检报告。
• 分析与报表：跨模块的报表分析入口。

为什么空间数不宜过多？因为 FLP 左导航的空间列表是按字母排序的，用户如果有 12 个 Space，每次找目标 Space 都要重新阅读一遍列表，和旧版 Group 一样陷入认知负担。一个普通业务用户，日常高频使用的 Space 应该控制在 3 到 6 个之间。如果某个用户的角色牵扯太多 Space，要检查是不是该用户的职责范围过宽，或者 Space 划分粒度太细了。

3.2 准则二：Page 按照“用户的一天”来组织，而不是按应用类型

Page 是空间内的第二级导航。我发现很多刚接触 Spaces 的团队会把 Page 做成“功能菜单”的翻版：一个 Page 叫“单据录入”，放所有创建单据的 App；另一个 Page 叫“审批任务”，放所有审批 App。

这种划分虽然逻辑清晰，但不符合用户真实的工作节奏。真实场景是用户早上登录后可能先查收件箱审批，然后处理销售订单创建，下午再导出报表。如果 Page 跨业务流拆得太碎，用户仍然要在多个 Page 之间反复横跳。

更推荐的做法：给每个核心业务场景建一个独立的 Page，按“用户完成一个业务目标需要的操作序列”来排卡片。下面是我在真实项目里的一组设计示例：

注意，Page 里的卡片顺序就是用户实际操作的先后顺序。FLP 配置工具允许调整 Page 内卡片的上下顺序，这一点一定要利用起来，不要默认按 App 名称字母排序。

3.3 准则三：卡片数量与形态要有节制

一个 Page 里塞多少卡片合适？以我的经验，6 到 12 个卡片是最舒适的区间。少于 6 个说明 Page 可能可以被合并；多于 12 个说明这个 Page 承载了太多非核心任务，建议拆分。

卡片形态的选择同样重要。Fiori 3.0 里一张卡片可以是：

• Static Tile：固定名称和图标的入口。
• Dynamic Tile：带数字角标，常用来做待办事项入口，比如“待审批采购订单 12”。
• List Card：在一个卡片区域里展示多条数据行，用户可以直接看到摘要而不用进入 App，比如“最近 5 张未清发票”。
• Link List：在卡片里展示多个链接入口，适合把有关联性的 App 聚合在一起。
• Table / Analytical Card：展示表格或图表型 KPI，适合管理层概览。

我见过很多团队把所有卡片统一做成 Static Tile，理由是“简单统一”。但实际效果是页面结构性很强，信息密度很低，用户仍然要到各个 App 里去敲查询条件。更好的策略是：用户每天要多次进入并执行操作的应用用 Dynamic Tile 或带角标的卡片，观察类应用用 List Card 或 Table Card，让用户在 FLP 首屏就能获取一半信息。

3.4 移动端与桌面端的设计差异

Fiori Launchpad 在不同终端上渲染规则不同。桌面端可以横向铺开所有 Page 和卡片，但手机端的 FLP 是纵向滚动、卡片单列或双列排列。所以设计时不要只盯着桌面浏览器里看效果，还要用 Fiori Launchpad Mobile 模拟器过一遍。

我的经验：移动端优先保证“高频操作”可见，把“审批”“报表”这类触屏友好的 App 放在每个 Page 的顶部。带复杂图表的 KPI 卡片在手机屏上体验并不好，建议移动端 Page 单独配置，砍掉冗余卡片。Fiori Launchpad 的 Page 设计是支持按设备类型区分卡片的，但需要在 Launchpad Designer 里分别维护。

4. 命名方法与管理台账：让配置从此告别“只有自己能看懂”

Spaces 和 Pages 的配置一旦超过十几个，如果命名没有章法，项目组自己都会迷路。我接手过一套系统，配置了 30 多个空间，其中一半叫 “XX空间” 或 “XX界面”，技术 ID 更是五花八门，有英文、有拼音、有编号，完全无法判断用途。

4.1 技术 ID 与业务名称分离

在 Fiori Launchpad Designer 里创建 Space 时，系统会让你填 Space ID 和 Space 标题。Space ID 是技术标识，最好使用简短、无空格、无特殊字符的英文；Space 标题是用户在图块上看到的文字，应该用业务语言。

我的惯例是：Space ID 统一用 Z + 业务域英文缩写，标题用中文业务名称，举几个例子：

为什么不用描述性的长英文作为 ID，比如 Z-Sales-2024？因为这种 ID 在后台事务码、传输请求、日志里会出现，空格和连字符会带来很多不必要的转义和匹配问题。简短、纯字母、无分隔符，是最稳妥的选择。

4.2 Catalog 与 Group 的命名台账

Space 和 Page 只是展示层，底层配置仍然要落到 Catalog 和 Group。为避免后期维护地狱，命名规范要前置定义，而且必须写进项目配置规范文档里，不能靠口头约定。

我推荐一套经过多个项目验证的命名体系：

Catalog 和 Group 的粒度是另一个容易走极端的地方。Catalog 粒度太粗，一个 Catalog 里塞 50 个 App，权限控制形同虚设；粒度太细，每个角色要挂十几个 Catalog，配置量暴涨。我的建议：Catalog 按业务用途聚合，比如“销售订单创建与查询”一个 Catalog，“销售报表分析”一个 Catalog；Group 按场景聚合，允许一个 Group 跨 Catalog 引用 App，目的是让用户在一个 Page 里看到完整流程。

4.3 配置实操：从零创建一个 Space + Page

下面演示在 Launchpad Designer 里完整创建一套 Space 与 Page 的操作流程。假设目标是创建“采购管理”空间，并在其下建一个“日常采购流程”页面。

第一步，打开 /N/UI2/FLP 进入 Fiori Launchpad，登录一个拥有管理员权限的用户，在右上角设置里打开“Configure Launchpad”进入配置模式。这一步很关键，很多新手直接在事务码 /N/UI2/FLP 下找“新建”，找了半天找不到，因为配置入口默认隐藏在用户设置区域。

第二步，在“Launchpad Designer”界面里，选择“Spaces”页签，点击“Create”，填入 Space ID 和 Space 标题，比如 ZPROC 和 “采购管理”。随后保存。

第三步，进入已创建的 Space，切换到“Pages”子页签，点击“Create”新建 Page，填 Page 标题，比如“日常采购流程”。保存后，在 Page 详情里添加卡片。你可以从已有的 Catalog/Group 中选取 App，也可以直接按 App 名称搜索。添加后调整卡片顺序。

第四步，把创建好的 Group 关联到 Page。这一步最容易忽略：如果 Page 里是空的，或者 Page 没有正确关联到任何 Group，用户登录后在 Space 下根本看不到这个 Page。实际上，在创建 Page 前，你要先在“Groups”页签下建好 Group，并把 App Tile 分配到 Group 里，然后在 Page 的“Groups”区域把对应的 Group 拉进来。

我这里用一个更直观的表述：Page 本身不直接存 App，Page 只是 Group 的 “陈列架”。Group 里放了哪些 Tile，Page 就显示哪些卡片。所以完整的配置顺序是：Catalog -> Group（分配 Tile） -> Page（关联 Group） -> Space（关联 Page）。

第五步，发布 Space 并测试。回到主 FLP 首页，用业务用户身份刷新，如果一次性缓存就刷新出来了，那说明角色权限和 IAM 都已经配好；如果看不到，优先排查角色分配和后端缓存刷新。

4.4 我踩过的命名与配置坑

配置流程本身不难，真正让人崩溃的是命名混乱带来的连锁故障。我遇到过一次典型事故：项目组把“财务月结”Page 的标题写成“月结 Page v2”，配置完成后又调整了 Catalog 名称，结果 PFCG 角色里挂的 Catalog 引用全部失效，用户在 FLP 上看到一堆空白磁贴。排错花了一整天，最后定位到是 Catalog ID 变更后，角色没有重新同步。

所以我现在严格要求项目组遵守三条铁律：第一，Catalog 和 Group 的 ID 一旦发布就不可随意更改；第二，任何命名调整必须通过 Change Request 记录，并同步更新角色分配；第三，每次交付前做一次 Catalog 引用完整性检查，专门找出那些在角色里引用了但实际 Catalog 已不存在的 App，避免产生死链。

还有一个细节：Launchpad Designer 里的 Space 和 Page 可以通过“Export and Import”功能在系统间复制，但某些情况下会连同角色分配一起导出，导到目标系统后如果权限对象没同步，会产生一堆“幽灵空间”。传输前务必核对目标系统的基础配置版本。

5. 项目落地全流程：从访谈业务 Owner 到正式切换的六步实操

设计准则只是纸面上的方法论，真正要落地到一套生产系统里，还是要走一个完整的项目流程。这里分享一套我实践过的六步落地法，每一步的关键产出物和验收标准都写清楚，照着做基本不会偏。

5.1 第一步：业务访谈与场景收集，产出一张“角色-空间”映射表

在动手配置之前，先把核心用户的角色清单梳理出来。打开 SUIM 按职位或者按组织架构导出现有 SAP 角色，然后与每个业务部门的 Owner 访谈，让他们把职责范围内 “每天要用的操作” 和 “每周偶尔用的操作” 分开列出来。

不要把访谈做得太泛。访谈的颗粒度应该到 “阿伟是销售订单专员，他每天的工作是先检查待审批的订单，然后录入新订单，偶尔处理交货和开票”— 这样才能把 Page 里的卡片排列设计出来。访谈结束后，项目组要产出一张“角色-空间-页面”映射表，格式可以参考：

这张表是后续配置的蓝本，也是 UAT 验收的依据。没有这张表，配置就会变成“想到哪配到哪”。

5.2 第二步：App 筛选与入库，确认可用 Fiori App 清单

别急着配置。先把系统里授权范围内可用的 Fiori App 全部拉出来，做一个清点。你可以通过 Fiori Apps Reference Library 查询每个 App 的技术名称、语义对象、所需后端服务，但更实际的做法是直接在当前系统里跑一遍事务码 /N/UI2/FLC 或者 SUIM 查看已导入的 Fiori App 清单。

清点之后，要标注每个 App 的状态：可上线、需要额外配置、不适用、待扩展。这个步骤特别重要，因为 Fiori 目录里有一大批 App 需要额外的后端定制才能展示数据，比如很多 KPI 卡片依赖 CDS View 和 OData 服务，如果没有做好权限和数据源配置，App 在页面上能打开但内容空白，用户体验反而更差。

5.3 第三步：Space 与 Page 总体设计，先评审再动手

结合第一步的角色映射表和第二步的 App 清单，设计出整套 Space 结构。注意这里要先把 Space 清单和 Page 清单评审一遍，最好拿给业务关键用户做一次“纸面评审”，让他们在 PPT 上看到左导航结构图，快速反馈“这个空间命名我能不能理解”。

评审的重点是命名和分组，不是逐个卡片。业务用户看不懂的 Page 名，即使卡片布局再合理也要调整。比如“GR/IR 重分类”这个 Page 名，财务月结会计看完会心领神会，但采购专员看到就会紧张。所以 Page 命名的原则是“面向目标用户的行业黑话，而不是面向实施团队的模块黑话”。

5.4 第四步：批量配置与权限同步

评审通过后，进入配置阶段。前文 4.3 已经把单个 Space 和 Page 的配置步骤写清楚了，这里主要说批量操作。如果系统里有几十个 Space 要建，一个个在 Launchpad Designer 里点会非常耗时。可以考虑用 SAP 提供的导入工具，或者开发一个小程序批量创建 Catalog/Group，但我的建议是第一次落地先用界面手工配置，理由是可以边配边检查，批量脚本一旦某个字段格式错误，排查成本更高。

配置完成后，PFCG 角色同步是最容易出错的环节。Catalog 在角色里维护时，建议把所有相关 Catalog 集中挂在少数几个复合角色下，方便统一分配。角色分配完成之后，需要在事务码 PFCG 里 “Mass Approval” 审批角色变更，并执行用户主数据同步，否则用户权限不会立即生效。

5.5 第五步：UAT 中的寻路测试，必须模拟用户真实操作

用户的 UAT 往往聚焦在业务功能能不能跑，忽略了对 FLP 界面本身的测试。所以我建议在 UAT 计划里单独加一项“寻路测试”：给测试用户一张任务清单，比如“在 FLP 中找到并打开采购订单审批”“在财务空间里找到月结工作台”，然后观察他们在 FLP 上的点击轨迹。

寻路测试的通过标准是：80% 的任务在两次点击内能定位到正确入口，95% 的任务在三次内完成。如果某项任务大部分用户都找不到入口，说明该 Space 或 Page 的布局有问题，需要返工。这种测试往往能发现很多设计死角，比如有的同事会把“采购申请”误认为该放在“财务核算”空间里，因为他们在审批流程中看到的单据带着会计科目视图。

5.6 第六步：切换与配套，不要踩旧 Group 的尾巴

正式切换到 Spaces 模式前，制定一个过渡计划。我的推荐是先让一个试点部门切换，跑两周后根据反馈微调，再全量切换。

切换过程中要做三件配套动作：第一，在 PFCG 角色里检查所有 Group 分配是否符合新版 Space 设计，将多余的旧 Group 从角色中移除；第二，在 FLP 配置里设置默认 Space 和默认 Page，用户登录后默认落在哪个页面很重要，一般设为主数据频繁访问的应用；第三，提前通过 Fiori Launchpad 的缓存刷新机制清理缓存数据，避免用户看到旧版结构。

提示：切换不要一步到位。保留旧 Group 结构一周左右作为回退方案，等业务基本稳定后再清理，可以显著降低上线风险。

6. 上线后的翻车案例与排错清单

再完美的设计，上线后也会遇到意想不到的问题。这里把我遇到过的几个高频故障场景写出来，每个场景都带上排查思路，当你对面是用户的未读消息和抱怨时要能迅速定位。

6.1 案例 A：角色权限都配了，用户登录后就是看不到新 Space

这是复现率最高的问题。可能的原因有五个，按检查先后顺序排列：

第一，检查用户所在角色是否包含了正确的 Catalog 和 Group。很多时候你改了角色，但用户没有重新登录或角色没有同步。在 SU01 里查看用户角色，再用 SUIM 或 RSAU 检查权限对象是否实际生效。

第二，检查 Space 是否已经发布。Launchpad Designer 里可以直接创建 Space 和 Page，但如果不从“Spaces”页签进入并点击“Publish”，系统不会立即推送结构到 FLP。许多项目组在配置完第四步就退出去了，忘了点发布。

第三，后台缓存。FLP 是基于 SAPUI5 的框架，浏览器端和 Gateway 端都有缓存。配置变化后可以使用 URL 参数强制刷新，比如在 FLP URL 后面加 ?sap-client=xxx&sap-language=ZH，或通过事务码 /N/UI2/FLP 里清空系统缓存。

第四，前端服务（Launchpad 服务）可能在 Gateway 系统上未激活。检查 ICF 节点 /sap/bc/ui2/flp 是否处于活动状态，以及 /default_host/sap/bc/ui2/flp 的别名配置。

第五，如果你用了多个 Client，不同 Client 的 Space 是隔离的，需要在目标 Client 单独发布。

排查顺序建议是先看角色同步，再看发布状态，最后清缓存。大多数情况下，问题出在忘了发布或角色同步延迟。

6.2 案例 B：Space 里的 Page 是空的，或者里的 App 全部显示为灰色

Page 能显示，但卡片全部灰色或空白，通常是 Catalog 里的 App 出现了权限或启动问题。打开其中一个 App 的启动日志，看是不是语义对象和动作没有正确配置。

在 Fiori 体系里，一个 App 的启动依赖 “Semantic Object” 和 “Action”。如果 Catalog 里添加 App 时，这两个字段没有匹配好，用户点击卡片后就会弹出“无法启动应用”的错误。排查方式：在 Launchpad Designer 里打开该 Tile，查看其语义对象和动作值，再和 FLP 上的链接地址比对。常见错误是多个 App 共用了同一个语义对象名称，导致 FLP 不知道该启动哪个。

6.3 案例 C：传输到生产系统后 Space 消失

这个问题最让人头疼，因为开发系统里明明都在。原因通常是把 Space 配置作为 Customizing 请求传输时，没有把对应的前端配置（BSP 应用、ICF 节点）一同传过去。

Space / Page 配置存储在 UI2/SPACE 和 UI2/PAGE 等表里，这些表属于 Customizing 请求，传输本身没问题。但如果在生产系统上没有激活相应的 UI 服务，FLP 就无法渲染新 Space。交付清单里必须包含检查和激活 ICF 服务这一项。更稳妥的方案是在 SAP Note 和交付文档里明确列出所需的 OData 服务和 ICF 节点，由 Basis 团队在传输后批量激活。

6.4 案例 D：用户自己配置的个性化布局在清理缓存后丢失

这属于 Fiori 前端个性化数据的遗留问题。如果用户用旧版 FLP 的编辑模式调整过 Group，再切换到新版 Spaces 时，旧个性化设置可能覆盖或隐蔽新 Space。解决方案是让用户进入 FLP 的“个人设置 -> 重置布局”，或者管理员通过事务码 /N/UI2/DEL_UX_CUST 清理前端个性化数据。注意，该操作只清除界面个性化，不会影响业务数据，但会连同用户自定义的 Tiles 一起清除，执行前要和用户确认。

6.5 长期维护：谁来负责 Space 配置的持续优化

Space 配置不是一劳永逸的。随着业务变化，用户会提出新增 App、调整 Page、合并 Space 的需求。我建议在项目交付时把 Space 和 Page 配置的维护责任明确给一个业务分析师或 Fiori 管理员，并要求每季度做一次配置 review，查看 Space 数量是否膨胀、Page 卡片是否冗余、用户反馈是否集中在某几个找不到入口的 App 上。

我在实际项目里会维护一份独立的“Space 健康检查清单”：每个 Space 分配了哪些 Page、Page 里有哪些卡片、卡片对应哪个 Catalog、角色是否还引用旧的 Catalog。这份清单类似配置台账，每次调整后更新，长期下来能避免大量返工。

最后分享一个小技巧：在新版 FLP 的“App Finder”里，用户可以自己看到所有已授权但未分配到任何 Space 的 App。这个功能在 UAT 阶段特别有用——你可以用测试账号在 App Finder 里搜一个 App，如果搜不到说明权限没配好，搜得到说明权限正常但未放上页面。这条规则能帮你快速区分是“权限问题”还是“布局问题”，少走很多弯路。