4.3 并行工程的核心要素

图4-5给出了并行工程的四个核心要素及其相互之间的关系。以下分别对这四个核心要素进行介绍。

4.3.1 数字化产品定义

并行工程研究的对象是产品，所以首先需要建立数字化的产品模型，而且所建立的数字化产品模型应该支持并行工程目标的实现，即能够支持产品研制过程中不同阶段所使用的软件工具之间（如CAD、CAPP、CAM、CAE、DFA、DFM、PDM软件）的产品信息集成。除了产品功能信息模型和几何模型外，还需要建立产品的特征模型、装配模型以及相应的标准交换文件模型（如建立符合STEP协议的产品模型），从而使所建立的数字化产品模型成为不同软件工具之间交换产品信息的基础，实现不同设计阶段之间的信息集成。

数字化产品定义（digital product definition, DPD）技术是在产品信息建模技术基础上发展起来的、面向产品数据管理层的应用技术，其主要目标是：以面向产品管理层的信息建模为目的，以设计、制造等过程中的应用层建模为基础，以数字化过程中的多种规范为约束条件，以产品结构树为纽带，最终实现产品的数字化定义及其产品数据的管理过程[43]。

数字化产品定义面向设计、分析、制造、装配、维护、销售、服务等产品全生命周期的各个环节，用于描述和定义产品全生命周期的数字化过程中所应包含的信息以及这些信息之间的相互关联关系，并使其成为计算机中可实现、可管理和可使用的信息。数字化产品定义应该满足产品全生命周期的数字化信息需求，它不仅需要对产品全生命期周期中的信息进行合理有效的描述，还要描述和定义这些数字化信息之间的相互关系。因为产品信息之间的关系描述直接影响产品信息的存储、检索查询和使用效率。

数字化产品定义的数据空间模型是一个由生命周期维、产品结构层次维、数据类型维、版本维、控制位置维组成的五维空间模型，如图4-6所示。空间模型的每一个侧面描述产品数字化定义的不同阶段、不同层次、不同数据类型、不同版本和不同位置的产品信息以及信息之间的关联关系。

（1）生命周期维

生命周期维主要描述和定义产品从设计、分析、工艺设计到制造、装配、维护等产品全生命周期中不同阶段的产品数字化定义所应包含的信息以及信息之间的关联关系。

（2）产品结构层次维

产品结构层次维是以产品结构树为基础，用层次化建模方法描述DPD的框架结构。在零件层，主要是建立每个零件的总体信息、管理特征、材料特性、表面要求、特征信息、特征之间的尺寸和位置公差信息等零件层模型。根据产品结构特征，逐步形成组件层、部件层和产品层数据，从而建立完整的产品数据。

（3）数据类型维

数据类型维描述DPD的数据类型。结构化数据是指可以以一定的数据结构对DPD数据进行表达和存储的数据类型，这类数据以数据记录的形式进行表达，并存储在数据库中。例如，产品及其零部件的名称、代号、设计日期、类型等信息；非结构化数据是指所描述的数据具有整体性和关联性，必须以特定的文件格式存储在计算机中，如产品的二维/三维CAD模型、CAE分析报告、工艺文件、NC程序等。在非结构化数据中，按数据内容又分为描述几何信息和非几何信息的数据。

（4）版本维

DPD中版本维主要描述和定义产品生命周期中各种类型的产品数据及其过程数据的版本以及版本的演变历程。版本反映了产品的整个开发过程、开发历程的追溯、开发过程中各开发阶段的多方案比较以及多方案选择等数据信息。

（5）控制位置维

在多厂所联合型号研制中，产品数据分布在地理位置不同的多个地点，并分别由这些位置所控制。因此，DPD的控制位置维主要描述产品数据的控制位置。

