SAP Fiori UX 困局：为何企业级设计总在重复旧战场

SAP Fiori 发布至今已有十余年，但一线仓库操作员与设计决策者之间的鸿沟，至今没有被填平。一位化名 Maria 的收货员，站在 1024×768 的 Panasonic Toughpad 前，用六周时间才把被 launchpad 拖垮的吞吐量拉回基线——而那六周里，她的团队比生产计划少处理了 30% 的收货单。

这不是个例。它揭示了一个结构性事实：企业级 UX 的核心矛盾不在于人才或技术，而在于激励错位。

激励错位：买家与用户从不见面

买 Fiori 的人——CIO、项目经理——看到的是 MacBook 上 1440p 的干净演示：所有 SAP 模块都在射程内，供应商合同就位，功能清单签字确认，UAT 全绿，项目可以结项。

用 Fiori 的人——Maria——体验到的是 300 单收货任务里多出来的三次点击、被错误默认值的筛选项、以及从冷启动到找到自己应用需要 45 秒的 launchpad。

两边的优先级没有任何重叠。买家永远看不到用户所见，而用户根本没有退出选项：当你的工作需要 SAP，你就只能用 SAP。厂商无论 Maria 的吞吐量是否在 go-live 当天崩掉，都已经拿到钱。

消费级软件靠用户体验生存，因为用户既是买家也可以离开；企业级软件的反馈回路完全不同。procurement 团队评估功能清单，CIO 签授权，用户没有退路。这就在结构上激励团队为演示优化、而不是为日常优化。

第二层问题在于，企业级实施中有太多拥有设计否决权的干系人：IT 有安全要求，业务流程负责人有工作流偏好，财务要 GL 账户常驻可见，运营要存储位置置顶，Basis 要求配置跨升级可维护。结果是一个满足清单上每一条要求、却谁都不好用的 launchpad。用户坐在所有人约束的交汇点上，却没有人为她代言。

SAP Fiori 是 SAP 自 2013 年推出的新一代用户体验层，它用基于角色的磁贴式 launchpad 取代了传统的 SAP GUI 事务码界面，底层由 OData 服务驱动，并原生支持移动与桌面多端。launchpad 是 Fiori 的入口门户，用户在其中通过磁贴（tile）进入各个应用。理解这篇文章的前提是区分两类角色：买家（buyer）——签合同、验收功能清单的 CIO 与项目经理；用户（user）——每天在设备上真正执行交易的仓库操作员、收货员。企业软件的结构性特征在于这两类人几乎从不在同一场景里碰面，因此采购决策与日常使用体验之间存在天然断层。

UAT（User Acceptance Testing，用户验收测试） 是项目上线前的最后一道验证关口，由业务方按预定义脚本确认功能是否符合需求。它的局限在于：脚本由实施方编写，测试者多为熟悉系统的超级用户，测试环境是会议室里的笔记本电脑，而非仓库现场的工业终端。因此 UAT 全绿往往只证明「功能存在」，不证明「高频使用下高效」。这正是文章中「通过 UAT 却败给 Maria」的制度性根源。

真正的根因：评估方式与使用方式错位

拥有最多设计影响力的人——功能顾问、解决方案架构师、项目经理——以「每任务 30 分钟」的节奏体验 Fiori，而不是「每天 300 笔交易」。他们把 Fiori 当作新用户发现功能来评估；Maria 把它当作产业工人使用，每一次多余点击都是可量化的成本。

这是两个完全不同的 UX 问题。第一个被解决了，第二个被忽略到 go-live。

更致命的是没有纠正性反馈机制。消费级应用有崩溃报告、漏斗分析、会话录制和 NPS，几天内就能回到产品团队。企业级 Fiori 实施只有 UAT 签字文档、go-live 就绪清单，以及启动 30 天后结束的 hypercare 期。当 Maria 的吞吐量崩塌出现在运营指标上时，项目团队已经撤走，系统集成商已经结项。关心 post-go-live UX 表现的激励，在设计决策者身上根本不存在。

Fiori 做对了什么：角色化与 OData

