1.1PDM/PLM与ERP在实施中的区别

    在过去国内的一些PDM/PLM的项目实践中，往往仅限于将技术部门的工程数据管理系统与实施ERP系统相比，没有引入实质性的管理改革。现在，越来越多的企业认识到，要发挥PDM/PLM的威力，必须把PDM/PLM作为企业级的管理软件来开展实施。同时，对实施顾问以及项目经理而言，在PDM/PLM软件实施项目中，项目进程的控制、质量的保证、技术的交付以及管理流程重组的有效性往往是他们关心的问题，专业的实施方法论是解决这些问题并保证客户满意度的有效方法。经过多年的实践，ERP实施方法论已经比较成熟，例如，SAP的ASAP或Value SAP方法Oracle的AIM方法论。由于PDM/PLM软件的特性以及产品数据的特性，PDM/PLM系统的实施与ERP系统的实施相比有很多不同的地方。
 
PDM/PLM系统的实施相比ERP系统主要体现在一下以下方面：
    (1)主数据的准备将围绕数据的分类管理。对ERP这样的业务系统来说，不同企业虽然业务不同，但是会计账套设置、订单格式、物料信息等还是基本类似或者有共通部分，因而一般ERP实施无须过多考虑数据格式问题。 然而，构成产品定义(Product definition)的数据规格在不同企业以及同企业的不同部件(例如电子器件和机械结构件)之间则千差万别，例如，我们所要介绍的通讯行业中的电子器件更多的是电气性能的描述，而机械件则是物理属性和规格尺寸的描述。
 
    因而，PDM/PLM数据的灵活度比ERP大很多。PDM/PLM实施一般用“对象化”的思路去理清产品项目定义的各个信息组成；各种文档，如设计规范、技术文件、工艺数据文件、制造资源文件等虽然看起来复杂，实质上都是与某个构成产品定义的“对象”有着对应关系的支持性文件；而数据的灵活性则表现为属性(Attribute或Characteristics)的多样化。
 
    因而，PDM/PLM的实施在数据准备方面有着与其他管理软件实施迥然不同的思路，支持这种思路的，则是分类管理(Classification)的方法。分类管理就是将企业业务数据对象的事物特性，例如，功能特性、制造特性、成本特性和几何特性等以属性的形式抽象出来，并将属性进行归类，建立一个层级的类结构。可以说，分类管理构成了整个PDM/PLM的实施框架，也是定义PDM/PLM系统数据范式的基础，使得查询、分析、结构配置等功能成为可能。
 
    (2)动态的业务建模ERP由MRPII发展至今有近20年的历史，业务逻辑相对来说已经模式化和成熟，而与之相比，PDM/PLM应用不到10年，加上企业研发和工程管理本身业务的灵活性，PDM/PLM软件不仅需要有基本的现成业务功能，而且必须适应企业灵活的业务逻辑。
 
    当前，先进的PDM/PLM系统都提供了一套定义整个系统数据范式(schema)的环境，也就是通常说的业务建模器(business Modeler)，主数据的格式可以通过这个工具非常灵活地定义。所以，实施PDM/PLM通常需要有细致的业务建模工作，这在过去实施ERP中并不常见。图3-1是PDM/PLM系统一般的建模对象，我们也将在后文介绍本文项目中的对象模型。

    (3)流程的规划以评审决策与ERP的流程所谓的“交易规则”的行为不同，PDM/PLM的流程会以工作流(workflow)的方式为载体。一个工作流的启动结束将改变数据对象的状态或版本，这种改变通常会意味着管理者的评审通过与否。
 
    评审是一种人为的、主观化的行为，在PDM/PLM实施中，我们发现，一般用户往往不愿意承担审批签发的责任，而管理人员的审批又往往因为管理者本身的技术能力限制而流于形式。 从这个意义上看，PDM/PLM的流程是以评审贯穿的、基于条件的、柔性的过程。PDM/PLM实施的流程设计，在很大程度上是对评审权限的分配(例如，如何设置新产品开发评审委员会、工程变更评审委员会等)、评审条件以及通过规则的定义。
 
    面临激烈的市场竞争和产品应市期缩短的要求，通常某个业务的流程还会有不同情形下的快速轨道(Fast Track)和普通轨道(Normal Track)等变通选择。除了以上几点，PDM/PLM实施在基础设施的部署、系统架构、文件管理、外围系统整合等技术因素方面也有显著的特色。
 
1.2PDM/PLM系统实施方法论
    PLM项目实施除了具有一般项目管理的特点和生命周期外，从技术的角度来看，它就像一个软件产品的开发，和软件工程的实施方法比较类似，需要包括对用户需求的深刻理解，持续不断的用户培训和系统上线后的技术支持。作者对PDM/PLM的实施方法论提出一些自己的见解，如图3-2所示。

    下面对图示中的每一步予以简单解释，对每一个阶段的主要任务和活动进行定义
    (1)确定项目范围该阶段的重点是对项目的范围、需求和资源进行清晰、明确的定义，主要是和客户达成对理解的共识。
 
    (2)需求收集项目规划阶段收集主要是现有流程的分析，需求阶段的重点是描述未来系统支持的流程。它们通常包括以下活动和任务：
    ＞了解客户的业务流程；
    ＞定义功能目标；
    ＞系统架构的需求；
    ＞收集功能需求；
    ＞应用集成的需求等。在需求收集阶段，我们将主要采用UML用例图来实现对需求的收集和分析。因为用例图主要用于描述拟建系统和外部环境的关系。
 
    (3)系统设计系统设计阶段将定义从流程到系统功能实现的关键步骤，这将直接决定最终的系统。通常包括以下活动和任务：
    ＞定义系统架构；
    ＞定义流程模型；
    ＞定义对象模型；
    ＞定义用户交互界面流程在定义用户交互流程中，比较好的方法是使用UML顺序图，可以明确定义消息的传递的流程。

    (4)编程开发

    (5)测试验收

    (6)用户培训鉴于篇幅，本文将介绍需求收集，系统设计及一部分核心模块的开发的顺序进行介绍,省略测试验收和用户培训这两步。