数字化产品定义一般由计算机辅助设计系统产生。数字化产品定义可以由计算机辅助设计系统自行管理，或者采用产品数据管理系统进行管理。数字化产品定义的存储格式有许多种。早期，数字化产品的定义和存储格式通常由计算机辅助设计工具的开发方自己定义成一种特定的格式。这种由软件开发方自己定义的特定存储格式给不同软件之间的信息共享造成了很大的困难。为了解决不同软件之间的数字化产品定义信息的集成，国际标准化组织（ISO）第184技术委员会（TC 184）提出了STEP（Standard for the Exchange of Product Model Data）标准。STEP标准是一个描述如何表达和交换数字化产品信息的国际标准（ISO 10303），其目的是提供一种不依赖于具体系统的中性模型和机制，并将其用来描述整个生命周期内的产品数据。

4.3.2 集成化产品开发团队

1．集成化产品开发团队的优势

在传统的功能制串行产品开发模式下，产品开发人员的组织与管理方式存在以下问题：（1）缺乏团队动力：在传统的管理体制中，奖惩的措施大部分建立在个人的贡献上。根据工程人员解决问题的能力来衡量其价值，而对于雇员参与团队协作或凭他们的能力预防设计错误的发生等工作没有奖励的措施。

（2）决策的方式不合理：决策的方式大多数是自上而下进行的。在工程师接手一个新项目时，许多决策早已完成，如计划部门已经选择好了关键产品特性（主要规格、毛重、长度、宽度等），财务部门决定了产品的消耗，企业可以承担的投资，市场部门决定了产品的销售数量，工期管理部门决定了什么时候开始推销。在这种情况下，来自技术专家和产品设计小组的结果与反馈不能在前期决策中加以考虑，因此，通常很难满足用户需求及产品质量、工期要求。

（3）缺乏信任和授权：管理信任是授权参与者去做那些正确的决策，但在传统的管理方式下，雇员没有足够的权力进行必要的决策，在遇到需要决策的问题时往往需要上报和等待，既耽误了时间，也影响了雇员工作积极性。

（4）实施程序僵化：要求参与者遵循非常严格和复杂的程序。

（5）通信效率低：低效率的通信环境使组织中向上、向下和跨部门的信息交换很困难。在下游活动中发现的问题不能及时通知上游活动，这就抑制和束缚了组织不断改进工作的机会。

为了快速、高质量、低成本地完成产品开发，需要对传统的产品开发组织模式进行创新。集成化产品开发团队（integrated product team, IPT）是并行工程模式下实现组织创新的主要方法。团队就是由少数有互补技能，愿意为了共同的目的、业绩目标而采用相同的工作方法并相互承担责任的人们所组成的群体。与传统的组织模式相比，团队更灵活、反应更快，可以快速地组合、重组和解散。团队在目标设置、协调配合、责任和技能方面更有明显优势。采用团队工作模式还有利于提高成员工作的满意度。团队协作具有强大的威力，能使各个本来分散的个人和具有不同能力、不同个性的人结合起来，携手作战，组织成一个具有共同目标、相互协调的整体。团队工作模式还可以更好地实现人的价值，即除了具有独立完成工作的能力外，人的价值更重要的是体现在与他人共同完成工作方面。

集成化产品开发团队是企业为了完成特定的产品开发任务而组成的跨学科多功能型的团队，它包括来自市场、设计、工艺、生产技术准备、制造、采购、销售、维修、服务等全生命周期各部门的人员，有时还包括顾客、供应商或协作厂的代表。集成化产品开发团队能够大大提高产品生命周期各阶段人员之间的相互信息交流，促进其协同工作。

采用团队工作模式可以取得良好的业绩，表4-1给出了通用电气公司属下生产电流断路盒的索尔兹伯里工厂在应用团队工作模式后的效果。

2．集成化产品开发团队的组成

根据团队成员聚集和沟通的方式不同，集成化产品开发团队（IPT）可分为以下两种基本类型：

（1）实体团队

在这种团队工作方式中，团队各成员是真正聚集在一起，面对面进行设计、开会、交流方案、讨论各种设计问题等。成员们完全是处于同一个物理空间，这是最常见的一种形式。

（2）虚拟团队

