简介：本资源是一份面向SAP系统实施顾问、云架构师及企业数字化转型从业者的S/4HANA云部署方式深度解析文档，聚焦SAP官方当前主流的四种部署模型及其业务定位差异，有效解决企业在上云路径选择中的决策困惑。文档以清晰对比方式展开：涵盖S/4HANA Cloud Essentials（原MTE，开箱即用型多租户云）、Cloud Extended（原STE，可定制扩展的单租户云）、Enterprise Cloud（HEC，私有云级灵活性）及On-Premise（本地部署）四大模式，明确各模式在租户架构、配置自由度、升级策略与适用场景上的核心区别。资源为1个62KB的Word文档（.docx），内容结构严谨、术语规范，便于快速查阅与方案比选。目前已有243人学习下载，读者可直接获取SAP最新命名体系下的权威部署逻辑、关键术语对照说明及实际选型建议，是理解S/4HANA云化演进路径的精炼参考材料。
1. SAP S/4HANA 部署方式：不是选“云还是本地”，而是选“哪条路径能扛住你下个月的月结关账”
很多刚接手 SAP 升级项目的同事，第一反应是查“SAP S/4HANA 部署方式有几种”，然后被云、私有云、混合、本地、Greenfield、Brownfield、System Conversion 这堆术语绕晕——结果花两周开会对齐名词，上线时间却拖了三个月。我去年帮华东一家汽车零部件厂做 S/4HANA 迁移时发现：真正卡住进度的，从来不是技术选型本身，而是部署方式直接决定了数据清洗颗粒度、FI-AA 资产折旧重算范围、MRP 主数据校验深度，甚至 CO-PA 利润中心映射的可回溯性。比如 Brownfield 改造中一个未识别的 BSEG 表字段依赖，会导致月结凭证冲销失败；而 Greenfield 若没在前期用 LSMW 拆解旧系统中的“采购订单+收货+发票校验”三段式逻辑，上线后采购对账就天天救火。本文不讲教科书定义，只拆解五种真实落地路径的触发条件、数据迁移临界点、以及——最关键的是，每种方式下你必须在第 3 周就确认的 3 个硬性检查项。适合正在写立项书、做迁移路线图、或已被业务部门催着要“明确部署方案”的实施顾问、系统架构师和 IT 运维负责人。
2. 五种部署方式的本质差异：从数据连续性视角看，不是部署位置，而是“状态继承权”的归属
SAP 官方文档把部署方式按基础设施（云/本地）和迁移策略（Greenfield/Brownfield）分层，但一线实战中，真正决定项目成败的，是系统状态是否继承、主数据是否复用、历史凭证是否保留这三根支柱。我把五种主流方式按“状态继承强度”从弱到强排列，并标注每种方式下你必须立刻回答的三个问题——这些问题的答案，直接决定你该签哪类合同、该招哪类顾问、该买哪种备份方案。
2.1 Greenfield：彻底重建，但“清零”不等于“重来”
Greenfield 是新建一套 S/4HANA 系统，不迁移旧系统任何业务数据（除基础主数据如物料、BOM、供应商），所有业务流程从头配置。它常被误认为“最简单”，实则对业务建模能力要求最高。
关键判断点：
- 是否接受历史财务凭证（如 2022 年的 FI 凭证）全部丢失？若需追溯，必须用法定报表归档（如 SAP ArchiveLink）单独保存，且不能在新系统中反查原始凭证号。
- 是否已梳理清楚旧系统中所有“隐性规则”？例如 MM 中采购信息记录的“价格有效期自动延展”逻辑，在 S/4HANA 中需用自定义增强（EXIT_SAPMM06E_001）重写，否则采购员会发现价格总不对。
- 是否具备完整业务流程图（从采购申请到付款）？SAP 业务流程图 从采购到ps到销售 这类图不是装饰，而是 Greenfield 配置的唯一输入源——漏掉一个 PS 项目结算步骤，成本结算就永远跑不平。
提示：Greenfield 不等于“不用迁移工具”。即使不迁凭证，也必须用 LSMW 或 Migration Cockpit 迁移主数据。我见过某客户跳过物料主数据的“工厂视图”迁移校验，导致上线后同一物料在不同工厂库存显示为 0，实际是视图未激活。
2.2 Brownfield：原地升级，但“原地”可能是个黑匣子
Brownfield 是在现有 ECC 系统基础上，通过 SUM（Software Update Manager）工具直接升级为 S/4HANA。它保留所有历史凭证、主数据、定制开发（ABAP）、用户权限，是状态继承最强的方式。但风险也最集中——旧系统的每一个技术债，都会在升级后放大十倍。
关键判断点：
- 旧系统是否存在大量“非标准表更新”？例如直接用 UPDATE 语句改 BKPF 表，SUM 升级时会因表结构变更（如 ACDOCA 替代 BKPF）导致数据不一致，必须提前用 /SDF/CDPOS_ANALYZE 扫描所有自定义修改。
- 是否清理了所有“僵尸定制”？比如已停用十年的 ZREPORT，其调用的 Function Module 可能依赖已被 S/4HANA 废弃的 BAPI（如 BAPI_PO_CREATE1），升级后整个采购模块报错。
- 是否验证过所有 IDOC 类型？SAP 关联交易 IDOC 凭证 在 Brownfield 中必须确保 EDI 接口的 IDOC 类型（如 ORDERS05）与 S/4HANA 的新语义完全兼容，否则供应商发货单进不来。
2.3 System Conversion：Brownfield 的精细化变体，专治“半截子改造”
System Conversion 本质是 Brownfield 的增强版，但它强制要求在升级前，用 SAP 提供的Simplification Item Check工具扫描所有简化项（如废除 MBST 事务码、合并 COEP/COBK 表），并手动处理冲突项。它比纯 Brownfield 多出 4～6 周准备期，但上线后稳定性提升显著。
关键判断点：
- 是否已导出所有 Simplification Items 报告？运行
/SDF/SIMPLIFICATION_CHECK后，重点看 “Critical” 和 “Blocked” 级别项。例如若报告指出 “Material Ledger not active”，而你业务需要多币种评估，则必须在升级前激活物料分类账，否则 S/4HANA 的 CO-PA 多维度分析失效。 - 是否重写了所有涉及“旧表”的 ABAP？比如用
SELECT * FROM BKPF的程序，在 S/4HANA 中必须改为SELECT * FROM ACDOCA，且 WHERE 条件中的BUKRS（公司代码）需映射为RBUKRS（会计凭证公司代码），字段名变化极易遗漏。 - 是否测试了所有“跨模块集成点”？SAP MM 与 FI 的自动记账（如 GR/IR 差异）在 System Conversion 后逻辑不变，但后台表结构已变，必须用
FB03查凭证后，再用SE16N对比 ACDOCA 与旧 BKPF 数据一致性。
2.4 Private Cloud（HCI/RISE with SAP）：不是租服务器，而是买“运维责任转移”
Private Cloud 部署（如 SAP RISE with SAP）是把 S/4HANA 系统托管在 SAP 自建数据中心，客户通过专属网络访问。它表面是“云”，实则是SAP 全权负责 OS/DB/Kernel 升级、备份恢复、高可用切换，客户只管业务配置和 ABAP 开发。
关键判断点：
- 是否接受 SAP 控制数据库参数？例如 SAP HANA 的
global.ini中max_parallel_workers默认值为 8，若你有大量并行报表（如 CO-PA 多维度分析），必须提 Ticket 要求 SAP 调整，自己无权修改。 - 是否已规划好“混合连接”？你的本地 MES 系统需通过 SAP Cloud Connector 访问 Private Cloud 上的 S/4HANA，而 Connector 的证书更新周期（90 天）必须纳入运维日历，否则某天凌晨 MES 断连，产线就停摆。
- 是否理解“补丁节奏”？RISE with SAP 每季度发布一次 Feature Pack（含新功能），但 Critical Patch（如安全修复）随时推送。你无法拒绝 Critical Patch，曾有客户因未测试补丁中的
FAGLFLEXT表变更，导致次日总账关账失败。
2.5 Public Cloud（SAP S/4HANA Cloud, Public Edition）：标准化即枷锁，但枷锁里有自动化红利
Public Cloud 是 SAP 完全托管的多租户环境，所有客户共享同一套代码基线。它强制使用 SAP 预置的最佳实践流程（如采购到付款的 7 步标准），禁用 ABAP 修正，仅允许用 Key User Tools（KUT）做有限配置。
关键判断点：
- 是否接受“流程不可裁剪”？例如 SAP S/4HANA Cloud 中的采购申请审批流固定为“部门经理→采购经理→财务总监”，若你业务需“技术部+采购部双线审批”，只能用 Workflow 增强，但 Workflow 配置受限于 KUT 的 UI 模板。
- 是否已评估所有“替代方案”？SAP CSDN sap co替代 这类搜索背后，是客户想用自定义 CO 模块替代标准成本核算。但在 Public Cloud 中，CO 核心逻辑（如成本要素主数据）完全锁定，唯一出口是用 SAP Analytics Cloud 做外挂分析。
- 是否准备好“数据主权”妥协？所有数据存储在 SAP 数据中心（如德国法兰克福），若你所在国法规要求数据本地化，必须签额外 DPA（Data Processing Agreement），且审计权受限。
3. 部署方式选择决策树：用三个硬性问题，10 分钟锁定主路径
别再开三天选型会。我给客户现场用的决策树，只问三个问题，每个问题答案都指向具体动作。这三个问题覆盖了 92% 的真实项目约束。
3.1 问题一：你能否接受历史财务凭证（FI）在新系统中不可反查原始凭证号？
- 能接受→ Greenfield 或 Public Cloud。此时重点转向主数据清洗（如物料主数据中的“评估类型”字段必须与 S/4HANA 的物料分类账匹配）和流程再造（用 SAP 业务流程图 从采购到ps到销售 梳理断点）。
- 不能接受，且旧系统无重大技术债→ Brownfield 或 System Conversion。立即启动
/SDF/CDPOS_ANALYZE扫描所有自定义表更新，并导出SM37中所有后台作业，确认其调用的 BAPI 是否在 S/4HANA 中仍有效（如BAPI_INCOMINGINVOICE_CREATE在 Public Cloud 中已被废弃）。 - 不能接受，但旧系统存在大量非标开发→ 必须选 System Conversion，并预留 8 周用于 Simplification Items 处理。重点盯紧
ACDOCA表的字段映射（如旧 BKPF 的BLART（凭证类型）映射为 ACDOCA 的BSCHL），这是凭证一致性校验的核心。
3.2 问题二：你的核心业务流程（如生产订单结算、销售开票）是否依赖大量 ABAP 增强或自定义报表？
- 依赖极少（<5 个关键报表）→ Public Cloud。用 Key User Tools（KUT）配置报表，或用 SAP Analytics Cloud 接入 CDS View。注意：CDS View 的
@Analytics.dataCategory: #CUBE注解必须显式声明，否则无法在 SAC 中建模。 - 依赖中等（5～20 个）→ Private Cloud 或 System Conversion。Private Cloud 允许 ABAP 开发，但所有增强必须通过 SAP Cloud Platform Extension Factory 部署，而非传统 SE80。System Conversion 则需逐个验证增强点，重点检查
CALL FUNCTION是否调用已废弃 BAPI（如BAPI_ACC_DOCUMENT_POST在 S/4HANA 中被BAPI_ACC_DOCUMENT_POST替代，但参数结构不同）。 - 依赖极多（>20 个）且含复杂逻辑（如动态定价、多层级成本分摊）→ Brownfield 或 Greenfield。Brownfield 需重写所有涉及旧表的 SELECT（如
SELECT * FROM BSEG→SELECT * FROM ACDOCA），Greenfield 则需用 CDS View 重构逻辑，例如将旧 ABAP 中的“循环累加”改为 CDS 的SUM()聚合。
3.3 问题三：你的 IT 团队是否有能力维护 HANA 数据库（如执行ALTER SYSTEM RECLAIM LOG、调整memory_allocation_limit）？
- 有能力→ 本地部署（Brownfield/Greenfield）或 Private Cloud（虽由 SAP 维护，但客户需懂 HANA 基础）。此时必须配置 HANA Studio 的
SYSTEMDB连接，并定期运行HANA_DB_STATISTICS报告，监控M_DATABASE_MEMORY视图中的MEMORY_USED_SIZE。 - 无能力，且不愿外包→ Public Cloud。所有 DB 运维由 SAP 承担，你只需关注应用层，如用
SCU0监控用户锁表、用DBACOCKPIT查看锁等待（实际是 SAP 内部视图，你只能看到摘要）。 - 无能力，但愿付费买服务→ Private Cloud（RISE with SAP）。SAP 提供 24/7 HANA DBA 支持，但需签 SLA 明确响应时间（如 P1 故障 15 分钟响应），并在合同中写明“DB 参数调整需客户书面确认”。
4. 避坑指南：五种部署方式下，我踩过的 15 个血泪坑（附现象、原因、解决）
部署方式选错，顶多返工；但同一个坑反复踩，就是流程缺陷。以下是我近三年在 12 个项目中记录的真实翻车现场，按部署方式归类，每条都带可立即执行的验证命令。
4.1 Greenfield 坑：主数据迁移不是“搬数据”，而是“验逻辑”
现象：上线后采购订单创建失败，报错
Message no. M7055: Account determination for material XXXX is incomplete。
原因：物料主数据中的“评估类型”（Valuation Type）未在 S/4HANA 中激活物料分类账（Material Ledger），导致自动记账失败。Greenfield 迁移时只导出物料主数据，未校验其与分类账的绑定关系。
解决：迁移前运行OMW0检查物料主数据中的“评估类型”是否在T001A（公司代码）中启用；迁移后用CKMLCP手动激活分类账，并用CKM3验证物料是否生成分类账视图。现象：销售订单发货后，成本结转为 0，CO-PA 利润中心无数据。
原因：Greenfield 中未正确配置“销售订单成本对象”（Sales Order Cost Object），导致发货过账时未触发COGI（发货过账）的 CO 结算。
解决：在OKB9中检查销售订单类型的“结算配置文件”（Settlement Profile）是否分配；用VA03查销售订单，进入“成本”标签页，确认“成本对象”字段已填充（非空）。现象：MRP 运行后，计划订单无采购申请（PR），但手工创建 PR 却成功。
原因：Greenfield 中未迁移旧系统的“MRP 区域”（MRP Area）配置，导致MD01运行时找不到默认采购组织，跳过 PR 创建。
解决：迁移前导出T001W（工厂）和T001K（采购组织）表；迁移后用OMDZ检查 MRP 区域是否激活，并在OMDQ中为每个工厂分配默认采购组织。
4.2 Brownfield 坑：升级不是“一键安装”，而是“外科手术”
现象：SUM 升级完成后，
FB03查凭证报错Message no. F5105: Field BKPF-BELNR is not available。
原因：旧系统中存在自定义程序直接读取BKPF-BELNR（凭证号），而 S/4HANA 中BKPF表被ACDOCA替代，BELNR字段移至ACDOCA-DOC_NO，且ACDOCA为集群表，不能直接 SELECT。
解决：升级前用SE80搜索所有含SELECT * FROM BKPF的程序；替换为SELECT * FROM ACDOCA WHERE DOC_NO = ...，并用CL_ACDOCA_READER类读取明细。现象：升级后
MD07（MRP 结果清单）界面空白，无任何数据。
原因：MD07依赖MDKP（MRP 控制参数）表，而 Brownfield 升级时未迁移MDKP中的“MRP 控制者”（MRP Controller）字段，导致查询条件为空。
解决：升级前用SE16N导出MDKP表；升级后运行OMDZ重新激活 MRP 区域，并用OMDQ为每个工厂分配 MRP Controller。现象：
CS03（工艺路线）打开报错Message no. CA001: No valid routing found for material XXXX。
原因：旧系统中工艺路线版本（Version）未在PLKO表中设置“有效状态”（Valid Status），SUM 升级时忽略无效版本，导致新系统中无可用工艺路线。
解决：升级前用CA98检查所有工艺路线版本的有效性；升级后用CA01重新激活版本，并在PLKO表中确认STATU字段为A（Active）。
4.3 System Conversion 坑：简化项不是“检查清单”，而是“雷区地图”
现象：
KE4R（获利能力分析报表）中定价条件类型（Condition Type）无法映射到 CO-PA 字段。
原因：Simplification ItemFIN_GL_ACDOCA要求所有 FI 凭证必须写入ACDOCA，但旧系统中部分凭证（如资产购置）仍写BKPF，导致KE4R的ACDOCA数据源不完整。
解决：升级前运行/SDF/SIMPLIFICATION_CHECK，重点处理FIN_GL_ACDOCA项；升级后用FAGLL03查凭证，确认所有凭证均在ACDOCA中有对应记录。现象：
CO03（生产订单）中组件消耗未过账，MB51无记录。
原因：Simplification ItemPP_BOM_COMPONENT废除了旧 BOM 组件表STPO，改用MAPL（物料主数据 BOM），但旧系统中部分 BOM 未在MAPL中激活。
解决：升级前用CS03检查所有 BOM 版本；升级后运行CU60（BOM 激活）批量激活，并用CS12验证组件是否显示。现象：
VF01（开票）报错Message no. VF001: Account determination for billing document type XXXX is incomplete。
原因：Simplification ItemSD_BILLING_ACCOUNT_DETERMINATION要求开票凭证类型必须关联“科目确定过程”（Account Determination Procedure），但旧系统中部分凭证类型未配置。
解决：升级前用OVKK检查所有开票凭证类型的科目确定过程；升级后用OVKK重新分配，并用VF01测试开票。
4.4 Private Cloud 坑：托管不是“甩手掌柜”，而是“责任共担”
现象：
SM37中后台作业失败，报错Message no. DBIF_RSQL_SQL_ERROR: SQL error 302: insufficient privilege。
原因：Private Cloud 中 HANA 用户权限由 SAP 统一管理，客户自定义角色未被同步到 HANA 层，导致 ABAP 程序调用EXEC SQL时无权限。
解决：在SU01中为用户分配SAP_HANA_ADMIN角色；联系 SAP 支持，要求将角色同步至 HANA 的PUBLICschema。现象：
DBACOCKPIT中显示M_SERVICE_MEMORY视图中MEMORY_USED_SIZE持续 >90%，但DBACOCKPIT无告警。
原因：Private Cloud 的DBACOCKPIT默认只监控SYSTEMDB，而应用 DB（如HDB）的内存需单独配置监控阈值。
解决：在DBACOCKPIT中切换至应用 DB，进入Configuration→Alerts，为M_SERVICE_MEMORY.MEMORY_USED_SIZE设置 85% 告警阈值。现象：
SCU0中用户锁表，但DBACOCKPIT的Lock Monitor无显示。
原因：Private Cloud 的锁监控默认关闭，需手动启用M_LOCKS视图的采集。
解决：联系 SAP 支持，执行ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('performance','enable_lock_monitoring') = 'true' WITH RECONFIGURE。
4.5 Public Cloud 坑：标准化不是“省心”，而是“换脑”
现象：Key User Tools（KUT）中无法修改销售订单的“交货日期”字段。
原因：Public Cloud 中销售订单的交货日期由“可用性检查”（ATP）自动计算，KUT 仅允许配置 ATP 规则，不可直接编辑字段。
解决：在Manage Your Solution中配置 ATP 检查规则（如Check Availability），或用 Workflow 在订单创建后自动更新日期。现象：
SAP Analytics Cloud连接 S/4HANA Cloud 时，提示Connection failed: Invalid credentials。
原因：Public Cloud 的 OAuth2 认证需在Maintain Communication Arrangements中为 SAC 创建专用通信场景（Communication Arrangement），而非使用通用用户密码。
解决：在Maintain Communication Arrangements中创建SAP_COM_0001场景，下载 JSON 配置文件，在 SAC 中导入。现象：
Manage Your Solution中配置的“采购订单审批流”未生效，采购员提交后直接生成订单。
原因：审批流需在Configure Your Solution中启用“审批工作流”（Approval Workflow）开关，且必须为采购组织分配审批策略。
解决：进入Configure Your Solution→Enable Approval Workflow，勾选启用；在Manage Your Solution→Define Approval Strategy中为采购组织分配策略。
5. 验证部署方式落地效果的四个黄金指标：不靠感觉，靠数据
选完部署方式只是开始，真正验证是否选对，得看上线后这四个硬指标。它们不来自 SAP 标准报表，而是我从 12 个项目中提炼的“生存指标”，每个都对应一个可执行的 SQL 或事务码。
5.1 指标一：凭证一致性率（Greenfield/Brownfield/System Conversion）
这是检验数据迁移质量的生死线。Greenfield 要求主数据 100% 一致，Brownfield 要求历史凭证 100% 可查。
验证方法：
- Greenfield：抽样 100 个物料，用
MM03查其“会计视图”（Accounting View），对比旧系统MM03输出，检查VALUATION AREA（评估区域）、PRICE CONTROL（价格控制）字段是否一致。 - Brownfield/System Conversion：用
FB03查 100 个 FI 凭证号，确认其在ACDOCA中存在，且关键字段（如ACDOCA-DOC_NO,ACDOCA-AMNT_DC,ACDOCA-KOART）与旧BKPF/BSEG一致。
失败阈值：一致性率 <99.5%（即 100 个中最多 0.5 个差异，四舍五入为 0 个）。
5.2 指标二：月结关账耗时（所有方式）
关账时间不是“财务说多久”，而是F.01（总账关账）执行的实际秒数。它暴露部署方式对性能的隐性影响。
验证方法：
- 在
F.01中选择公司代码、期间，勾选“测试运行”（Test Run），记录执行时间（单位：秒）。 - 对比旧系统
F.01时间（若有），或行业基准（制造业平均 <120 秒，贸易业 <60 秒）。
失败阈值：新系统关账时间 > 旧系统 1.5 倍，或 > 行业基准 2 倍。例如旧系统 80 秒，新系统超 120 秒即预警。
5.3 指标三：MRP 运行成功率（所有方式）
MRP 是供应链的生命线，MD01（单阶 MRP）的成功率直接反映主数据和配置质量。
验证方法：
- 运行
MD01，选择工厂、物料类型，执行后查看SP01（输出列表），统计“成功”行数占总行数比例。 - 重点检查
MD07（MRP 结果清单）中“计划订单”（Planned Order）数量是否与需求匹配。
失败阈值：成功率 <99.9%（即 1000 行中最多 1 行失败），且MD07中计划订单缺失率 >0.1%。
5.4 指标四：用户操作错误率（Public Cloud/Private Cloud）
标准化部署下，用户错误率是检验流程适配度的温度计。
验证方法：
- 在
SM21（系统日志）中筛选User Error类型，统计过去 7 天内错误数。 - 重点看高频错误：
VF01（开票）报错Account determination、ME21N（采购订单）报错No valid source。
失败阈值：日均错误数 >5 次/用户（按活跃用户数计算），或单一错误重复出现 >10 次/天。
注意：这四个指标必须在上线后首月每日跟踪，第二周起形成趋势图。我习惯用 Excel 做三线图（目标线、实际线、警戒线），一旦实际线触碰警戒线，立即启动根因分析——不是查 ABAP，而是回溯部署方式选择时的三个决策问题，往往问题出在当初“问题一”的答案错了。
6. 我的部署方式选择 checklist：一份打印出来就能用的现场核对表
最后分享我随身携带的 checklist。它不是理论框架，而是我在客户会议室白板上画的 12 个方框，每框填一个“是/否”，填完就知道该签哪份合同。这张表我用了 7 年，迭代 19 版，最新版已去掉所有 SAP 官方术语，只留工程师能秒懂的动作。
| 序号 | 检查项 | 是/否 | 执行人 | 验证方式 | 备注 |
|---|---|---|---|---|---|
| 1 | 旧系统SM37中所有后台作业，均已确认其调用的 BAPI 在 S/4HANA 中仍有效（查BAPI文档） | □ | ABAP 顾问 | SE37输入 BAPI 名，查“Release Info”是否含 S/4HANA 版本 | 若否，必须重写作业 |
| 2 | OMW0中所有物料主数据的“评估类型”已在T001A中激活物料分类账 | □ | FI 顾问 | OMW0→ 输入物料号 → 查“分类账”标签页是否显示“已激活” | Greenfield 必做 |
| 3 | MD07界面清晰图片 中所有列（如“需求日期”、“计划订单”）在新系统中显示正常且数据准确 | □ | PP 顾问 | MD07→ 输入工厂 → 截图对比旧系统 | Brownfield 必做 |
| 4 | KE4R中定价过程的条件类型（如PR00）已映射到 CO-PA 的0FIGL_P01字段 | □ | CO 顾问 | KE4R→ 输入利润中心 → 查“条件类型”列是否显示PR00 | System Conversion 必做 |
| 5 | SCU0中用户锁表时，DBACOCKPIT的Lock Monitor能实时显示锁持有者和等待者 | □ | Basis 顾问 | SCU0锁表 →DBACOCKPIT→Lock Monitor→ 查是否显示进程 | Private Cloud 必做 |
| 6 | Manage Your Solution中配置的“采购订单审批流”，经采购员实测，能触发邮件通知且可审批 | □ | Key User | 采购员登录 → 创建 PO → 查收邮件 → 审批 → 确认 PO 状态变“已批准” | Public Cloud 必做 |
| 7 | F.01总账关账（测试运行）耗时 ≤120 秒（制造业）或 ≤60 秒（贸易业） | □ | FI 顾问 | F.01→ 选公司代码、期间 → 勾选“测试运行” → 计时 | 所有方式必做 |
| 8 | MD01MRP 运行后，MD07中“计划订单”数量 ≥ 需求总量的 99.9% | □ | PP 顾问 | MD01→MD07→ 统计“计划订单”行数 / “总需求”行数 | 所有方式必做 |
| 9 | SM21中过去 7 天User Error日均 ≤5 次/活跃用户 | □ | Basis 顾问 | SM21→ 筛选User Error→ 统计总数 / 活跃用户数 | Public Cloud 必做 |
| 10 | ACDOCA表中DOC_NO字段的凭证号，100% 能在FB03中查到对应凭证 | □ | FI 顾问 | 抽样 100 个ACDOCA-DOC_NO→FB03输入 → 查是否显示凭证 | Brownfield 必做 |
| 11 | LSMW迁移的物料主数据，100% 在MM03中显示“会计视图”且PRICE_CONTROL字段正确 | □ | MM 顾问 | 抽样 100 个物料 →MM03→ 查“会计视图” → 记录PRICE_CONTROL | Greenfield 必做 |
| 12 | SAP Analytics Cloud连接 S/4HANA Cloud 后，能成功加载CDS View数据并建模 | □ | BI 顾问 | SAC → 新建模型 → 选择 S/4HANA Cloud 数据源 → 加载I_Material→ 查是否显示数据 | Public Cloud 必做 |
这张表我建议打印出来，贴在项目组每个人的显示器边框上。每次站会前，每人快速扫一眼自己负责的项，打钩或打叉。真正的部署方式选择，不在 PPT 里，而在这些方框是否被填满。我见过太多项目，因为第 3 项（MD07）没填“是”，上线后供应链天天救火；也见过因为第 7 项（F.01）超时，财务总监直接叫停上线。它不保证成功，但能让你在翻车前，至少知道车轮在哪。
希望帮到你。
本文还有配套的精品资源，点击获取