3. Fiori应用类型与选型策略
SAP Fiori 并不是一个单一应用，而是一整套按用户任务形态划分的应用家族。做实施时，真正决定项目成败的往往不是“能不能开发出来”，而是“这个需求到底该用哪一类 Fiori 应用来承载”。选错类型，轻则用户多点几次、多跳几屏，重则把分析需求做成事务录入、把对象洞察做成报表，最终导致上线后使用率低、返工成本高。因此，本节围绕 SAP Fiori apps reference library、事务型应用、分析型应用、对象页与自定义应用五类对象，讲清它们的适用场景与选型判断。
一、先查库，再选型：SAP Fiori apps reference library
SAP Fiori apps reference library 是官方提供的 Fiori 应用目录，也是选型的第一入口。它按产品版本、应用类型、业务角色、行业、前端技术等维度组织，每个应用条目通常包含应用名称、应用 ID、技术类型（SAPUI5、Web Dynpro、SAP GUI for HTML 等）、所需后端组件、所需 OData 服务、所需业务目录与业务角色、以及该应用所属的 Fiori 角色。实施顾问在接到需求后，第一步不是画原型，而是先在库中检索是否已有标准应用。
检索时建议按“业务对象 + 动作”组合关键词，例如“purchase order approve”“sales order create”“material stock analyze”。命中后重点核对四项：一是应用类型（Transactional / Analytical / Overview Page 等），二是所需后端版本与组件是否与当前 S/4HANA 版本匹配，三是依赖的 OData 服务是否已激活，四是所需业务目录与角色是否已分配给目标用户。若四项均满足，优先激活标准应用；若仅部分满足，再评估扩展或自定义。
二、事务型应用：面向“做一件事”
事务型应用（Transactional App）的核心是完成一次业务操作，例如创建采购订单、审批请假、过账发票、修改客户主数据。它的页面结构通常围绕单个业务对象展开，包含列表页、详情页与编辑页，操作路径短、字段聚焦、有明确的保存或提交动作。判断一个需求是否属于事务型，可以问三个问题：用户是否需要改变系统状态？是否存在明确的提交/审批/过账动作？操作是否围绕一个主对象？若答案都是“是”，应优先选事务型。
事务型应用的关键设计点是字段精简与校验前置。以“创建采购订单”为例，标准应用 ME21N 的 Fiori 版本会把供应商、采购组织、采购组、公司代码作为必填抬头字段，行项目只保留物料、数量、交货日期、价格等核心字段，其余通过默认值或后台配置带出。实施时应确认字段的必输、隐藏、只读属性是否与业务规则一致，避免用户因字段过多而放弃使用。
三、分析型应用：面向“看趋势、做判断”
分析型应用（Analytical App）的核心是聚合、对比与钻取，典型形态包括 KPI 磁贴、图表、多维分析表。它不改变业务数据，而是帮助用户发现异常、定位问题。常见场景有：采购支出按供应商与物料组分析、库存周转率趋势、应收账款账龄分布、生产订单达成率。分析型应用通常基于 CDS View 或 Analytical Query 构建，数据来自 HANA 计算视图或 BW 查询。
选型时要区分“实时分析”与“离线报表”。若用户需要基于当前事务数据即时查看，应选基于 CDS 的实时分析应用；若涉及跨年度、跨系统的大数据量汇总，则更适合 BW 或 Datasphere 支撑的分析应用。此外，分析型应用对权限粒度要求更高，需确认分析维度是否与用户授权范围一致，避免出现“看得到总数、看不到明细”的尴尬。
四、对象页：面向“360度了解一个对象”
对象页（Overview Page / Object Page）不是用来录入的，而是用来“看清一个对象”。它把与某个业务对象相关的关键信息、KPI、关联文档、操作入口集中在一屏，例如供应商对象页会展示基本信息、采购支出、未清订单、发票记录、风险评分等。对象页的价值在于减少跳转：用户不必在多个事务码之间来回切换，就能获得完整上下文。
对象页适合三类场景：一是需要跨模块查看同一对象的信息，如客户在销售、财务、服务中的状态；二是需要快速判断对象健康度，如供应商风险、物料呆滞；三是需要从洞察直接跳转到操作，如从库存预警直接进入补货事务。实施时应重点设计卡片布局与导航目标，确保每张卡片都能回答一个具体问题，而不是简单堆砌字段。
五、自定义应用：标准无法覆盖时的补充
自定义应用（Custom App）是在标准应用无法满足业务需求时的补充手段，通常基于 SAPUI5、Fiori Elements 或 CAP 构建。它适用于行业特殊流程、企业特有审批规则、与外部系统深度集成等场景。自定义应用的成本不仅是开发，还包括后续升级适配、权限维护、性能调优与用户体验一致性。
决定自定义前，应先评估三个替代方案：能否通过标准应用的扩展点（Extension Point）实现？能否通过自定义字段与自定义逻辑增强？能否通过 Fiori Elements 基于 CDS 快速生成？只有在扩展与增强都无法满足时，才进入完整自定义开发。自定义应用应遵循 Fiori 设计规范，保持与标准应用一致的交互习惯，避免形成“孤岛式”体验。
六、选型策略与常见误区
把五类应用放在一起看，选型可以归纳为一条主线：先判断用户是要“做事”“看数”还是“看对象”，再判断标准是否覆盖，最后才决定扩展或自定义。事务型解决“操作”，分析型解决“洞察”，对象页解决“上下文”，自定义解决“标准之外”。四者不是互斥关系，一个完整场景往往需要组合使用，例如对象页中嵌入分析卡片，分析卡片再跳转到事务型应用完成处理。
常见误区有三个。第一，把分析需求做成事务型报表，用户每次都要导出 Excel 再手工汇总，效率反而下降。第二，把事务操作塞进对象页，导致对象页变成“万能入口”，加载缓慢且职责不清。第三，一遇到标准不满足就启动自定义，忽略了扩展点与 Fiori Elements 的低成本路径。实施顾问应在需求评审阶段就明确应用类型，并记录选型依据，便于后续变更时追溯。
最后给出一个可执行的选型检查清单，供实施时逐项确认：需求是否已在 apps reference library 中检索；应用类型是否与用户任务形态一致；所需 OData 服务与业务目录是否已激活；权限角色是否覆盖目标用户；字段与操作是否符合业务规则；是否评估过扩展与 Fiori Elements 方案；自定义应用是否遵循 Fiori 设计规范；上线后是否有使用率与性能监控。逐项确认后，选型决策才算闭环。