驳斥「欧洲某 ERP 公司死推 Fiori 是为了绑着用户上公有云」的言论

近日笔者在群里看到一张截图，里面的文字抛出了一个观点：

欧洲某 ERP 公司死推 Fiori，是为了绑着用户上公有云。

本文笔者纯粹从技术角度出发，说一说自己对这个言论的看法。

说实话当我第一眼看完，一时没搞清楚文字的作者到底想要表述什么。

截图中的公有云，我猜测他指的是 SAP S/4HANA Public Cloud？

Fiori 是 SAP 旗下的一门 Design Language，正如 Apple 的 Liquid Glass 和 Google 的 Material Design 一样。

在我看来，SAP S/4HANA Public Cloud 作为 SAP 旗舰级产品，采用 Fiori 不是一件天经地义的事情吗？何况 SAP 旗下众多产品线，使用 Fiori 设计语言的产品多了去了。所以为什么通过「SAP 推 Fiori」，就能得出「是为了捆绑用户上公有云」的结论？我不理解。

笔者之前写过一系列关于 SAP Fiori 的文章：

SAP Fiori 和 SAP UI5 的区别和联系

SAP Fiori 设计准则演进的历史时间节点

从 SAPGUI 到 SAP Fiori 的得与失

漫谈 SAP Fiori 和 Google Material 这两门设计语言

为什么都 2025 年了，还有人在抱怨 SAP 系统界面难看？

这些文章都反复强调了一个观点：Fiori 不是单一组件，而是一套横跨平台的设计系统与指导原则。

SAP Fiori 官网将 Fiori 定义为跨设备体验的一致性标准，并提供基于 Web / iOS / Android 等平台的设计与开发资源。

https://www.sap.com/design-system

Fiori 作为一门设计语言，在产品上最直观的落点常常体现为「主题与视觉语言」，例如 Quartz 与 Horizon 这类主题家族。

在 SAP Fiori Design Guideline 里，Morning Horizon / Evening Horizon 被描述为最新主题，同时仍保留 Quartz 等主题。

我曾经不止一次被问到这样一个问题：

SAP 哪些产品支持 Fiori？

从一个 SAP 开发专家的视角出发，我认为这个问题本质上是在问：

这些产品是否遵循 Fiori 的交互模式与信息架构？

这些产品是否使用 SAP 的统一主题体系（例如 Quartz / Horizon）？

这些产品是否提供 Fiori 相关的开发框架与组件库（例如 SAPUI5，移动端 SDK 等）？

这些产品是否能通过统一入口进行访问（例如 SAP Fiori Launchpad 或其云化演进）？

根据本人这些年来从事过多款 SAP 产品开发的经验，我认为 SAP 产品对 Fiori 的支持程度，可以分为以下三个维度。当然这个分类纯属个人见解，不代表 SAP 官方观点。

第一档：原生支持，即 Fiori 是产品主体验的一部分(强支持)

这一档的典型特征是：用户日常工作入口就是 SAP Fiori Launchpad（或其云端形态），业务应用以 Fiori 应用的方式呈现，权限内容模型围绕 catalog / space / role 组织。最典型的代表就是 SAP S/4HANA.

SAP Fiori Launchpad 本身并不是一个单独售卖的产品，它通常是随着不同 SAP 解决方案一起获得与部署。

第二档：对齐支持，产品整体 UX 与视觉语言向 Fiori 对齐(中支持)

这一档的典型特征是：产品可能不是典型的 Fiori Launchpad + UI5 应用架构，但它采用 Fiori 的主题与视觉语言（例如 Horizon），让用户跨产品切换时获得一致的品牌与控件观感，降低学习成本。

比如 SAP Concur，虽然其访问入口不是典型的 Fiori Launchpad，页面跳转访问各个业务功能也并非通过传统的 Launchpad Tile 方式进行，不过其界面明确引入 SAP Fiori Horizon 视觉主题（含 light / dark / high contrast），仅仅进行了少量导航方式的调整。

再比如 SAP SuccessFactors 的公开 KBA 3189269 明确写到，其默认主题从 Fiori 2 的 Belize 更新到 Fiori 3 的 Quartz Light，以保持与 SAP Fiori 标准一致。

