企业官网建设流程全解析

简介：这份 SAP PM 工厂维护学习资料面向 SAP 顾问、设备管理信息化人员及希望系统掌握 PM 模块的初学者，围绕设备、功能位置与固定资产的维护管理展开，帮助读者建立从技术对象结构到维护订单执行的完整认知。压缩包内共 1 个 PPT 文件，约 661KB，以图文幻灯片形式呈现，便于按章节浏览与课堂讲解。内容覆盖技术对象结构、主数据管理、通知与信息编译、即时与修改维护流程、维护订单与日程管理、商务与技术完成、R/3 与 ABAP/4 组件关系、SAP 各模块协作、供应商处理与投资管理、技术系统信息系统等核心知识点，并配有功能位置、设备与装配关系的示意说明。目前已有 361 人学习，适合作为 SAP PM 入门梳理与项目实施的参考材料。

1. 从一份 2004 年的 SAP PM 培训胶片说起：它到底能解决什么问题

如果你正在做 SAP PM（Plant Maintenance，工厂维护）模块的实施或运维，手头大概率缺一份能把「技术对象结构 → 主数据 → 通知 → 维护订单 → 计划排程」这条主线串起来的完整资料。这份 SAP PM 资料就是干这个的——它是一套项目二期的培训胶片，从技术对象结构讲起，一路覆盖到通知编码、即时维护与修正维护的区别、维护订单与通知的关系、工时确认、商务完成与技术完成的边界。适合三类人：刚接触 PM 模块、需要快速建立全局认知的顾问；已经在做设备主数据维护、但想搞清楚功能位置与设备层级关系的运维人员；以及需要给团队做内部培训、想找一份结构清晰参考材料的负责人。它不是操作手册，而是一份能让你理解「为什么这样设计」的培训底稿。

2. 技术对象结构：功能位置、设备与装配的层级关系怎么搭

SAP PM 的一切都建立在技术对象结构之上。如果你把设备主数据当成一张张孤立的卡片来维护，后面做维护计划、排程、成本归集时一定会翻车。这份资料用轨道交通车辆的例子把层级关系讲得很清楚：一列地铁（功能位置 VSP-nnnn）下面挂转向架、制动系统、牵引单元等子功能位置，转向架这个功能位置上再安装具体的设备，比如轮对、齿轮箱、牵引电机。理解这套结构，是后面所有操作的前提。

2.1 功能位置与设备的本质区别

功能位置（Functional Location）描述的是「系统中的一个位置」，它是一个区域或一个安装点，本身不是要被维护的物理对象。设备（Equipment）才是那个「作为独立单元来维护的物理对象」。资料里的定义很直白：功能位置是技术结构中的一个元素，代表一个可以安装对象的系统领域；安装在功能位置上的对象，在 PM 系统中称为设备。

这个区别在实际操作中非常关键。比如一根管道上的泵，管道是功能位置，泵是设备。泵可以拆下来送修，但管道位置不会动。如果你把泵直接建成功能位置，后面做维修工单时就没法把泵作为一个独立对象来跟踪它的维修历史和成本。

结构指示器（Structure Indicator）是控制功能位置编码规则的模板。它定义了结构可以包含多少层级、每层的编码规则是什么、哪一层在哪个字符结束。编辑模板（Editing Mask）则定义了编码用数字还是字母来生成。这两者配合，决定了你整个工厂的功能位置编码体系。

2.2 用 IE01、IL01、IB01 搭建技术对象结构

资料里给出了三条并行的搭建路径：按设备结构（IE01）、按功能位置结构（IL01）、按维护装配结构（MMP1）。实际操作中，我一般会先建功能位置层级，再在对应位置上建设备，最后用 IB01 把维护 BOM 挂到设备上。

