企业官网建设流程全解析

简介：面向设备管理与工厂运维人员的SAP PM（Plant Maintenance）模块系统讲解课件，适合SAP初学者、实施顾问及企业设备管理人员快速建立维护业务流程的整体认知。资源为单份PPT演示文稿，约4.38MB，共1个pptx文件，内容按模块化章节组织，便于用户按需定位和进行培训讲解。课件围绕设备资产生命周期管理展开，覆盖计划工厂与维护工厂组织架构、功能位置层级设定、设备与BOM结构清单、序列化管理、工单与通知单流程、预防性维护及外部服务触发等核心概念，并配业务流程图与结构图辅助讲解，能系统呈现从设备基础数据构建到维护执行、成本归集与信息记录的完整路径。目前已有136人学习浏览，适合企业内训、课堂演示或个人自学，是理解SAP PM模块功能范围与管理逻辑的入门参考材料。

1. SAP PM 不是「设备台账」：一张 PPT 背后的维护业务主线

拿到这份《SAP_PM模块介绍.pptx》，如果你以为它是给设备贴编码、做资产台账的课件，方向就偏了大半。SAP PM（Plant Maintenance，工厂维护）真正承担的角色，是把「设备坏了谁来报、谁来修、用什么备件、花多少钱、下次怎么预防」这条业务线钉在一个系统里。它上承资产台账，下接物料采购、生产计划与财务结算，是 ERP 里最容易做成「黑匣子」的模块。这份 PPT 的价值不在页数多，而在把主数据、业务流程、预防性维护和系统集成串成一条能对表落地的主线。适合刚接手 PM 实施、正在做维护数字化选型，或要给设备部门做培训的从业者——拿到的是概念，更是一张能反过来追问业务边界的核对表。

2. 主数据与组织架构：功能位置、设备和 BOM 怎么串起来

做 SAP PM 项目，第一场硬仗不在流程梳理，而在主数据建模。功能位置、设备、设备 BOM、任务清单，这四类对象决定后面所有通知单和订单是否找得到历史、算得清成本。刚上手的人最容易干的事，是叫设备部门导一张 Excel 台账出来直接批量建设备，结果做出来的功能位置树没有层级、设备编码没有规矩、BOM 缺料不全。等到维护订单创建完、财务结算对不上账，才发现主数据的债全留在了后头。这一章不绕理论，直接说我在项目里怎么定对象、怎么建编码、怎么让业务方和 IT 都不后悔。

2.1 功能位置 vs 设备：先挂树还是先建档

功能位置（Functional Location）描述设备在物理空间或工艺系统里的位置，是结构化的、相对固定的；设备（Equipment）是独立的、可移动的技术对象。举个例子：循环水泵站里，PLANT-PUMP-STATION是功能位置，挂在它下面的那台泵40000001是设备。泵坏了拆走维修，功能位置不动，设备跟着检修单走。

我在项目里常用的判断规则是：如果一个位置上的设备换了型号、历史记录不能断，那就必须把维护记录挂在设备上，功能位置只承担「从哪个位置能找到这台设备」的索引功能；如果一批同型号设备分散在多个位置且不单独核算，才考虑把对象挂在功能位置。SAP 允许设备挂在功能位置下，也允许功能位置挂设备，数据结构上形成一对多关系。

实操路径：事务代码 IE01 创建设备，IL01 创建功能位置。在 IE01 的「位置」页签里给设备分配功能位置；如果设备带厂家序列号，建议在「序列号」页签同步维护，为后续扫码巡检、资产盘点留扩展空间。这里有个经验：功能位置的层级不超过五层，超过之后业务在前台维护时翻找位置树非常痛苦。另外要提醒一句，尽量不要用「整条产线做成一台设备」的建模方式，设备一换，整条产线维护历史就断了，后期做设备可靠性分析时数据根本取不出来。

边界条件：如果企业将来要做状态监测或备件消耗分析，我建议设备层单独建对象，并把测点、备件 BOM 都挂到设备上，这样预测性维护的读数才有载体。功能位置树不是必须全部建成「厂区-车间-工段-设备」四级，按实际管理粒度来。我看到过一家化工厂把阀门也建成功能位置，结果树里上万节点，维修工根本找不到东西在哪一层。功能位置的粒度，应该由「谁在哪个层级做维护计划」决定，而不是由设备专业决定。

2.2 设备 BOM 与任务清单：给维护对象造「配方」