这不是一篇唱衰 Fiori 的文章。Fiori 方向是对的——只是方向对了但实施错了，可能比原地不动更糟。

角色化应用交付是 Fiori 最真实的能力。作者曾见过一个中型分销客户的成功案例：他们有三个仓库角色——收货、拣货、退货处理。项目团队没有给每个人一个 40 个磁贴的通用 launchpad，而是花两天采访了六名工人（每个角色两人），梳理真实日常任务序列，最终产出三个 launchpad：收货五个磁贴、拣货四个、退货处理六个。每个磁贴都用动词命名：「Receive Delivery」「Check Open POs」「Log Discrepancy」。没有模块名，没有事务码，没有因为「也许以后用得上」而存在的磁贴。

那次上线没有出现生产力崩塌。Maria 的上线出现了。差别不在技术，而在那两天用户访谈——大多数项目从不为此做预算。

第二个真实优势是 OData 对移动端的对齐。驱动 Fiori 应用的 REST-based OData 服务，在架构上比基于 BAPI/RFC 的集成更干净：可缓存、移动兼容、在扩展场景中可组合性更强。建在 OData 上是正确的地基，问题出在其上的实现层。

OData（Open Data Protocol） 是一种基于 REST 的开放数据协议，用 HTTP 动词（GET/POST/PUT/DELETE）暴露和操作数据，返回结构化 JSON 或 Atom 格式。相较 SAP 传统的 BAPI（Business API）和 RFC（Remote Function Call），OData 的差异在于：BAPI/RFC 是过程式调用，一次只能拿回固定结构，跨系统组合困难，且不天然适配移动端；OData 则支持查询参数（$filter、$select、$expand）、分页、缓存和幂等语义，天然契合移动端与浏览器。

这对 Fiori 至关重要：Fiori 应用的前端不是渲染 SAP GUI 屏幕，而是消费 OData 服务返回的数据集，因此响应速度、离线能力和组合扩展性都直接取决于 OData 设计质量。文章强调「建在 OData 上是正确的地基」，即架构选型没问题；问题出在实现层——字段该不该默认、tab 顺序如何排、磁贴如何命名，这些 OData 管不到。

三种真正可行的实施模式

任务化 launchpad 设计。 标准实施按 SAP 模块分组，因为配置 launchpad 的功能团队就是用模块思考的。正确做法是：每个角色访谈三名用户，让他们按顺序描述自己的一天，然后把 launchpad 映射到这个叙事上。应用名应该是动词而非名词：「Check Expected Deliveries」是工作任务，「VL06I - Inbound Delivery Monitor」是数据库引用。

UAT 之前的渐进披露。 找出用户在 90% 交易中真正填写的 top 10 字段，其余全部藏到「More」展开里。用三名真实用户测试——不是懂 SAP 的超级用户，而是第一天就会在生产车间使用的人——观察他们在哪里犹豫。如果有人搜索一个被隐藏的字段，就把它放出来；如果 20 次运行没人注意到某字段被藏了，它就永久该藏。业务方会坚持每个字段都必填，字段使用数据会给出不同答案——相信数据。

硬件优先测试。 在顾问 MacBook 上渲染漂亮的 launchpad，在真实用户手持的设备上可能完全不可用。在 UAT 之前、而不是之后，在真实硬件上测试：1024×768 的仓库终端、屏幕保护膜裂开的共享平板、输入延迟 40ms 的工业触摸屏、仓库现场与会议室之间的网络延迟差异。这些变量真实存在，只是在会议室的笔记本上看不到。

被 UX 设计师忽略的企业语境：吞吐量优先

消费级 UX 优化可发现性——新用户需要直觉地找到功能。企业级 UX 应该优化吞吐量。Maria 每天做同一个任务 300 次，两周之后可发现性已经无关紧要，速度和肌肉记忆才是全部的用户体验。

这意味着 Fiori 应用中的键盘导航比大多数实施所认为的更重要。收货应用的字段 tab order 应该遵循处理一次交付的物理流程：供应商、PO 号、物料、数量、存储位置。如果 tab order 跟随数据库 schema 而非物理流程，你就给每个用户每天 300 次交易都强加了摩擦。这种摩擦可量化，而且完全是自找的。