* 创建功能位置（IL01） * 事务码：IL01 * 输入结构指示器，系统自动带出编码模板 * 逐层创建：VSP-nnnn → VSP-nnnn-BO → VSP-nnnn-BO-01 * 创建设备（IE01） * 事务码：IE01 * 设备类别：M（机器）或 P（生产资源） * 关键字段：设备描述、功能位置（安装位置）、计划组、工作中心 * 将设备安装到功能位置（IL02/IE02） * 事务码：IL02 或 IE02 * 在功能位置中安装设备，系统自动建立安装关系 * 安装后设备继承功能位置的部分主数据 * 将维护 BOM 链接到设备（IB01） * 事务码：IB01 * 输入设备号，维护 BOM 用途选择 4（维护 BOM） * 逐项添加组件：物料号、数量、单位

逻辑说明：IL01 建功能位置时，结构指示器决定了编码的层级和格式，一旦有数据就不建议再改。IE01 建设备时，功能位置字段可以先留空，等设备到货安装时再用 IL02 挂上去。IB01 链接维护 BOM 时，用途字段一定要选对，维护 BOM 的用途代码通常是 4，选错了后面做维护订单时备件计划带不出来。

参数说明：设备类别决定了设备能用的功能范围，M 类设备支持维护订单和通知，P 类更偏向生产资源。计划组（Planner Group）用来区分负责计划工作的人，工作中心（Work Center）用来区分执行工作的人，主工作中心（Main Work Center）则是维护监督人员用来分配工作的。这三个字段在建设备时就要想清楚，后面改起来会影响已有订单。

2.3 物料主数据与维护 BOM 的配合

物料主数据（Material Master）是所有物料信息的中央来源，分两类数据：纯描述性的（名称、尺寸、维度）和系统用来执行控制功能的（MRP 类型、价格控制）。维护 BOM 只包含与维护相关的项目，它有两个核心功能：一是把对象从维护视角结构化，二是为维护订单做备件计划。

我见过不少项目把维护 BOM 当成采购 BOM 来用，结果备件计划时带出一堆不相关的物料。维护 BOM 的定位是「这个设备维修时需要哪些备件」，不是「这个设备由哪些零件组成」。这个边界一定要在项目初期就跟业务方对齐。

3. 通知与维护订单：从故障报告到工单确认的完整链路

通知（Notification）和维护订单（Maintenance Order）是 SAP PM 日常操作中最核心的两个事务。资料里把这条链路拆得很细：输入故障报告（IW21）→ 创建维护订单（IW31）→ 完成维护订单（IW32）→ 确认维护订单（IW41）。每一步都有明确的业务含义，跳步或者顺序错了，后面的成本归集和维修历史就会乱。

3.1 通知的编码体系：目录、代码组与代码

通知不是随便写一段文字就完事。SAP PM 用目录（Catalog）来管理预定义的代码，目录下面分代码组（Code Group），代码组下面才是具体的代码（Code）。资料里列了几种目录类型：任务（Tasks）、损坏原因（Damage causes）、活动（Activities）、对象部件（Object parts）、损坏（Damage）。

* 维护目录、代码组和代码的配置路径 * SPRO → 工厂维护和客户服务 → 维护通知 → 通知类型 → 目录 * 实际创建通知时的操作（IW21） * 事务码：IW21 * 通知类型：M1（故障报告）或 M2（维护请求） * 必填字段：参考对象（设备或功能位置）、描述、优先级 * 编码页签：选择目录类型 → 代码组 → 具体代码 * 损坏代码：从目录中选择，描述技术对象的损坏情况

逻辑说明：目录和代码组是配置层面的东西，一般在项目上线前由顾问配好。日常操作时，用户只需要在通知的编码页签里选择对应的代码。损坏代码的选择直接影响后续的维修分析报表，如果用户随便选，后面统计故障模式时数据就没法看。

参数说明：通知类型决定了通知的编号范围、屏幕布局和后续处理流程。M1 通常用于故障报告，M2 用于维护请求，M3 用于活动报告。不同通知类型可以配置不同的必填字段和编码目录，这个在项目蓝图阶段就要定下来。

3.2 维护订单的创建、计划与确认