设备 BOM 保存一台设备由哪些备件和原材料组成，是维修领料的依据；任务清单（Task List）保存这台设备的标准维修步骤，是维修施工的依据。两者配合，创建维护订单时 SAP 会按 BOM 带出计划料、按任务清单带出工序和工作中心，订单从「空白模板」变成「有配方可抄」。

创建设备 BOM 的事务代码是 CS01，对象类型选「设备」；维护任务清单在 SAP 菜单里走「工厂维护 → 准备 → 任务清单」，事务代码在不同版本有 IA05/IA06 等差异，以你项目的菜单路径为准。任务清单里的工序需要分配工作中心（Work Center），工作中心决定维修工种、工时费率、可用能力，这些在后续确认人工成本时会被取到订单上。我见过不少项目把工序里的工时填成 0，理由是「内部维修不用钱」，结果每次月末结算人工成本都归集不上去，财务就只能来堵你。

建议维护两条工序：第一条是「检查/拆解」，第二条是「修复/装配」，工时分开记。后续做维修工时分析时，能看到「查故障花了多久、动手修花了多久」，对优化检修定额很有用。工序里有个「控制键」字段，如果配了 PM02，表示工序需要确认工时才允许做后续发料或结算；如果业务不需要强控，可以用标准控制键 PM01。

验证设备 BOM 是否建成功，可以用 SE16N 查表，或者直接在 CS03 里显示对象 BOM。如果需要批量检查设备 BOM 是否存在，我一般用一段简单 ABAP 查表：

DATA: lv_objkey TYPE equnr VALUE '40000001'. DATA: lt_stb TYPE TABLE OF stpo. CALL FUNCTION 'CS_BOM_EXPL_OBJ' EXPORTING objtype = 'E' objkey = lv_objkey TABLES stb = lt_stb EXCEPTIONS no_bom = 1 not_found = 2. IF sy-subrc = 0. WRITE: / 'BOM items found:', lines( lt_stb ). ELSE. WRITE: / 'No BOM found for equipment', lv_objkey. ENDIF.

参数说明：objtype = 'E'限定 BOM 对象类型为设备，objkey是设备编号，表格stb返回 BOM 明细；no_bom表示该设备没有 BOM，not_found表示设备对象本身不存在。这段代码不是标准报表，只是我排障时快速确认 BOM 数量对不对的脚本，生产环境慎用。

任务清单也有类似问题。有些企业直接在维护订单里手写维修步骤，不做任务清单。短期看省事，长期看，同样的设备在不同车间有两套维修步骤，工时定额完全对不上。企业越走越深，最后还是要回头补任务清单。我的建议是一开始就把高价值设备、重复性维修设备先建任务清单，其余设备后续逐步补，不要等上线后再全员铺开。

2.3 分类特性与编号范围：编码设计的后悔药

预防性维护要做到「按一台设备的型号特征排检修策略」，光靠文本描述不够，需要分类系统（Classification）支撑。事务代码 CL01 创建分类，CL02 维护特性值，再把分类分配给设备类型或设备本身。比如给机泵建分类ZZ_PUMP，特性RATED_POWER（额定功率）、BEARING_TYPE（轴承型号）、LUBE_OIL（润滑油牌号）。后面建测点、选备件、做状态评估时这些值都能被拉出来筛选。

分类特性在批量导入时要注意：特性允许值（Value）和描述（Description）必须一起维护，否则导入后前台下拉看不到描述，业务不知道这个代码是什么意思。更有意思的是特性可以定义成「继承」，例如把设备分类特性挂到功能位置分类上，那么挂在功能位置下的设备会自动继承位置特性。但我一般不推荐过度使用继承，因为数据读取性能会下降，业务维护时也很难搞清楚值是从哪一层来的。

编号范围是另一个容易被低估的配置。设备号建议用内部编号（事务代码 SPRO → 工厂维护和维修 → 技术对象 → 定义编号范围），留足 6 位以上空间；功能位置建议用带语义的结构码（如A1-B2-C3），但层级不要超过 5 段。很多老项目设备编号沿用了外部人工流水号，导入时重复、跳号、补 0 不统一，后续在采购订单、服务确认单里引用设备号频繁出错。

配置要点：编号范围在 SPRO 里分别给设备、功能位置、通知单、维护订单定义，每类对象可以共用一个号段。注意不要把所有对象混进同一个编号范围里，否则前台创建通知单时跳出的是设备号规则，用户会以为自己按错事务代码。维护计划、测点、任务清单也有独立编号范围，建议按实际业务量各建号段，避免未来顶号。

