PM 模块在企业信息化建设中的实施方法
—— SAP-PM 模块如何摆脱鸡肋的角色（上）

特邀撰稿人：北京承泽星汉信息技术有限公司 仝文革

目前，国内许多大中型企业都已经实施了SAP（企业管理解决方案）系统PM（项目管理）模块，但限于PM模块自身功能的不足，以及企业用户要求的不断提升，PM 模块在企业设备管理信息化建设中的地位越来越尴尬，不实施不行，实施了又满足不了要求。本文希望通过对PM 模块实施方法的讨论，来论证SAP 系统PM 模块如何摆脱其在企业信息化建设中的鸡肋角色。

大中型企业不得不实施PM 模块

首先，当企业发展到一定规模，按行业通常的说法，年销售额在60 亿以上时，其原有的各种信息化管理软件的功能就逐渐满足不了企业的业务需求，尤其是满足不了财务管理的需求，而只能通过实施具有高度集成化、系统化、功能化、模块化特点的SAP 系统，才能更好地满足企业的快速、长远发展需求。

其次，企业这种因发展而产生的各项新的业务需求，不会因为企业不断地实施新的软件系统而得到解决，反而会因为新系统的实施造成更多的信息孤岛和业务断点，给系统操作用户带来更多的跨系统操作难度和信息使用的不方便；同时，多套系统的存在，在很大程度上还会造成数据的不一致性和不准确性，这些都会影响企业用户对这些系统的使用热情和信任度。

因此，企业所需要的信息化管理系统，必须具有集成化、系统化、功能化，尤其是具有平台化的特点，才能更好地解决用户跨系统重复操作、业务流程闭环管理、多系统信息查询的难题。这些都决定了只有实施SAP 系统才能更好地解决企业的现实需求。

而随着SAP 系统在大中型企业中的实施，作为SAP系统的模块之一，PM 模块与SAP 系统其他模块间，尤其是与物料管理模块和财务管理模块间的无缝关联，决定了企业同时也要实施PM 模块来满足其设备管理业务需求，尤其是设备在企业生产经营活动中占有重要地位时，企业实施PM 模块就更成了必然的选择。

当然，也有企业许多企业已经分别实施了各自的设备管理系统，这时，他们就会尝试将这些原有设备管理系统与SAP 系统的物资、财务等模块间做接口的方式来取代PM 模块，但由于这些接口关系过于复杂，开发工作量过在而不得不放弃接口开发的想法，转而考虑先实施PM 模块，再将这些在用设备管理系统与PM 模块建立接口来实现这些系统与SAP 系统财务、物资管理模块间的间接关联。

再加上PM 模块实施咨询方一般都会承诺在PM 模块中结合系统标准功能，进行适当开发来实现企业的需求，这些承诺也会使SAP 系统实施企业下定实施PM 模块的决心。

以上这些都定了企业在实施SAP 系统时，都会同时实施PM 模块，来满足企业设备管理业务需求。

PM 模块的地位不尴不尬

通过上述分析，我们可以知道，SAP 系统实施企业在实施设备管理系统时，一般都会首先实施PM 模块，但PM 模块在其实施企业中一般都会处于一种不尴不尬的地位，这种地位的产生主要有以下原因：

/PM 模块的管理范围难于满足企业需求/

PM 模块的管理范围主要集中在设备维修管理，即设备的检查（巡检，以发现问题为主）、维修（以恢复设备的功能为主）、预防性维修（以预防故障的突发性维修为主）。

而随着企业的发展、设备管理水平的提高以设备管理需求的提升，企业对设备维修管理的基本需求已经转变为设备全生命周期管理需求，设备全生命周期管理将设备管理业务分成了规划管理、采购建设、运行维护、退役管理四个业务阶段，此时，设备维修管理只是运行维修阶段中的一个功能阶段，其他功能阶段的业务需求，例如，运行管理、安全管理、退役管理、专业管理、专项管理、固定资产管理等功能阶段的业务需求，以及公共管理需求，例如，审批待办、移动办公、档案管理等需求，都已经超出了PM 模块标准功能的管理范围；同时，PM 模块原来只涉及设备管理部门，现在因业务需求的扩展，扩大到运行管理部门、安全管理部门、固定资产管理部门、物资管理部门等。

因此，不管从业务管理范围、还是业务涉及部门，PM 模块现有标准功能都已经不能满足企业现实设备管理需求。

/PM 模块的标准功能过于简单/

从PM 模块现有标准功能来讲，是以实现设备维修的业务需求为主，因此，它的标准功能使用主要集中在设备基础台账管理、维修工单管理方面，还有一些功能，例如，通知单、预防性维修计划、计数器、计量凭证、BOM、任务清单等，虽然都属于PM 模块标准功能，这些功能好看不好用，需要企业做许多基础工作和具备相当高的管理水平后才有可能使用好功能，因此，这些功能的使用效果普遍比较差，或根据用不起来。

再加上SAP 公司最码有二十年没有对PM 模块的标准功能进行过大开发和提升，因此，其功能老旧、界面难看、字段描述难懂、操作复杂。

以上这些现象的存在，造成PM 模块的标准功能一方面不能满足企业对设备全生命周期管理业务的需求，另一方面，其界面风格和操作复杂的基本特点，都让企业用户对其产生很大的意见，对PM 模块功能的提升和操作改进有了更多的要求。

