推动PDM本身的发展和完善

申请免费试用、咨询电话：400-8352-114

1.基于PDM的互动

我们不断地听到诸如“基于PDM的产品开发设计过程”等说法，就我个人看来所有“基于PDM…..”的事实似乎都可以用“基于PDM的互动” 来概括。
   
1) 基于PDM的人与人之间的互动  已经实施了的用户、正打算实施的用户、供应商、学者、咨询顾问，在他们之间进行的讲授与倾听，演示与观看、自由讨论等活动，形成了一种相互映证，相互启发的互动；

2) PDM与应用技术之间的互动   PDM与CAD、Cax等应用软件之间，在产品建模、配置管理、BOM管理、系统仿真等方面，天然具有一种紧密互动关系。通过互动使应用软件的功能得到充分发挥，同时更加凸显PDM的优势。需要注意的是由于一些CAD、Cax开始强调其自身所具有的管理功能，所以有必要考虑PDM和这些软件之间的协调，避免冲突和冗余；

3) PDM与的管理信息系统之间的互动 最典型的是与ERP，ERP可以从PDM获取唯一可靠的产品数据源，而PDM可以利用ERP最大限度地实现自己的价值。通过对它们之间“集成方案进行精确的规划”，能够“真正发挥两者的核心优势”。
   
4) PDM与技术和创新管理之间的互动  产品建模、大批量定制、流程重组、协同商务、企业动态建模等适应新的市场竞争环境的理论框架和技术在PDM的支持下得到有效应用，同时反过来使PDM的内涵和外延得到进一步深化和拓展。

虽然上述“基于PDM的互动”是那样激动人心，但是我们不得不感到些许遗憾，因为至今为止还没有看到在不同软件的开发和实施人员之间，尤其是PDM和ERP的开发和实施人员之间形成真正的、公开的互动，这使得PDM与ERP之间的互动缺乏足够的深度和自主性。现在要求所有用户都考虑购买具有统一平台的企业信息系统还不现实的，对构建在不同平台上的系统进行集成还是当前企业信息化的一个极其重要的需求，所以特别需要为不同系统的开发人员和和实施人员搭建一个诸如此类的互动平台，使他们之间自主互动，而不是应用户要求针对具体问题的被动“互动”，那不是我们所希望看到的。

2.  对“关键”问题的辩证思考

关于PDM实施，有一些问题被反复提到，由于它们在项目中的重要性和困难程度，我们一直把它们当作“关键”问题来分析和解决。随着对PDM的认识更加接近其本质，以及实施和应用方面的经验的积累，必然要对一些“关键”做出辩证思考，思考的结果是，有些被过度重视，而有些则重视不够，不管属于哪一种情况，我们在解决这些关键问题时，要么还没有好的方法，要么没有采取好的方法。这样的尴尬，妨碍了问题的解决，增加了项目风险。

1) 编码 

从已经实施的情况来看，对编码问题解决得都不怎么好，我认为一个主要原因是没有把它放在一个适当的位置，负责编码的人不了解PDM中编码的本质要求，无法完全摆脱传统编码系统的影响、盲目借鉴别人的经验和原则，追求大而全，赋予编码太多的功能，把简单问题复杂化等。

系统要求每一个对象必须至少有一个唯一编码，零部件仅仅是其中一类或几类对象。由于在PDM中产生的零部件编码可能在随后传递到ERP或其他管理系统中，因此显得比其他一些仅仅局限在PDM中的对象编码更加重要，类似的还有产品编码、配套件编码以及原材料编码等。在PDM中每一个对象对应一套属性卡片，通过若干属性完整地给出其定义和有关信息，这些信息足以帮助用户对对象“分类”和“理解”，不一定非要通过编码达到这样的目的。编码只不过是这些对象属性中的一个，由于被指定为对象唯一标识，因此才显示出独特的含义，仅此而已。正因为它的“独特性”在于“唯一性”，所以只要具备“唯一性”就基本上算是一个合格的编码。认识到编码的本质，有理由相信针对PDM的零部件编码，不管是其过程还是结果，其实都可以非常简单。

建立“编码体系”一般有几种主张：

* 主张建立“有效的零部件编码系统”，既要能“分别进行识别”又要能 “分类处理”，既要“简洁明了”又要“易于理解”，例1-107-41-001。对企业基础数据和编码人员素质要求很高，需要较长时间完成。
* 主张无含义编码，最容易实现，但是不适合人工处理，例4712。
* 主张介于两者之间，用户多数倾向于这种方案，分类码+顺序码，例0J0046。

祁国宁教授认为PDM项目中的前期工作，应按照“建立编码体系、零部件ABC分析、零部件分类、零部件名称分析”的内容和顺序来，而一些用户根据自己的经验认为将“建立编码体系”放在上述步骤的最后一步完成比较好。在这些工作当中，对企业现有零部件等编码对象的数据，进行收集、整理、分析、规范，剔除“垃圾”，比建立编码体系更加重要。