给一个实际项目中的例子：一家钢厂把功能位置编号定义为「厂区(2)-车间(2)-产线(2)-段位(2)-序号(3)」，共 11 位，前台录入时业务方叫苦不迭。后来改成「厂区号+产线号+序号」6 位结构码，录入效率明显提升。编码不是越全越好，是「能被业务记住和说出来」才好。SAP 支持在结构码里做掩码显示，但底层的分段仍然存在。设定编号范围时，把外部号码段和内部号码段分开，预留未来并购带来的大批量导入空间。

3. 维护业务闭环：从通知单、维护订单到结算的关键配置

主数据建好之后，真正的业务跑起来靠的是「通知单 → 维护订单 → 发料/确认 → 结算」这条闭环。很多 PM 项目在演示环境里跑得很顺，一到上线就卡住，问题基本都在配置细节上：通知单类型没人配合作伙伴、订单类型没有自动结算规则、成本中心字段在设备主数据上空着。这一章把每个环节的配置点和翻车点都摆出来。

3.1 通知单：报修入口、编码与优先级

维护通知单（Notification）是维护业务的门把手。现场操作工发现故障，开一张 M1 类通知单；设备工程师巡检发现隐患，开 M2 类通知单；预防性维护触发检修需求，可以开 M3 类通知单。不同通知单类型决定后续流程动作：是否需要保存在技术对象上、是否可转订单、是否要记损坏代码。事务代码 IW21/IW22/IW23；创建通知单时输入功能位置或设备，描述里写故障现象，损坏代码（Damage Code）组选择故障类型，SAP 会把损坏代码作为后续统计维度。

一个常见问题：通知单里没有采购组织、没有费用责任范围都可以理解；但如果没有维护计划员组（Planner Group），通知单保存后很可能找不到负责人。维护计划员组在 SPRO 中定义（工厂维护和维修 → 主数据 → 计划员组），创建功能位置时可以把计划员组维护到对象上，这样一张通知单保存后会自动带出负责人，通知单不会躺在系统里没人接。

优先级：SAP 默认有 1～4 级，1 为最高。我习惯在通知单屏幕上把「基本开始日期」和「优先级」设为必填，防止用户随手保存后不安排维修时间，维修调度排程时找不到可排任务。这里的底层参数是屏幕格式（Screen Form）和字段状态组，在配置里把必输字段控制好，比上线后靠人去催可靠得多。

通知单转换成订单的方式也值得说。推荐用 IW31 直接从通知单创建订单，系统会复制问题描述、技术对象和损坏代码。如果企业想保留「先评估再派工」的逻辑，也可以在通知单上停留一段时间，等计划员评估后再转。评估阶段最怕的是通知单状态被误置为「完成」，后来收到同一台设备的重复故障时，旧通知单已经关闭，分析人员看到的损坏代码统计就会失真。遇到这种情况，用 IW23 菜单里的「编辑 → 重置已完成通知单」把它拉回处理中状态。

3.2 维护订单：从计划到执行的状态流转

通知单确认后转为维护订单（Maintenance Order），也可以由维护计划直接生成订单。维护订单类型常见 PM01（维修订单）、PM02（计划检修）、PM04（一般维护），版本不同叫法有差，但核心状态流转一致：CRTD（创建）→ REL（下达）→ 已开始执行（CNF）→ TECO（技术完成）→ CLSD（关闭）。

订单状态不是摆设。物料发料前订单必须已下达（REL），否则 MIGO 发料时提示订单未下达；工序确认时需要订单处于已下达或技术完成状态；结算需要订单进入 TECO 后执行。很多项目上线初期，用户创建完订单不点「下达」，仓库看到的就是一张「纸面订单」，自然发不了货。这时我通常给用户开一个字段状态：订单类型为 PM01、PM02 时，创建保存后自动带上「下达」状态（通过订单类型配置里的状态参数文件加自动操作实现），但仅在审批流程允许的前提下建议这样做。

关键事务代码：IW31 创建订单、IW32 修改订单、IW33 显示订单、IW41 确认工作中心工时、IW42 批量确认、MIGO 发料、MB31 按订单收货。维护订单里的计划成本会在订单下达后累计，订单技术完成时结算到成本对象。讲个真实翻车案例：某项目上线第一周，设备部反馈「订单都做完了，但财务说没成本」。查下来是工序没有做确认，WIP 一直挂在订单上，TECO 后成本没有释放到结算对象，财务报表里自然看不到。我后来在运维手册里加了一条标准动作：订单技术完成前，必须跑一遍未确认工序检查，把 IW41 的批量确认界面作为每日收尾检查项。