这也意味着，UAT 期间为首次使用者优化的 UI，和第六周生产环境中服务熟练用户的 UI 不是同一个设计问题。大多数 Fiori 实施解决了第一个，忽略了第二个。结果就是：通过 UAT，却败给 Maria。

作者建议用「两分钟测试」作为门槛：非 SAP 用户能否在真实硬件上、无人帮助、第一次尝试，两分钟内完成最常见的日常任务？如果做不到，就是没准备好。配套的三条检查是：冷启动任务完成、磁贴命名全部用动词、UAT 签字前至少三名真实终端用户在生产硬件上测试过。

渐进披露（Progressive Disclosure） 是交互设计中的一条经典原则：默认只展示最常用的少量信息或控件，其余按需展开到「More」「Advanced」等入口之后，以降低初次使用的认知负担。它在消费级软件中通常用于降低新手门槛，但文章把它用在了企业场景的另一面：通过字段使用数据判断哪些字段真正高频，把低频字段永久收进「More」。

关键在于验证方式。业务方出于风险厌恶倾向于要求所有字段可见且必填，但实际交易数据显示真正填写的往往只有 top 10 个字段。渐进披露因此必须配合可观测性——记录每个字段的展开次数与搜索行为。如果 20 次运行中没人注意到某字段被隐藏，说明它确实低频；如果有人主动搜索它，就应该放出来。这把「设计直觉之争」转化为「数据之争」，是减少干系人否决权拉扯的一种机制。

大多数实施真正缺的：一次用户观察

UAT 之前的一次用户观察会。不是问卷，不是反馈表，而是有人坐在真实用户旁边——在生产硬件上、在仓库现场——看他们尝试完成日常任务：那些犹豫、误点、找不到移动字段的瞬间、以及放弃并问同事的那一刻。这些在任何其他反馈机制里都是不可见的。一个下午的观察能识别出的真实 UX 问题，比三周功能测试还多。它几乎从不发生，因为没人会为一个不出现在项目里程碑图上、需要两天预算和一张机票的事情买单。

Maria 最终在 Fiori 应用上变快了，但花了六周。这六周里，团队收货单量比生产计划少 30%，导致货物移动积压、生产订单积压，最终变成每周运营复盘里 VP 的不适提问——仓库团队为六个月前由一群永远不会做收货的人做出的设计决策背锅。那场会议里没人提到 launchpad 磁贴布局，没人把它和那块从未被测试的 1024×768 屏幕联系起来。

所有这些——六周、30% 缺口、运营复盘——本可以在 go-live 前用一个下午的硬件测试避免。最后被做出的那些 UX 决策（launchpad 配置、字段可见性、磁贴分组、tab order），决定了仓库现场每个人前六周的生产体验。把它们当作装饰性而非运营风险，是作者最想回头更用力抗争的错误。

hypercare 期 是企业软件上线后的密集支持窗口，通常为 30 天左右，其间项目团队驻场处理紧急缺陷、配置调整和用户求助。它的结构性问题在于：这段时间关注的是「系统是否运行」「流程是否走通」，而不是「熟练用户的长期吞吐量是否达标」。一旦 hypercare 结束、系统集成商结项、项目团队撤离，任何需要改动设计的问题（磁贴布局、tab 顺序、字段默认值）就失去了负责人。

与之相对，消费级软件的可观测性体系包括崩溃报告、漏斗分析、会话录制和 NPS，这些机制在产品上线后持续运行，几天内就能把用户摩擦反馈回产品团队。企业 Fiori 实施通常没有部署任何等价物：SAP 系统本身能记录事务量，却无法自动关联到 UX 设计决策。这就是为什么 Maria 的 30% 吞吐量缺口只能作为运营指标浮现，而不会作为设计反馈回流——「纠正性反馈机制」的缺失不是疏忽，而是激励结构里没有人被要求为 post-go-live 的 UX 表现负责。