PLM项目的成功率已经成为了企业忧心忡忡的问题。项目启动，进程失控，预算失控，领导不满意，员工意见大，这些现象在IT项目中并不鲜见。如何通过项目管理的手段及方法，保证项目的成功也就成了企业十分关注的问题。而项目管理是所有实施方法论的基础。
PLM项目管理的生命周期
产品生命周期管理项目本身也有生命周期，一个完整的PLM项目通常包括三大阶段:需求分析、系统选型和系统实施；在系统实施阶段又可细分为实施计划、业务模拟测试、系统开发确认、系统转换运行、运行后评估这五个主要步骤。项目管理围绕整个PLM项目的全过程，对项目的立项授权、需求分析、软硬件的评估选择，以及系统的实施进行全面的管理和控制。一个典型的PLM项目管理循环通常包括：项目开始、项目计划、项目执行、项目评估及更新和项目完成六项主要内容。
第一阶段：项目开始 项目开始阶段主要针对PLM项目的需求、范围和可行性进行分析，确定项目的愿景、目标与宪章(Charter)，制定项目的总体安排计划，项目主要的里程碑和路标(Roadmap)，进行投资回报分析，并以“项目合同”的方式由企业与PLM项目咨询公司确定项目责任和授权。在项目开始阶段进行的项目管理主要包括以下内容：项目目标评估；项目范围定义；可行性分析；项目总体安排；投资回报分析；项目授权；项目启动仪式和项目签字仪式是造外势。
第二阶段：项目计划 项目计划阶段是PLM项目进入系统实施的重要阶段，主要进行的工作包括：确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、质量保证计划、沟通计划、人力资源计划等。
第三阶段：项目执行 从客户角度来看这才是项目的真正开始。这个阶段项目经理和项目组将代表公司完全承担合同规定的任务。项目执行阶段是实施过程中历时最长的一个阶段，贯穿PLM项目的业务模拟测试、系统开发确认和系统转换运行三个步骤。实施的成败与该阶段项目管理进行的好坏休戚相关。在项目执行阶段进行的项目管理的主要内容包括:实施计划的执行；时间和成本的控制；实施文档；项目进度汇报；项目例会；会议纪要。
第四阶段：项目监控 项目评估及更新阶段的核心是项目监控，就是利用项目管理工具和技术来衡量和更新项目任务。项目评估及更新同样贯穿于ERP项目的业务模拟测试、系统开发确认和系统转换运行三个步骤中。在项目评估及更新阶段常用的项目管理工具和技术有：阶段性评估；项目里程碑会议；质量保证体系。
第五阶段：项目结束 主要包括移交工作成果，帮助客户实现商务目标；系统交接给维护人员；结清各种款项。完成这些工作后一般进行项目评估。评估可以请客户参加，让其表达意见，并争取下一个商业机会，或请求将项目作为灯塔向其他客户展示。最后，举行庆祝仪式，让项目成员释放心理压力、享受成果。
PLM项目的实施方法论
在过去国内的一些PDM的项目实践中，还往往仅限于技术部门的工程数据管理系统，与实施ERP系统相比，没有引入实质性的管理改革；现在，越来越多的企业认识到，要发挥PDM的威能，必须把PDM作为企业级的管理软件来开展实施。同时，对实施顾问以及项目经理而言，在PDM软件实施项目中，项目进程的控制、质量的保证、技术的交付以及管理流程重组的有效性往往是他们关心的问题，专业的实施方法论是解决这些问题并保证客户满意度的有效方法。
作为企业管理软件，与ERP实施相比，PDM项目实施的共同的思路在于：
1、必须建立企业级的，以企业的客户需求为驱动的业务流程体系和信息规范。
系统的实施伴生的是管理的优化，随着业务流程再造BPR理论通过信息技术得到完美的实现，企业管理人员达成了一个重大共识：以客户为核心的、跨越职能部门的“流程”来观照业务，而不是以企业传统层级的、部门本位化的职能运作来开展业务。通过IT技术推动业务的优化如果在企业某个职能部门进行，或者在供应链体系里某个孤立的企业进行，反而会造成新的信息孤岛和信息沟通障碍。所以，ERP实现了财务和物流、销售以及生产制造之间的信息同步，同样，PDM的实施必须跳出产品设计部门的领域，以所谓的“客户的声音”作为流程的驱动源，横跨设计、工艺、技术标准管理、生产规划、制造执行、销售等等企业相关职能环节，消除了流程冗余和错误，提高工作的效率和信息的准确性，达到提高质量，降低成本，缩减产品上市周期的目的。质量、成本、上市周期通常是实施一个PDM项目的效果衡量的关键绩效指标(KPI)。
2、项目管理、业务流程优化和变化管理等非技术性的因素在保证实施的成功率方面，具有与技术因素等量齐观的重要性。
管理软件的实施非常强调人的作用，领导的支持、人员转变的促成、沟通和协调等因素一般被认为是关键成功因素。PDM系统的最终用户很大一部分是产品设计人员，在现实中，技术人员时常有一些 “创作冲动”，不必要地在设计中标新立异，习惯个人主义的工作方式，具有保密个人创作的本能等工作特点，这与PDM倡导的提高设计重用率，团队协作和“公共工作区”等工作方式存在抵触。依靠企业领导的重视，开发共同愿景和加强沟通，从而推动变化管理是PDM实施中一个重要的环节。
3、正确认识实施期望，减少技术风险。
管理软件的实施毕竟不同于软件的开发，应该把项目资源和项目重点放到对业务问题的分析、优化和实现上去，避免技术细节的纠缠。特别是对过去没有系统的企业第一次导入PDM这样的大型管理系统，更要分清80/20原则。一般来说，大多数PDM软件的功能性模块的既有功能已经抽象了企业的一般性的需求，在作出开发独有功能前，顾问和用户最好仔细考虑进行这些开发的必要性。当然，产品数据的灵活性决定了PDM实施的技术开发量要稍多于ERP软件的实施。
与ERP这类的管理软件实施相比，PDM的实施又具有以下一些显著的不同之处：
1、主数据的准备将围绕数据的分类管理
对ERP这样的业务系统来说，一般实施无需过多考虑数据格式的问题，或者，在实际实施过程中，尽量向软件本身的格式去靠拢。然而，构成产品定义(Product definition)的数据规格在不同企业以及同企业的不同部件(例如电子器件和机械结构件)之间则千差万别，例如电子器件更多的是电气性能的描述，而机械件则是物理属性和规格尺寸的描述。因而，PDM数据的灵活度要比ERP大很多。PDM实施一般用“对象化”的思路去理清产品项目定义的各个信息组成；各种文档，如设计规范、二维图纸、三维模型、技术文件、工艺数据文件、制造资源文件等等虽然看起来复杂，实质上都是与某个构成产品定义的“对象”有着对应关系的支持性文件；而数据的灵活性则表现为属性(Attribute或Characteristics)的多样化。因而，PDM的实施在数据准备方面有着与其他管理软件实施迥然不同的思路，支持这种思路的，则是分类管理(Classification)的方法。
分类管理就是将企业业务数据对象的事物特性，例如功能特性、制造特性、成本特性和几何特性等以属性的形式抽象出来，并将属性进行归类，建立一个层级的类结构。可以说，分类管理构成了整个PDM的实施框架，也是定义PDM系统数据范式的基础，使得查询、分析、结构配置等功能成为可能。产品本身的分类管理有一些参考性标准。此外，在实施中，还要研究项目管理的项目活动的分类问题。
2、通过动态的业务建模来搭建业务逻辑。
与ERP相比，PDM应用不到10年，加上企业研发和工程管理本身业务的灵活性，PDM软件不仅需要有基本的现成业务功能，而且必须适应企业灵活的业务逻辑。关于PDM软件选型甚至有一种说法，“与其看PDM产品功能有多强大，不如看产品有多容易定制”。当前，先进的PDM系统都提供了一套定义整个系统数据范式 (schema) 的环境，也就是通常说的业务建模器(business modeler)，主数据的格式可以通过这个工具非常灵活地定义。所以，实施PDM通常需要有细致的业务建模工作，这在过去实施ERP中并不常见。
3、流程的规划以评审决策(Review and decision)为关键控制点。
ERP的流程实现一般来说是一种基于“交易规则”的行为；而PDM的流程会以工作流(workflow)的方式为载体，一个工作流的启动和结束将改变数据对象的状态或版本，这种改变通常会意味着管理者的评审通过与否。评审是一种人为的、主观化的行为，在PDM实施中，我们发现，一般用户往往不愿意承担审批签发的责任，而管理人员的审批又往往因为管理者本身的技术能力限制而流于形式，从这个意义上看，PDM的流程是以评审贯穿的、基于条件的、柔性的过程。
PDM实施的流程设计，在很大程度上是对评审权限的分配 (例如如何设置新产品开发评审委员会，工程变更评审委员会等) 、评审条件以及通过规则的定义。面临激烈的市场竞争和产品应市期缩短的要求，通常某个业务的流程还会有不同情形下的快速轨道(Fast Track)和普通轨道(Normal Track)等变通选择。
在PDM流程设计方面，也有一些参考性做法，例如新产品开发方面的PACE方法，产品结构和变更管理方面的配置管理标准(CMII)，这些流程无不是以审批决策作为流程的控制点。
除了以上几点，PDM实施在基础设施的部署、系统架构、文件管理、外围系统整合等技术因素方面也有显著的特色。
PLM项目实施除了具有一般项目管理的特点和生命周期外，从技术的角度来看，它就象一个软件产品的开发，需要包括对用户需求的深刻理解，持续不断的用户培训和系统上线后的技术支持。
对每一个阶段的主要任务和活动进行定义，尤其强调文档资料的管理。让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。天下没有不散的宴席，项目组的成员也是在动态调整中，文档就是成员之间交接的重要工具。很多主管很容易陷入“重技术实现，轻文档”的误区。他们总是认为项目实施时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是项目周期稍长，到了最后，成员还会对每个实现细节记得清清楚楚吗？没有文档的项目铁定是一个失败的项目。从过程控制的角度看，项目的实施质量控制，最重要的就是文档的管理控制。通过文档来显示表明每个基线，每个成员的工作量和完成质量，达到项目的风险最小化。
确定项目范围
这阶段的重点是对项目的范围、需求和资源进行清晰、明确的定义，通常包括以下活动和任务：达成对理解的共识；广泛收集各个层次的需求；撰写SOW(任务描述书)；规划项目实施的路线图；与客户一起审阅SOW；客户认可并签署SOW；客户方成立项目组；配置测试与开发服务器；正式的项目启动仪式。
阶段成果：项目任务书；比较粗的项目计划；项目团队的组建。
需求收集
项目规划阶段收集的主要是现有流程的分析，需求阶段的重点是描述未来系统支持的流程。通常包括以下活动和任务：对客户的项目团队培训系统模块；了解客户的业务流程；定义功能目标；系统架构的需求；收集功能需求；应用集成的需求；系统上线的策略；准备，审阅和签署需求/用户界面规范；准备，审阅和签署项目验收的标准；进行差距分析；估计开发的工作量。
阶段成果：签署项目需求规范书 (这是关键交付物)；签署用户界面需求规范书(这是关键交付物)；详细的项目计划。
系统设计
系统设计阶段将定义从流程到系统功能实现的关键步骤，将直接决定最终的系统。通常包括以下活动和任务：定义流程模型；定义对象模型；配置软件；定义流程模型规范；定义对象模型规范；设计要交付的系统；决定实际的运算环境；决定数据划分的逻辑；文件存储的策略。
阶段成果：签署系统设计规范书 (这是关键交付物)。
编程开发
这个阶段的重点是客户化，对软件包的进一步配置和开发以实现系统设计中包含的流程和功能。通常包括以下活动和任务：工作的分配；构建系统管理、业务对象和工作流；开发用户界面；开发客户化的程序；开发历史数据迁移的工具；开发工作流；单元测试；撰写软件客户化的文档资料；准备集成和功能测试计划。
阶段成果：客户化的源程序；集成和功能测试计划；详细的客户化文档资料。
测试和验收
这阶段要确保开发的系统提供项目规范书上承诺的功能。在测试服务器上根据集成和功能测试计划进行测试。可能要根据反馈的结果更新系统。其最终结果达到客户验收的标准。通常包括以下活动和任务：根据集成测试计划进行集成测试；根据功能测试计划进行功能测试；进行缺陷分析；修复缺陷。
阶段成果：提交源代码(这是关键交付物)；集成测试结果；功能测试结果。
用户培训及反馈
这阶段主要是针对关键用户进行培训，并且得到他们的反馈。通常包括以下活动和任务：准备用户手册，培训资料；建立培训环境；对关键用户培训；对系统管理员培训。
阶段成果：对系统的反馈；用户手册；培训手册。
系统推广
这阶段主要是建立生产环境，把系统从测试环境迁移到生产环境。系统验证结束后，将投入正式使用。通常包括以下活动和任务：搭建生产环境；从测试环境迁移到生产环境；系统试运行；历史数据导入；面向最终用户投入正式使用
阶段成果：项目结束报告；签署项目验收通过报告。
8/31/2011
|