这里用一段 ABAP 抽查订单状态，比一张张点开界面快：

SELECT aufpl, aufnr, equnr, iloan, pprio, erdat FROM aufk WHERE aufart IN ('PM01','PM02') AND erdat >= '20240101' INTO TABLE @DATA(lt_aufk) UP TO 200 ROWS. IF lt_aufk IS NOT INITIAL. LOOP AT lt_aufk INTO DATA(ls_aufk). WRITE: / ls_aufk-aufnr, ls_aufk-equnr, ls_aufk-iloan. ENDLOOP. ENDIF.

说明：aufk是订单抬头表，equnr在设备相关订单里会被写入，iloan是功能位置编号（内部字段）。抽查时最常看的是pprio（优先级）和erdat（创建日期），用来排查当月订单是否集中在某一天被突击创建——通常意味着补录。

3.3 结算规则与成本归集：月末不让财务追着你问

维护订单上的成本，包括物料费、外部服务费、内部人工小时费。订单结算规则决定这些成本转到哪里：成本中心、资产、内部订单或获利段。配置路径：SPRO → 工厂维护和维修 → 维护订单 → 订单结算 → 维护结算参数文件。结算参数文件定义订单默认采用哪种规则，如果配置了「自动建立结算规则」，SAP 会在订单创建时按设备/功能位置上的成本中心自动生成规则。

最容易翻车的是：设备主数据上的成本中心没维护，或者结算参数文件里不允许自动创建，订单结算时系统提示「订单 & 没有结算规则」。此时除了补配置，前台也可以用 IW32 给订单手动追加一行结算规则。成本归集到资产时，SAP 会向资产模块发更新请求，若资产模块未做「允许资本化维修」的增强，维修费用转资产会失败。

我一般建议在测试环境里用一张测试订单走完整条链：创建 → 下达 → 发料 → 确认 → TECO → 结算，运行 COOIS 订单信息系统或维护订单成本报表，核对订单实际成本与 FI 记账凭证是否一致。这一步能发现大量「订单该归成本中心却归到资产」的配置问题。财务顾问常要求 PM 顾问写清楚订单类型与成本对象对照表，其实更好用的是做一条「订单类型 × 是否允许资本化 × 默认结算对象」的规则表，在配置文档里直接对齐，省得月结时手工查。

这里补一个参数细节：PM 订单的成本对象可以是成本中心，也可以直接是内部订单。如果维修项目跨多个成本中心或需要跟踪项目预算，建议用内部订单做中间归集对象；如果只是日常修理，直接用成本中心最干净。SAP 在结算时支持百分比和金额两种分配方式，跨成本中心时用百分比，单成本中心时用 100% 规则即可。

4. 预防性维护与检修策略：时间计划、性能计划和计量点的取舍

4.1 时间计划：单周期还是多周期

预防性维护进入有效运转以后，企业开始关心「保养计划怎么排」。SAP 提供维护计划（Maintenance Plan），可以通过时间或性能触发。先用时间计划：计划按固定周期（每天/每月/每 200 小时）生成维护订单，排程方式有单周期计划（类型 1）、多周期计划（类型 3）和带工厂日历的排程。事务代码 IP01 创建计划，IP10 调度，IP02 更改，IP03 显示。

选择单周期还是多周期，取决于一台设备是否同时存在「日点检、月度保养、年度大修」三种频率。同一台设备如果建了三个维护计划，订单生成会重叠；用多周期计划可以让一个计划覆盖多个周期，但执行界面复杂，业务端容易混淆。我的做法是：基础保养全用单周期计划，把高频和低频分成两个计划，用策略配置到设备；只有对大型机组做组合检修时才引入多周期策略。先简化，等运作稳定后再细化。

关键参数是排程的开始日期和调用间隔（Call Number）。SAP 的排程算法按调用编号递增计算到期日期，修改过去日期可能会导致计划重排，必须在测试环境试运行。很多项目一开始把维护计划里的「开始日期」填成上线日，之后业务发现有一批设备错过了首次保养，去改了计划开始日期，结果系统把未来所有调用都重算了。这里的正确做法是：用 IP10 先跑一次模拟调度，看生成记录，再决定是否正式提交。

4.2 性能计划与计量点：让设备读数自己说话