“编码系统与很多因素有关”，其中“编码目的、编码的应用范围对编码的结构和内容影响最大”，编码过程中遇到的主要困难是，涉及的对象多、部门多、历史数据多，往往牵一发而动全身，特别需要事先明确目的、范围和一般原则。一旦编码问题阻碍了项目进程，要考虑到PDM的目的不是建立“编码系统”，恰恰相反，建立“编码系统”是实现PDM目的的一个过程，基于这种认识尽量采取简单化处理，迅速把项目拉到正常轨道上来，比如“对于已经有零部件编码系统的企业，只要这些零部件编码具有唯一性，也可以作为Part-ID使用，以减轻由于更换编码系统而造成的来自各方面的压力。”

对于编码，在思想上给予适当重视，采取符合企业自身特点的、可以驾驭的编码原则和方法，建立一套实用的编码体系。

2) 配置管理和项目管理

配置管理和项目管理是PDM的两个基本功能，但是直到现在，仍然只有少数PDM产品宣称具有这两个功能。和“文档管理”功能相比它们显得高深莫测，这越发刺激了对于它们的想象，因此经常被高估。实际上，配置管理和项目管理的思想或模式对任何企业都是有效的，但是作为PDM系统功能，其应用是有条件的，并不是对所有的企业都适合。

* 配置管理  基于产品建模技术和大批量定制模式。对于按订单装配模式比较适合；对于按订单制造模式，需要加入一定的人工干预，应用起来比较困难；对于按订单设计模式，因为需要很多人工干预，该功能几乎不起作用。即使是按订单装配模式的企业，如果没有采用产品建模技术，建立起完整的产品模型以及配置规则，该项功能同样不起作用。配置管理功能在汽车行业得到普遍应用，并取得良好效果，而在其他行业案例中却很少提及，就是这个原因。

* 项目管理  根据调查发现，在PDM中项目管理应用效果最差，“在实际运作过程中远比想象中复杂，有时需要很多人工干预”。主要原因是“软件方面没有突破”，可以理解为该功能在技术上还不成熟，和实际需求还有一定的距离。除此之外，“由于项目工作的复杂性和创造性，以及创造性工作的非线性本质（做了50%的工作，并不意味着改任务完成了50%）”，“项目管理模式不是太简单就是太复杂，在许多情况下，它们简直就是不切实际”。

我曾经说“配置管理和项目管理简直就是两个陷阱”，当时主要是一种直觉，现在看来有一定道理。用户在选型的时候，要仔细分析自身特点和条件，对这两个功能可以不要就不要。如果考虑到今后变化，可能需要，那个时候再通过软件升级或增加模块来解决。对于选择了这两个模块的用户，在PDM项目实施中必须下大力气建立起完整的产品模型和配置规则，对现有业务流程进行改造或改进，否则用不起来。

3) 产品建模

“成功实施PDM系统的重要前提是建立科学、合理、可操作的PDM模型，包括产品模型、过程模型和项目模型”，其中最关键的是产品模型。然而，对此我们却重视不够。在有些供应商的项目计划或实施方案中提到了“选择一个产品”、“建立数据模型”等，但是这是从项目管理的角度提出来的，目的是“导航”，并作为项目阶段性“里程碑”，此“模型”非彼“模型”。

根据有关“基于PDM/ERP的开发设计过程”及其产品模型的论述，我们也可以反过来说“基于开发设计过程的PDM/ERP（项目）”，从字面上理解前者用于指导对某一类PDM/erp系统的应用，后者则用于指导对“某一类PDM/ERP系统”的实施和创建。这意味着，在PDM项目准备和实施阶段，就要充分考虑 “开发设计过程”的需要，建立完整的产品模型，包括三维设计模型、产品结构模型、工程图、产品文档，以及配套件、原材料和毛坯等。可以想象，把这项工作真正做扎实，工作量和难度都非常大，在有限的项目周期内也许只能做到相对的“科学、合理、可操作”，但是只要有一个这样的基础，在项目完成后还可以继续不断的改进和完善。

重要的是认识到产品建模，以及配置管理等都是为了贯彻一种思想，即 “减少内部多样化，增加外部多样化”，避免“零部件和文档数量过度增长、制造过程难以控制、工艺装备数量增加、生产成本提高、交货周期延长等严重后果”，对企业是长远有利的。基于这种认识，有必要组织专门班子负责产品建模及其相关工作，抛开一般开发设计工作中不可避免的短期利益和局部利益的干扰，另外可以将这项工作和历史数据处理结合起来统筹考虑。

来源：E-WORKS