这种团队并不是面对面地聚集在一起工作，而是通过计算机网络相互联系。在计算机中有一个公共的、统一的产品概念和数据库，成员可以通过网络相互沟通，交换设计数据，甚至举行远程多媒体会议。这种方式完全打破了地域上的限制，使分布在不同办公室、公司、城市、国家的成员可以通过先进的网络系统进行协同工作。

团队组成角色包括：

（1）团队发起人：团队的指导者，负责团队任务分工；

（2）团队领导人：制定团队任务与目标，保证团队的协同工作；

（3）团队成员：执行团队所做出的决策，与其他成员合作完成团队目标；

（4）团队促进者：协助团队工作，确保团队成员平等参与决策；

（5）团队记录员：记录团队的决策及决策过程。

集成化产品开发团队作为一种新的产品开发组织模式，与企业的文化背景和社会环境密切相关。在对国外的集成化产品开发团队组织结构和管理模式进行了总结的基础上，提出以下支持并行工程模式的集成化产品开发团队的组建原则。

（1）IPT是按产品结构的纵向线划分的，根据产品的零部件组成方式，IPT呈递阶层次关系。

（2）IPT的成员来自各功能部门，他们代表产品生命周期的各个环节，在开发过程中为决策提供意见，集体对IPT所开发的产品负全部责任。与过去的工作方式相比，最大的区别在于IPT成员从IPT组长获得日常工作指令，并且鼓励跨学科的信息共享和实时交换，取消常用的递阶式审签制度。

（3）IPT组长从总任务出发，定义产品开发计划、活动、角色、资源等，相对独立的任务仍由功能部门单独执行。

（4）功能部门负责根据IPT负责人定义的任务角色指派相应的人员承担，并且为承担任务的人员配置必要的工作环境。一个角色可以由多个人作为一个小组承担，一个人也可以承担多个角色。

（5）IPT组长和功能部门的负责人分别从任务执行情况和日常工作表现确定IPT成员的业绩。由于功能部门提供了人员和工作条件，他们必须得到IPT管理部门的经费支持。

（6）IPT本身和IPT中的角色有时限要求，在IPT组未完成预定任务前，IPT组和其成员在IPT组长领导下工作。在IPT组预定的任务完成后，IPT组解散，其成员仍回到原有的功能部门中去。

（7）实现IPT的工作模式需要良好的计算机和网络支持环境。

3．团队协作的7个要素

要实现良好的团队协作，需要关注以下7个要素（简称7C）：

（1）协作（collaboration）：指在传统的交流和团队工作中所缺乏的那种成员之间的创造过程。协作不侧重于交流方法，而是对工作中遇到的未事先计划问题和不确定因素进行讨论和合作。

（2）信任（commitment）：授权团队内部要充分的信任，在此基础上确定任务的目标、时间、效用、复杂性、期望结果和关键成功要素。

（3）交流（communications）：有效的交流是有意义协作的先决条件。交流是信息的交换，以及建立一种相互理解的信任。

（4）折中（compromise）：在多个学科之间出现设计冲突时，必须在深入讨论的基础上进行折中，以便进行协同的产品、过程和工具开发。

（5）一致（consensus）：项目组和管理者之间可能存在不同意见，但是对于需求和项目的最终结果必须达成一致，在项目的生命周期内必须始终强调共同的目标。

（6）持续改进（continuous improvement）：产品或过程设计小组致力于通过提高产品质量和缩短产品开发周期来提高产品开发效率。

（7）协调（coordination）：协调包含为达到目标而履行的相互关联的活动，包括目标分解、资源分配、小组决定、成员交流等活动。在项目的各个领域确立伙伴关系，建立高效的通信手段，使供应商在项目早期阶段就能参与到项目中。

4．IPT的管理和决策模式

图4-7给出了并行工程中IPT管理的三种主要模式，即指令型管理模式、支持型管理模式和面向目标的一致性管理模式。

（1）指令型管理模式

指令型管理模式以传统的层次化管理模式为基础，设立了逐级汇报的金字塔管理方式，由管理层建立管理措施，并控制整个运作过程。

（2）支持型管理模式