维护订单（Maintenance Order）是执行维护工作的载体。资料里区分了即时维护（Immediate Maintenance）和修正维护（Corrective Maintenance）两个过程，以及 PM 订单与通知之间的关系。简单说，通知是「报告问题」，订单是「安排解决」。

* 创建维护订单（IW31） * 事务码：IW31 * 订单类型：PM01（修正维护）或 PM02（计划维护） * 参考对象：输入设备号或功能位置 * 从通知创建：输入通知号，系统自动带出参考对象和描述 * 计划维护订单（IW32） * 事务码：IW32 * 操作：分配工作中心、计划工时、分配备件、打印工单 * 确认维护订单（IW41） * 事务码：IW41 * 输入实际工时、物料消耗、技术确认文本 * 系统自动计算成本并归集到订单 * 商务完成（IW32 → 功能 → 完成 → 商务完成） * 技术完成：工作已做完，但可能还有后续采购或发票未处理 * 商务完成：所有成本已归集，订单不能再接受任何记账

逻辑说明：从通知创建订单时，系统会自动把通知的参考对象、描述、编码信息带到订单里，省去重复输入。计划阶段要分配工作中心和备件，这些信息会决定订单的成本预估。确认阶段输入实际工时和物料消耗，系统自动计算实际成本。商务完成和技术完成的区别在于：技术完成表示工作做完了，但可能还有采购订单未收货、发票未校验；商务完成表示所有财务相关的事务都已处理完毕，订单关闭。

参数说明：订单类型决定了订单的编号范围、结算规则和成本归集方式。PM01 用于修正维护，PM02 用于计划维护，PM03 用于大修。工作中心决定了人工成本的计算费率，备件从维护 BOM 中带出，也可以手动添加。

3.3 计划维护与排程：IP10、IP42、IP11 的配合

计划维护（Planned Maintenance）是 SAP PM 中自动化程度最高的部分。资料里给出了完整的操作链路：创建总维护任务清单（IA05）→ 创建维护策略（IP11）→ 创建维护计划（IP42）→ 排程和启动维护计划（IP10）。

* 创建总维护任务清单（IA05） * 事务码：IA05 * 任务清单类型：A（一般维护任务清单） * 输入工序：描述、工作中心、计划工时 * 可以分配物料组件 * 创建维护策略（IP11） * 事务码：IP11 * 策略类型：基于时间的策略或基于性能的策略 * 维护包：定义维护周期和偏移量 * 创建维护计划（IP42） * 事务码：IP42 * 输入维护计划类别、参考对象、任务清单 * 分配维护策略和维护包 * 设置排程参数：周期、开始日期、提前天数 * 排程和启动维护计划（IP10） * 事务码：IP10 * 输入维护计划号，执行排程 * 系统自动生成维护呼叫对象或维护订单

逻辑说明：任务清单定义了「做什么」，维护策略定义了「多久做一次」，维护计划把两者绑在一起并设置排程参数。IP10 执行排程后，系统根据设置的提前天数自动生成维护订单或呼叫对象。计划组和主工作中心在这里发挥作用：计划组决定谁负责计划，主工作中心决定谁负责分配工作。

参数说明：维护策略中的维护包定义了周期和偏移量，比如「每 3 个月一次，偏移 0 天」或「每 1000 小时一次」。排程参数中的提前天数决定了订单提前多久生成，太短会导致准备时间不够，太长会导致订单积压。周期修正因素和宽容度用来处理实际执行日期的偏差。

4. 避坑与排查：SAP PM 实施中最容易翻车的五个地方

4.1 功能位置编码改不了，上线前一定要想清楚

现象：项目上线后业务方要求调整功能位置编码规则，发现结构指示器一旦有数据就无法修改。

原因：结构指示器决定了功能位置的编码模板和层级规则，SAP 不允许在有数据后修改，因为会影响所有已创建的功能位置。

解决：上线前用沙箱环境充分验证编码规则，至少模拟三层以上的层级结构。如果确实要改，只能新建结构指示器并重新创建功能位置，旧数据需要做数据迁移。

4.2 维护 BOM 用途选错，备件计划带不出物料