企业在设备全生命周期管理过程中，有一些重要的功能模块需求，在PM 模块的标准功能中，根本就没有对应的功能给予解决，或者即使有对应的功能，也由于使用繁杂或对管理水平、人员素质的过高要求而没有办法在企业实施。

/ 完整实施设备全生命周期管理的开发量太大/

在企业实施SAP 系统PM 模块时，如果想按设备全生命周期管理的业务需求开发、完善其标准功能，就必须单独建立一个项目，专门投入大量的人力、物力和时间来进行设计、开发和测试工作，仅该项目的实施就至少需要一年半的时间，才能完成设备全生命周期基本业务需求的开发工作。

而一般企业实施SAP 系统时，都只是将PM 模块当成SAP 系统的一个标准模块实施，在费用、顾问、时间等方面都不可能按独立项目实施的要求来投入，这些也决定了PM 模块在SAP 实施企业只能完成标准功能的实施，开发工作也主要集中于报表和少部分增强功能的开发；项目实施的要求也以在规定期限、规定开发量、规定人员投入范围内，尽早完成项目实施任务、确保整个SAP 系统的顺利上线为目的。

因此，在这种项目实施的指导原则和要求下，SAP 系统实施咨询公司就不可能从总的实施费用中专门为PM 模块划出一部分费用和时间来进行PM 模块的深化运用实施，咨询公司项目组也不能要将过多的注意力投入PM 模块的实施中，项目实施顾问就更不可能自找麻烦把标准功能之外的项目开发需求引入到PM 模块的实施工作中。

所以，PM 模块标准功能的实施一般都不会满足用户的需求，用户通常只能达到数据收集整理、对部分业务流程和数据进行标准化，项目实施就只能实现设备管理业务的最基本需求；而随着用户对PM 模块已实施功能了解的逐渐深入，加上对PM 模块繁锁功能的持续使用，以及还存在许多需要在线下手工操作、带来额外工作量的情况，就会逐渐产生对PM 模块、甚至于对SAP 系统本身的不满，但日常工作要求又不得不使PM 模块，用户的不满就会日益加深。

以上这些情况都造成了PM 模块在企业设备管理信息化建设中的尴尬地位，即，用不好用，不用又不行；企业信息化管理部门也处理两难之间，即，不进行设备管理业务信息化建设不行，建设了企业基层用户又不说自己的好；企业领导也没有难受，年年在设备信息化建设方面投入资金，可每次投入都解决不了根本性问题，下次还得投入。

上图是对炼化设备管理系统的需求分析统计表，从表中可以看出，PM 模块标准功能只能满足用户需求的11%，其他89%都需要通过程序补充开发的方式来满足。

/PM 模块的后续功能提升效果不理想/

有许多SAP 系统PM 模块实施企业的领导都已经意识到了PM 模块实施的问题，所以，希望通过后续的提升项目、或专业改进项目来提升、改进、完善PM 模块的标准功能，但这些提升和改进工作并没有取得理想的使用效果。

这种情况是如何产生的呢？我认为主要还是PM 模块的提升或改进项目仍然只是从PM 模块某些功能点的不足着手提出改进工作的a，这些提升或改进仍然是建立在PM 模块标准功能的基础上，对部分标准功能的不足做出适当的改进，对某些系统功能的缺失进行程序开发来予以满足，这些所谓的提升或改进仍然站在设备维修的角度、从设备管理部门的需求提出的，从业务范围来讲，并没有从设备全生命周期的角度考虑问题，也没有从打破部门界限、打通业务流程闭环环节的高度，跳出PM 模块本身，尤其是跳出SAP 系统功能限制，从设备全生命周期管理业务需求系统化、集成化的角度来设计和分析各系统和流程间的业务、流程、数据、接口关系。由于这些局限的存在，造成了PM 模块或设备管理系统的后续功能提升与改进项目的实施效果必然达不到企业的原始期望，其结果就是企业不断地投入人力、物力和财力实施提升和改进项目，可每次的实施效果都达不到企业的预期目标，只好又对下次提升项目充满期待。

右图显示，北京承泽星汉公司在实施设备管理系统时的服务思想。

另一方面，就是PM 模块项目咨询实施方的项目实施思想问题，他们一直以做项目的态度来实施PM 模块提升或改进项目，这种态度一定会要求项目经理要在有限的费用、时间内完成项目实施工作，项目实施顾问必然又会以尽量少的开发、最低的风险的项目实施态度来实施提升项目。所以，这种态度就决定了PM 模块提升或改进项目不可能取得预期效果。

其次，就是许多SAP 系统实施顾问都有一个共同的认识，那就是在SAP 系统中不可以做大量的程序开发工作，这些额外的开发会对SAP 系统的标准功能产生许多不利的影响，再加上项目实施指导思想的影响，就更造成项目实施顾问不愿意过多进行PM 模块补充功能的讨论和设计、开发工作。

其结果仍然是，企业领导在期望、失望中轮回，企业用户在不断增加的工作中痛苦，企业自身在不断投入中增加成本。

那么，PM 模块如何摆脱其在企业信息化建设中的尴尬角色，就成了一个摆在PM 模块项目实施双方企业面前的一个重大问题。