性能计划（Performance-based Maintenance）按照计量装置的读数触发维护。比如压缩机每运行 8000 小时换机油、电机累计振动值超过阈值做检修。需要三个要素：计量点（Measuring Point）、计量凭证（Measuring Document）、维护计划（类型 2 或 4）。

计量点挂在设备或功能位置上，记录测量单位和上限/下限阈值。操作工在 IK11 里输入当前读数；SAP 比较上次读数差值，对照维护计划的预期值生成订单。这里最容易踩的坑是测量单位和计数精度不一致：有的泵计数器读数是小时，有的读数是加仑，单位配错后读数差值完全不可用，预防性维护订单要么不触发、要么过量触发。

我建议在做性能计划时先做一轮「计量读数频率审计」：哪些测点每天有读数、哪些读数本身不可靠。如果一个测量点一个月读不到几次，建性能计划就是给自己找维护负担，不如回归时间计划。计量点必须用统一的「计量凭证类型」记录，否则在 IK03 显示测量点历史时数据是断层。

提示：建性能计划前，先在测试机用两个读数试跑一次排程，确认读数差值单位与维护计划触发单位一致。这个测试 5 分钟就能做完，能挡掉 80% 的性能计划配置错误。

4.3 策略、计划包与调度参数：别让计划生成变成玄学

策略（Strategy）在 SAP 里决定同一维护计划下不同周期如何组合调度。以一台设备为例，每 30 天换过滤器、每 90 天换润滑油、每 180 天大保养，可以在同一个维护计划下用策略包定义。调度参数（Scheduling Parameter）包含「计划开始节点」「排程窗口（调度提前量）」「调用日期偏移」。设置排程窗口后，SAP 会在提前量范围内自动生成订单；窗口太小则订单常常晚到，窗口太大则订单提前过早，业务压力大。

我常用的排程窗口是计划到期日提前 5 个工作日，覆盖「物料备货」和「人力排班」的最小提前量。窗口的设置在 SPRO → 工厂维护和维修 → 维护计划 → 计划调度 → 定义时间确定规则里配置，按订单类型分。这些参数影响的是自动生成订单的时间点，如果改成「订单立即生成」，车间会收到大量未来订单，反而让计划列表失去参考性。

性能计划在配置里和策略紧密相关：计量器读数差值超过计划策略定义值时，SAP 会在排程时增加一序调用（Additional Call）。要看清这些逻辑，IP10 跑维护计划排程后，检查计划调度日志和订单创建历史，确认触发原因是时间还是计数，否则很难说服设备工程师相信计划是精确的。最后，维护计划里用到的维护订单类型也会影响自动生成逻辑。如果维护计划把订单类型设为 PM04，但 PM04 在系统里配的是「外部服务采购订单」，自动生成的订单会带出错误的服务确定逻辑，这类组合配置需要一版一版地验证。

5. SAP PM 高频翻车现场：五条值得记下来的避坑记录

5.1 通知单创建时提示「合作伙伴缺失」

现象：前台 IW21 保存通知单报错，提示必须填写合作伙伴，用户拿着一张故障报告在系统外等。 原因：通知单类型没有分配合作伙伴确定过程；或功能位置/设备主数据上没有维护通知单相关合作伙伴（如损坏责任人）。 解决：在 SPRO → 工厂维护和维修 → 通知单 → 通知单类型 → 定义通知单类型的合作伙伴确定过程，分配过程到 M1/M2/M3 类型；同时在 IE03/IL03 里维护设备/功能位置的默认合作伙伴。顺手在通知单屏幕格式里把「合作伙伴」标签页放开，并配置字段状态。做批量导入时，合作伙伴字段经常被漏掉，所以导入模板里必须有「损坏联系人」「计划员组」这两列，不要只在表面配置里修。

5.2 维护订单下达了还是不能发料

现象：订单状态已经是 REL，但 MIGO 发料时报订单/项目冻结，或者物料无法被选中。 原因：较常见的是订单里的物料未做 PM 专用库存类型设置，或者发料移动类型与订单类型不匹配。PM 订单发料一般用移动类型 261（消耗），收货用 262；若物料主数据在工厂下未允许「维护订单」发料，则不会出现在计划料里。 解决：先查订单的计划料是否齐全（IW32 → 物料标签页）；物料主数据仓储视图是否维护；再用 MIGO 选移动类型 261 参照订单。若仍报冻结，检查订单类型配置——有些订单类型只在特定状态允许发料，下达后状态字段未正确流转会导致发料冻结。注意仓库组织级别的「发货工厂」和订单工厂要一致，否则系统会按跨工厂转储去处理，直接报错。