现象：创建维护订单时，从维护 BOM 带不出备件，或者带出了完全不相关的物料。

原因：维护 BOM 的用途代码选错了，或者 BOM 链接到了错误的对象上。

解决：检查 IB01 中 BOM 的用途是否为 4（维护 BOM），检查 BOM 是否链接到了正确的设备或功能位置。如果 BOM 是从采购 BOM 复制过来的，要清理掉不相关的项目。

4.3 通知的损坏代码随便选，后面报表没法看

现象：用户创建通知时随便选损坏代码，导致后续故障模式分析报表数据混乱。

原因：目录和代码组没有根据实际业务场景做裁剪，用户面对太多选项时倾向于随便选。

解决：在配置中精简目录和代码组，只保留实际需要的代码。给用户做培训时强调损坏代码对后续分析的重要性。可以在通知类型中设置必填的编码字段，强制用户选择。

4.4 商务完成和技术完成混淆，订单关不掉

现象：维护订单已经技术完成，但商务上无法关闭，或者关闭后还有发票进来无法处理。

原因：技术完成和商务完成的含义没搞清楚。技术完成表示工作做完，商务完成表示所有财务事务处理完毕。

解决：在订单确认后先做技术完成，等所有采购订单收货、发票校验完成后，再做商务完成。如果订单已经商务完成但还有发票进来，需要用后续调整事务处理，比较麻烦。建议在项目培训中把这两个概念作为重点讲解。

4.5 计划维护的排程参数设错，订单要么积压要么来不及

现象：维护计划排程后，要么生成大量提前订单积压，要么订单生成太晚来不及准备。

原因：排程参数中的提前天数、周期修正因素和宽容度设置不合理。

解决：提前天数根据备件采购周期和人员准备时间来确定，一般 7 到 14 天比较常见。周期修正因素用来处理实际执行日期与计划日期的偏差，宽容度用来允许一定的提前或延后。建议先用小批量维护计划试运行，观察一个周期后再调整参数。

5. 进阶技巧：用 IW38 和 QE51N 做维护历史与结果记录

维护订单做完不是终点。资料里提到了两个容易被忽略的事务码：IW38（查看订单工作清单）和 QE51N（查看记录结果的工作清单），以及 QA11（用途决定）。这三个事务码配合使用，能把维护执行结果反馈到质量管理模块，形成闭环。

* 查看订单工作清单（IW38） * 事务码：IW38 * 选择条件：订单类型、计划工厂、工作中心、日期范围 * 可以批量查看订单状态、工时、成本 * 用于日常运维监控和月度报表 * 查看记录结果的工作清单（QE51N） * 事务码：QE51N * 选择条件：检验批来源、工厂、日期范围 * 用于查看维护订单触发的检验批结果 * 与 QA11 配合使用 * 用途决定（QA11） * 事务码：QA11 * 输入检验批号，做使用决策 * 决定检验批是接受、拒绝还是返工 * 结果反馈到维护订单和通知

逻辑说明：IW38 是日常运维中最常用的事务码之一，可以批量查看订单状态、工时消耗和成本归集情况。QE51N 和 QA11 用于维护订单触发的质量检验流程，比如维修完成后需要做质量确认的场景。这三个事务码把维护执行、成本归集和质量结果串在一起，形成完整的维护历史记录。

参数说明：IW38 的选择条件中，订单类型和计划工厂是必填的，工作中心和日期范围用来缩小结果集。QE51N 的检验批来源要选对，维护订单触发的检验批来源通常是 03 或 04。QA11 的用途决定会影响后续的库存移动和成本结算。

我自己的习惯是：每次维护订单技术完成后，先用 IW38 检查工时和成本是否已正确归集，再用 QE51N 确认检验结果是否已记录，最后才做商务完成。这个顺序走一遍，基本不会出现订单关不掉或者成本对不上的情况。从那以后我每次做 PM 模块的配置变更，都强制走一遍「通知 → 订单 → 确认 → 完成」的完整链路，确认没有断点才放手。希望帮到你。

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