产品
一个成功且优秀的PLM系统，一定不是由顾问公司实施出来的，而是企业本身经过长期的运维优化得到的。
技术开发部技术经理，熟练操作PAM-STAMP、Dynaform、HyperMesh等软件，对冲压件仿真分析有较丰富的应用经验；熟练操作 Deform、 Simufact.Forming(原MSC.SuperForge）等软件，对金属的冷锻、冷挤仿真有较丰富的经验；精通Solidworks，对SolidWorks的导入、推广、培训有丰富的经验。对于其他的CAD软件如PRO/E、UG等掌握其基本操作；熟悉Teamcenter、PDMWorks等产品数据管理软件，对图纸的编码、分类、标准件库的构建、图文档的管理等有丰富的工作经验。
欧美日等发达国家应用各种管理系统已经有几十年的历史，目前从底层到中高层对系统的作用、理念、应用细节都有很深的经验和积累，而国内中小企业真正开始大规模应用管理系统也就最近十几年的事情，目前的大多数中高层管理对PLM系统的认知和应用经验积累较少，平日繁杂的日常工作使得其没有时间精力参与系统架构（即使参与做出的决策也许有悖于系统实施）；
还有就是高层对具体执行层业务不参与，仅了解大概，高层对系统主架构、主流程规划完毕后，需要中层落地，但中层没有时间或者不具备系统落地实施的能力，而顾问公司经验和水平良莠不齐，实施时受限于顾问本身的行业经验和行业经历，实施效果通常都不甚理想，系统上线后问题多，效果差；笔者从自身经历总结初次实施导入PLM系统的一些建议，总结如下。
PLM售前阶段，一般都是高层或决策层（具体业务层不参与）与外部供应商之间洽谈，实施PLM系统的目的一般是基于公司战略或者信息化需求，这很容易造成PLM系统方案前期制定的项目目标一般都假大空类型的，没有明确的项目目标，很多时候是为了上系统而上系统，项目实施结果往往不尽如人意。
笔者建议在项目合同中就明确具体的项目目标，不要是那种提供设计效率多少个百分点，或者降低成本多少，这种目标一是很难统计，二也会对项目验收造成障碍。
笔者建议可以结合企业的实际现状和问题，提出具体的目标，比如设计数据的版本管理（解决版本混轮导致的报废问题），设计数据的唯一数据源管理（解决多数据源造成的采购或加工问题），设计数据的电子审批（解决纸质文档的人工受控成本）、历史数据整理导入的范围和方法（解决历史数据的导入PLM系统问题）、基于PLM系统变更管理（非文档变更，产品变更问题收集，解决、通知等）、需要实现项目管理（资源管理、项目进度统计等，目标可以更细化）……；
对于这个过程越具体，企业的需求就越明确，不仅仅有利于实施商的后期服务，也有利于企业对自身需求的清晰思考，对决策层和实施层是一场在项目实施前的头脑风暴和深度思考，能够为项目成功上线并发挥实际作用提供坚实的基础。
目前所有的PLM系统实施或者方案，一般都大谈战略、规划、噱头吹的太多，实际上方案内容一般都是行业通用解决方案，不涉及项目上线后结合企业的现状后具体实施结果或效果；不可否认公司战略、规划等内容一般公司高管都是很关心的，因为与其平日工作内容比较贴合；
但是PLM系统是一个直接面向研发、设计、项目管理等人员的系统，基础层用户一般都具有较高的学历或企业经验，且系统上线后也与他们的本职工作也息息相关；如果上线后的效果不好，操作繁复，流程冗余,即使管理层面强行推广，基础操作层用户也会以种种理由（系统慢、宕机、流程审批时间长等等））阻碍系统推广和日常运营，久而久之就不了了之了，运营时间越长，PLM系统问题越多，口碑越差。
所以笔者建议，在项目实施前期，调研完成以后，就需要实施商对需要对基础用户进行详细的应用培训，明确PLM系统介入后，对基础层用户的日常工作会带来哪些变化，如果有条件最后对未来业务场景进行简要的演示，不仅仅会大幅度减少系统上线以后的抱怨或者BUGS，也会让基础层用户参与进来，有利于基础数据的收集及完整、完备。
管理层过于重视企业发展战略、主流程等本身工作相关的领域，而对基础数据收集、整理、录入等细节重视力度不够甚至完全忽略；而项目实施时，一般都讲所谓的一把手（企业或组织）原则，希望公司高层直接参与，提高项目的执行力，但高层一般只关注战略、流程、对基础数据产生过程、特点、复杂程度没有深入了解、各部门主要领导基本不深入参与项目实施（大部分只参与调研）、实际产生数据人员对项目没有发言权。
PLM系统实施往往过于满足高层需求，而忽视基础用户层的需求，且一般企业，在实施PLM系统时，特别是系统架构阶段，基础用户层是没有任何的决策权的，高层决策80%的系统架构，底层没有决策权，但是基础数据方面，底层用户提供90%以上的基础数据；如果底层数据质量太差，PLM系统架构再合理，报表再完美，都是没有意义的。
万丈高楼平地起，没有一个坚实的基础，公司的战略和流程无论规划的多么合理高效都是水中望月、空中楼阁；没有完整、准确、高质量的基础数据作为基础，任何的规划都是无意义的；所以笔者建议，在第一期实施阶段，要花大力气，把主要精力放在基础数据以及历史数据的收集整理中，系统涉及的相关人员，全员参与。
PLM系统架构（蓝图）完毕，基础用户层要参与及评审；如果高层直接规划数据产生层基本架构，这样就存在一个问题：实际规划人不操作系统，不了解数据产生的具体过程，不关心数据产生、录入过程的难易、复杂程度；很多问题都是上线之后一段时间才集中爆发出来，这个时候系统的主要架构已经定型，只能修修补补，勉强维持运行。
一切魔鬼都在细节里，项目的实施过程，具体到每个字段、每条细枝流程都需要系统实际操作人员的确认和认可，符合数据本身的特点，如果数据录入过程本身过于繁复、就需要对其进行二次开发，提高数据进出系统的效率；如果数据本身容易产生问题，就需要进行防呆、防错、标准化、交叉检查等手段，基础数据的完整、准确程度决定未来整个系统的质量程度。
一个成功的系统，无论是最基础的数据产生还是中间过程的流程审批、数据的二次利用，以及最后的归纳报表，在实施过程中都需要全体系统相关人员的亲身参与，这样系统正式上线运行之后才能做到预期规划和实际相匹配。
PLM系统一旦上线，过渡阶段完毕后，需要从流程和制度上，将线下作业完全取消，一些企业因为种种原因，PLM系统与系统外作业同时存在，这样就会造成数据源不唯一，系统运行一段时间后，就会暴露种种问题，例如：
① 本来为了简化流程或者加急而设置的一些线下通道被无限制使用；
② PLM系统数据的不标准、不完整；
③ 无有效版本管理。
笔者认为，保持PLM系统数据中心位置至关重要、唯一数据源的作用也很重要，所以一定要下决心取消线下的受控盘、共享盘、个人数据存储、邮件等数据的存储和分享方式，确立PLM系统的数据中心位置，建立准确可靠的唯一数据源。
一个成功且优秀的PLM系统，一定不是由顾问公司实施出来的，而是企业本身经过长期的运维优化得到的；实施公司只能帮助企业建立标准、规范作业、导入系统，而一个系统是否有用且好用，这就需要企业本身长期持续的投入、维护、优化；
如果只是靠上线时系统本身的架构和功能也许可以维持一段时间，但是随着企业本身业务及环境的发展和变化，系统本身又缺少运维优化，那么最终的结果就是运用越不好用，抱怨和障碍增多，势必会影响PLM系统的正常运行，所以企业在此方面需要长期投入培养相关的人员、最终将系统变成企业自己信息化系统不可分割的一部分。
实施PLM系统还有很多其他的注意事项，比如企业的标准化、历史数据的整理方案、主服务器硬件架构及网络架构、涉及多个地域的还要考虑异地设计协同，异地文件服务器管理、与其他系统如ERP/MES/OA等系统的集成、项目管理、变更管理等多个方面；
如果企业本身的信息化基础比较差、企业本身又缺少相关人才储备，管理层对系统功能和特点不熟悉，笔者建议不妨可以考虑小步快跑、分步实施，不要追求大而全的系统，优先选择最紧迫需要解决的问题，上完系统能够立竿见影得到效果的部分功能先上，从点到面逐步实施，既可以节省投入成本，也可以通过此过程使得企业内部人员不断学习成长进步。
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