支持管理基于所有雇员合作和参加的原则。这种模式呈倒三角形结构，客户和供应商在顶部而管理层在底部，突出了强大的多学科群和清晰的客户目标。协同解决问题与有效的项目管理代替了一味的设置数字管理目标，管理层与小组共同工作并确定改进过程的方法。

支持型管理模式基于实际情况实施开发过程管理。这意味着需要将信息提供给支持群供其进行决策，因此，充分的信息提供是实施支持型管理模式的第一原则。第二条原则是要求工作组充分了解生产环节、产品的现有水平以及客户服务方面的情况。

NEC公司按照支持型管理模式进行一种新式膝上型电脑开发。公司首先根据市场需求设立了一个90天的产品开发期限，然后由有经验的管理人员和从各个电脑开发项目组抽调来的人员组成攻关小组，赋予攻关小组在产品开发各个方面的权力。最后用倒计时方法来保证产品在90天内完成开发。

（3）面向目标的一致性管理模式

面向目标的一致性管理模式是支持型管理模式的一种变异。它依然以客户和供应商作为管理引导的方向，但是在众多单元的工作协调中强调了整个组织目标的实现。所有人员都可以向共同管理者汇报其工作，并且向着一个共同一致的目标努力工作。这要求从考虑单个部门或工作组的目标转变到考虑事务单元或企业的目标，IPT必须支持企业目标的实现，并保证不同IPT组目标的一致性。每个人都为一个共同一致目标的实现尽最大努力。管理的作用是不断改进工作，保证与预期目标的一致。在面向目标的一致性管理模式中，IPT组的培训是直接依据某一任务进行的，包括目标、完成任务的过程、交流方法等。

4.3.3 开发过程改进与重组

传统的产品开发模式有一套严格的开发程序，它将开发阶段分为可行性分析、需求定义、系统分析、概要设计、详细设计、工艺编制和制造等几个阶段，各开发阶段界限十分明确，都有完整的文档记录，为保证质量，定期进行评审。这种开发模式阶段性过强，信息大体又是单一流向，即使是有经验的设计者，也经常会在产品设计中产生导致后期可制造性或可装配性方面的错误，由于这些错误不能及时发现和解决，在后期制造阶段发生大的返工现象屡见不鲜，导致产品开发长周期长、成本高。另外，复杂产品开发的需求本身复杂多变，甚至存在模糊性，而信息流的单一流向又会导致某些严重问题直到产品发放到客户手中时才暴露出来，从而进一步加大产品研发的风险。

图4-8给出了串行开发方法的主要步骤。从图中可以看出，在后期的加工制造与测试阶段有比较多的错误信息反馈到确定工艺方案阶段，有频繁的错误信息反馈到早期的详细设计阶段。这些频繁的错误反馈是导致传统串行开发方法出现产品开发周期长和开发成本高的最主要原因。

并行工程就是要以流程为核心，打破原有职能界限和任务划分，尽可能将由不同职能部门的不同专业人员完成的工作集合起来，合成单一任务。通过对传统串行开发流程进行建模和优化，对产品开发过程中的活动进行删除、合并、重叠、增加和循环等改造，建立新的产品协同开发流程。

与一般的业务流程相比，并行工程中的流程优化还具有以下特点：

（1）重叠性：将产品开发过程中的概念设计、方案设计、详细设计、工艺规划、原型试制等阶段重叠进行。

（2）协同性：流程和活动的执行需要多学科、跨部门、全生命周期的协作。

（3）迭代性：在阶段性设计结果不满足产品需求和设计目标的情况下，需要重复执行某些活动序列，直至获得满意的结果。

（4）冲突性：在并行产品开发过程中，对同一个设计对象会有多学科人员参与决策，不同学科的人员有不同的指标和需求，对问题的解决方法也有不同的认识，因此，在决策过程中会存在大量的冲突，在这种情况下，要提高设计决策效率，必须制定和实施良好的冲突协调策略和冲突消解方法。

（5）时序性：并行工程中活动的排序对设计过程的性能会产生重要影响，因此，需要事先做好活动优化排序工作。