5.3 月末结算时订单没有结算规则

现象：CO88 批量结算提示「订单 & 没有结算规则」，成本滞留挂在订单上，财务月结卡住。 原因：订单类型配置的结算参数文件没有勾选「自动建立结算规则」；设备/功能位置主数据上成本中心为空；订单处于 TECO 之前状态时结算规则未创建。 解决：SPRO 维护订单类型的结算参数文件，选择可自动创建规则；在 IE02/IL02 里把成本中心维护到设备；对已创建的订单用 IW32 手动维护结算规则。经验：每个月结前跑一次订单状态检查报表，把「未 TECO + 无结算规则」的订单清单提前拉给业务去清。这条我做过无数次，每次都是生产计划部先来问「为什么成本没跑到我们部门」，实际上就是他们没在下达时检查设备上的成本中心。

5.4 计量点读数有了，但维护计划不生成订单

现象：IK11 录入计量值正常，但性能计划到排程日期后没有产生预期订单。 原因：最常见的是计量单位和维护计划单位不一致（如计划按小时、计量点按天），或测量点未挂到维护计划对象列表；其次可能是计划调度的「计数溢出」参数设得太窄，读数差值被判定为负值而忽略。 解决：IK03 查看测量点单位，与 IP03 维护计划的计量单位对齐；确认维护计划的「测量点/计数器」标签页里已经挂入该测量点。排程后检查 IP10 的日志，SAP 会列出被过滤器条件排除的调用。我在项目里常让业务每天在同一时间点录入读数，这样计数器差值更稳定，不容易触发异常逻辑。

5.5 订单 TECO 后仍提示无法完成结算

现象：订单已经技术完成，但结算单执行时报「订单 & 项目 & 未确认」或「活动类型费用缺失」。 原因：内部人工成本需要有工作中心的活动类型与费率（KP26）加持。工序已确认，但工作中心没有维护活动类型，成本无法核算，结算就会被挂起。 解决：在 CR01/CR02 维护工作中心成本计算视图，分配活动类型（如 LAB、SETUP），在 KP26 维护该期间费率；同时核对订单工序的「控制键」是否允许成本核算。曾经有项目把这步拖到月结前一天才处理，财季末差点被集团通报——从那以后我会在项目初始化阶段就把工作中心费率测一遍。这个坑属于「配置期埋雷，月结期引爆」的典型，建议在运维手册里加一条月结前检查：工作中心成本视图、工序确认、结算规则三条同时过一遍。

6. 从 PPT 到需求边界：用这套资源快速做一轮项目核对

拿到这份 PPT，不要急着当培训教材从头讲。我惯用的做法是先做一轮「对象清单对表」：把 PPT 里涉及的功能位置、设备、BOM、任务清单、通知单、订单、维护计划、计量点全部列成一张 Excel 表，逐项问业务方「现状有吗？用哪个字段记录？谁负责维护？」这轮访谈通常能暴露设备编号规则没人定义、维修工时没人记录、备件领用不走订单三大问题。

然后是流程对表：PPT 里的业务闭环图可以和系统实际走一遍对照。比如「通知单 → 订单 → 发料 → 确认 → 结算」这条路，用一台测试设备建测试订单，把事务代码 IW21 → IW31 → MIGO → IW41 → TECO → CO88 全部跑通，确认每个状态切换的真实操作人。我习惯把每个操作的人和事务代码都贴在流程图下，防止上线后操作工发现系统行为和 PPT 演示不一致。

最后是配置差异表：用 SPRO 配置清单（通知单类型、订单类型、编号范围、结算参数文件、维护计划策略）和 PPT 对照，标出哪些在演示里成立、在客户现场未必成立。比如 PPT 假设设备都是有成本中心的，但很多老厂设备挂在资产网下没有成本中心，结算模型就要调整。再比如 PPT 里的通知单类型只有 M1/M2/M3，但实际现场有 M4（安全整改）、M5（外部服务合同内维修），通知单编码规则就要扩展。

从那以后，我每次做 PM 模块的需求调研，都强制自己先走一遍「对象清单—流程对表—配置差异」三轮核对，不看完 PPT 直接讲课。这半小时的检查能挡掉大部分上线前夜的翻车。希望帮到你。

本文还有配套的精品资源，点击获取