https://userapps.support.sap.com/sap/support/knowledge/en/3189269

第三档：技术可实现，即用某些 UI 技术能实现 Fiori 风格(弱支持)

这一档对 Fiori 的支持其实是一种从「平台能力」层面对于 Fiori 的支持。应用本身并不是通过 SAP UI5 开发，但用户可以在产品当前支持的 UI 技术上套用 Fiori 的主题与控件，使其在视觉与交互上尽量接近 Fiori,简单来说就是「套壳」。

典型场景包括 SAP GUI、Web Dynpro、CRM WebClient UI 等经典技术逐步补上 Quartz 或 Fiori 3 主题能力：

运行在 SAP GUI for Windows 里的事务码，可以通过 Belize 与 Quartz 主题适配到 Fiori 的设计与可用性范式上。

Web Dynpro ABAP 的 Quartz Light（技术名 sap_fiori_3）被描述为迈向 SAP Fiori 3 的第一步。

CRM WebClient UI 也有 Quartz 主题可用，用于在经典界面里向 Fiori 3 视觉效果靠拢。

对于很多企业来说这种套壳功能很实用：虽然不可能一夜之间把所有事务码与经典界面都重构成基于 SAP UI5 的 Fiori 原生应用，但可以通过低成本的主题统一，快速减少视觉上的割裂感。

按 SAP 产品家族梳理：哪些产品属于 Fiori 强支持？哪些属于中支持或弱支持？

A 类：以 SAP Fiori 为主体验入口的产品与平台（强支持）

1. SAP S/4HANA（含 On-Premise 与 Cloud 版本）及其 Fiori 入口形态

在 SAP S/4HANA 体系里，Fiori 的定位非常核心：大量标准业务流程以 Fiori 原生应用的方式交付，用户通过 Fiori Launchpad 作为统一入口，后者的部署形态包括 embedded / hub 等选项。

2. SAP BTP 上作为统一入口的 Fiori Launchpad 云化形态（强支持）

很多企业会走中央统一入口路线(central entry point)：把多个后端系统与云应用统一到单一入口。

此时 SAP BTP 提供的入口服务就至关重要，历史上曾经称为 SAP Launchpad service，而后更名为 SAP Build Work Zone standard edition.

虽然名称发生了变化，但仍继续提供 revamped UX、页面与工作区、以及遵循 SAP Fiori 设计系统的卡片等能力。

SAP Build Work Zone 提供的 Content Federation 能力，可以把 SAP S/4HANA 与 SAP Business Suite 作为远程内容提供者，把业务角色、catalog、应用等内容联邦合成到该入口，实现统一访问的效果，如下图所示：

换句话说，SAP BTP 上的 Fiori Launchpad，提供的访问入口不再是针对某个单体业务产品，而是把 Fiori 的信息架构与导航体验，抽象成「企业统一工作台」，更符合真实世界下的多系统客户使用习惯。

3. SAP BTP ABAP environment 等云开发运行时里的 Fiori 应用（强支持）

SAP BTP ABAP 编程环境里也提供了面向管理员与开发者的 Fiori 原生应用与 Launchpad 体验（例如环境管理相关应用）。

笔者的SAP BTP 开发教程也有专门章节对此做了介绍。

B 类：产品整体视觉语言与部分交互方式对齐 Fiori（中支持）

SAP Service Cloud、SAP Sales Cloud、SAP BTP Services、SAP SuccessFactors、SAP Concur、SAP Emarsys Customer Engagement，SAP Analytics Cloud 等都属于 B 类范畴。