设计信息预发布机制（在设计工作的进展过程中，不断发布阶段设计结果）和多学科协同团队工作模式是早期发现和改正设计错误的核心方法。为此，需要在设计过程中建立许多小循环，对不同阶段的设计信息进行预发布，在面向制造的设计（DFM）、面向装配的设计（DFA）、快速原型制造（RPM）、计算机辅助工程（CAE）、计算机辅助工艺规划（CAPP）、计算机辅助工装系统设计（CAFD）、加工过程仿真（MPS）等多种软件工具的支持下，采用协同工作方式，对设计方案、详细设计、工艺方案等进行全面的评审，以保证设计方案的正确性，减少后期的修改。图4-9给出了并行工程模式下产品的开发流程。

与传统开发方法类似，并行工程方法也需要对产品的开发过程进行必要的分解，以降低大型产品开发过程的复杂性。开发过程分解包括两方面内容，一是指系统/子系统/子子系统的分解，通过子系统的分解使系统的开发可以分成部件和模块进行，简化系统的开发管理。子系统的分解必须客观和稳定，为了将系统分解为相对独立的几个子系统，在分解时，必须从系统的、对象的角度出发，将子系统看作是完成一定功能的且具有特定属性和行为的实体系统，各子系统通过功能驱动来组成整个系统结构；开发过程分解第二个方面内容是对某个子系统（或子项目）的开发活动的分解（活动分解）。活动分解思想是将子系统开发与其生命周期各阶段相对应，期望通过对活动的进一步分解，确定活动间的关系和约束，通过约束消解或者增加资源的方法尽可能使活动并行化，达到缩短开发时间的目的。

4.3.4 协作工具与环境

并行工程设计模式的运作需要基于信息技术的高效协作工具和环境的支持。图4-10给出了基于PDM的并行工程设计支持环境，它包括了过程控制、系统应用、应用支持和基础环境四个层次。

顶层是过程控制层。并行工程中围绕过程进行数据管理，过程决定了参与人员的组织方式、职责和权限、设备资源的分配、应用工具的使用以及何人应于什么时候向什么地方提交什么数据。因此最上层的过程控制是通过PDM系统的用户操作接口来调用可执行的设计过程和工具来实现的。

第二层是系统应用层。系统应用层面向不同的应用领域，完成不同的任务（如设计、装配、分析、工艺等）。该层是数据的产生器和接收器，通过PDM的应用开发接口，将不同的工具封装在对象管理框架中，从而实现应用工具与PDM系统的集成。

第三层为应用支持层。这一层是数据管理的核心，它一方面提供用户操作接口实现人员组织、产品结构和过程管理等定义和操作，另一方面还提供应用开发接口，使用户可以对PDM内部的产品数据对象模型进行修改和补充，实现产品结构管理和应用工具封装。PDM系统利用面向对象技术，把所有工业标准模型和用户化的模型（包括过程模型、数据模型、产品结构与配置管理模型、人员、应用工具等）放置于图形化的对象浏览器中进行统一管理，而且该层把网络、操作系统及数据库屏蔽起来，用户可以直观方便地对整个环境中的数据对象进行创建、删除、查询和修改，并建立各种对象之间的关系。

第四层为基础环境层。这一层包括操作系统、数据库以及网络，数据库主要对元数据（metadata）进行管理。

为了在PDM环境中对应用工具及其产生的数据进行直接跟踪与管理，要求将相关的应用工具集成到PDM框架中，包括对DFA、DFM、CAPP、CAFD、MPS等应用工具的集成。应用工具的功能集成分成三个层次，即工具封装、信息集成与应用集成。工具封装是指将CAx/DFx工具作为操作对象，利用API接口实现其在PDM系统内的管理，通过文件数据可以激活工具，工具产生的文件数据可以作为一个整体由PDM系统管理，但不直接管理文件内部的数据；而信息集成不仅实现应用系统或工具对文件的操作，还可以通过接口方式直接读取存放在PDM系统中的数据库记录，如BOM、零件属性等。应用集成则通过接口连接，形成更紧密的关系，实现PDM与应用系统之间的双向操作。这就要求应用系统与PDM系统都有很好的开放性。