通过在这些产品中应用 Fiori Horizon 主题与模板，获得高度一致的 SAP 产品范儿(官方术语叫做 Look and Feel，简而言之就是「一眼看上去就知道是 SAP 的产品」。

以下面动画所示的 SAP Analytics Cloud 为例，它更偏数据分析与可视化，但通过引入 Horizon 主题，让用户从事务处理的 SAP S/4HANA 页面跳转到 Analytics Cloud 的分析看板时，毫无违和感，丝毫没有「像换了一套软件」的尴尬。

C 类：经典技术与外围入口的 Fiori 化（弱支持但很有价值）

这类支持经常被忽略，但在真实的企业使用场景里，它们反而决定了 Fiori 推广的成败，因为企业不可能将所有的业务功能界面都用纯粹的 UI5 来实现。

1. SAP GUI 的 Belize / Quartz 主题

SAP GUI for Windows 的官方文档明确指出，经典应用可通过 Belize 与 Quartz 主题来适配 Fiori 的设计与可用性范式。这意味着用户可能一部分工作时间停留在原生的 Fiori 应用，剩下的则在 Fiori-Like 的经典 SAPGUI 事务码里继续工作。

笔者之前的文章做过介绍：

如何分辨 SAP Fiori Launchpad 里的"真假" Fiori 应用

2. Web Dynpro ABAP 的 Quartz Light（sap_fiori_3）

在 ABAP Platform 1909 的 What's New 页面，SAP 直接把 Quartz Light 主题描述为迈向 Fiori 3 的一步，并强调 Fiori 3 是面向所有 SAP 产品的目标设计系统。

对还保有大量 ABAP Web Dynpro 应用的企业，这是一条非常现实的路径：先做低成本的 Fiori 视觉统一，同时逐步把高价值流程重构为 Fiori 应用。

3. SAP CRM WebClient UI 的 Quartz 主题

Fiori Quartz 主题已可用于 WebClient UI，以更贴近 Fiori 3 的视觉效果。

Fiori 对移动端应用的支持如何？

很多朋友误认为 Fiori 只支持浏览器应用，这其实低估了 SAP 在移动端对 Fiori 的投入。

1. SAP Fiori for iOS 与 SAP BTP SDK for iOS

SAP Fiori for iOS 融合了 iOS 设计与 SAP 企业能力，有自己的 iOS 设计语言、

UI Kit，以及配套的 SAP BTP SDK for iOS 来构建企业级移动应用。

SAP Fiori UI Kit 是对 SAP Fiori 设计语言在 iOS 平台上的原生实现。

2. SAP Fiori for Android 与 SAP BTP SDK for Android

同 SAP Fiori for iOS 类似，SAP Fiori for Android 帮助开发者用 Android Studio 和主流编程语言，更快开发原生 Android 应用；同时结合 SAP Fiori Guidelines for Android，把 SAP Fiori 设计带到 Android 平台，将移动应用同 SAP BTP 上的服务进行对接。

这意味着它不仅包含 UI 控件，更包含企业级移动开发领域必需的底座能力，例如通用的登录与引导、与 SAP Mobile Services 的集成、在线与离线的数据访问框架等等。

技术栈层面的支持：为什么 SAP UI5 经常被当成 Fiori 支持的证据

刚接触 SAP UI5 和 SAP Fiori 的从业者很容易将二者混淆起来，笔者的文章已经做了辨析。

SAP Fiori 和 SAP UI5 的区别和联系

当我们需要从开发角度回答「某产品能否支持 Fiori」时，最硬的证据之一是它的前端开发技术是否以 SAP UI5 作为主要 UI 技术。

SAP UI5 是一套构建应用的库集合和开发框架，目标是提供一致体验，并符合 SAP Fiori 设计指南。

所以落到项目治理层面，我们可以把「是否使用 SAP UI5」当成该产品对 Fiori Design Language 支持度的重要指标之一。

SAP UI5 开发分为灵活度较高的 Freestyle 和「流水线式」快速生产应用的 Fiori Elements 两种开发方式。

笔者分别写过两套开发教程进行过介绍：

一套适合 SAP UI5 从业人员从入门到进阶的学习教程

SAP Fiori Elements 开发教程：从入门到精通

当然，如果选择 Angular，React 和 Vue 这些非 SAP UI5 前端框架，借助 Fiori Foundamental，也能开发出具有 Fiori 外观的前端应用。笔者之前的文章做了介绍：

SAP Fiori + Vue = ？

用 React 开发 SAP Fiori 应用

好了，到这里笔者已经写了 4000 多字，想表达的就是：SAP S/4HANA 公有云的前端页面确实是基于 Fiori 设计，但 SAP S/4HANA 公有云远远不能代表 Fiori. 那么文章开头截图里的观点「欧洲某 ERP 公司死推 Fiori 是为了绑着用户上公有云」，笔者实在难以认同。