IPD变革成功的关键

正如产品开发项目的成败很大程度上取决于项目管理的能力一样，而IPD变革项目成功与否很大程度取决于对IPD变革项目的管理，以下十点供相关组织参考。

1、IPD咨询项目是公司级的变革项目，不是研发部门的流程项目，企业老板是IPD咨询项目的直接客户。

理解老板的真实需求是IPD变革项目取得成功的关键，顾问需要深度理解老板的战略意图、痛点和烦恼，帮助老板解决问题是IPD咨询顾问存在的唯一理由。

2、IPD咨询项目的成败和企业老板在变革项目中的价值观、态度和行为息息相关，更与咨询顾问如何引导并推动变革项目脱不了干系，IPD变革成功的思想基础是企业的文化与价值观，而往往是由企业领导人的价值观决定的。

3、企业某种意义上就是一条大船，老板在船头站着指导航向，众人在船边齐心协力用力划着浆。要想变革取得成功，光靠老板是不行的，一定要让众船夫有使命感、责任感，深度卷入变革。正式任命变革项目的领导组和核心团队，明确项目目标和职责，赋予团队使命感和紧迫感，将变革愿景和目标传递到每个成员，并以实际行动全身心地投入到变革项目中去。

4、IPD变革方案是否能解决企业的业务问题，往往来源于咨询顾问对企业的组织文化、业务模式、战略愿景与研发管理现状的调研和深度理解。问题的识别和精准把握决定了方案的有效性，而是否认同和达成共识决定了方案的可执行性。

5、咨询方和企业方在变革过程中是荣辱与共的战略合作关系，而不是甲乙双方的供应商/客户关系。变革团队唯一的目标就是共同解决阻碍企业战略目标达成的问题，实现企业的战略目标。变革的主体在于企业方，顾问是推动变革的主体。

6、变革项目团队是跨部门、跨公司的项目团队，如产品开发项目团队一样，取得高绩效团队必须是基于信任的团队，这种信任是建立在共同的价值观和文化，相互了解和信赖基础上的。作为变革团队也一样，团队必须树立共同的目标和愿景、相互信任、经常沟通，才能把工作做好。有些企业，核心团队成员很多都很陌生，发表观点和意见都遮遮掩掩，无法表达真实想法，这样的研讨输出的成果就很难真正达成共识，也无法有效落地。而有些企业就将可以将优秀的项目文化带入到变革项目中来，为了一些业务流程设计问题深入探讨，直到理解并解决之。咨询顾问作为变革团队中的教练、引导者和方法论贡献者和变革推动者，更需要熟悉团队成员的个人经历、性格特征、专业背景等，这样才有利于建立基于信任的合作伙伴关系，也利于推动变革方案的执行与落地。

7、领导层和执行层都需要建立正式和非正式的沟通机制，做到变革项目过程主动听取不同利益相关人的意见，将变革打成在战略和方法论引导下的“人民战争”。

8、项目阶段成果汇报会是展现变革进展与成果的关键里程碑节点，也是检验知识和技能、思维方式实现顾问和客户转移的重要方式。这个汇报项目团队成员要敢于“亮剑”，既锻炼了能力，又展现了风采，也是高层管理团队发现重点培养对象的舞台。

9、变革进展汇报材料可要围绕项目目标取得的进展和存在问题以及下一阶段的计划编写。汇报人可结合自身谈谈在变革项目中的成长、对IPD的理解以及对以后工作中如何采用变革思想开展工作。

10、贯彻“不惊讶原则”，项目开展过程中形成的决策结论应提前和利益相关人沟通听取意见，并经过开诚布公的讨论，最后形成结论。

基于IPD的产品质量管理理念与实践

语雀崩溃7小时，中国SaaS服务信任危机！

基于模型的协同设计技术应用

  1前言 　　航空产品研制是一项复杂系统工程，涉及多专业、多学科领域之间的协同。尤其是随着机械、电子、电气、流体等多学科领域在航空产品开发过程中的深入应用及跨地域、多厂所联合协同模式的推广[1]，传统相对独立、封闭的设计模式已经不足以应对市场的快速发展和快速响应用户需求。尤其在飞机产品反复迭代，不断创新的研制过程中，各个专业使用的设计、仿真分析工具种类繁多，这些工具软件产生的多源异构数据给专业之间带来了数据传递、共享困难。 另外飞机产品设计过程中由于专业设计知识、经验、流程、方法未固化，易随人员流动流失，不利于经验传承；尤其是飞机方案设计阶段由于仍采用传统的人工迭代计算和分析的方式，导致方案设计阶段飞机设计快速迭代效率低，给设计带来了极大的不便利。亟需要信息化手段实现这些成熟技术的集成化管理，通过固化重用的方式发挥其更大的价值。 本文提出的基于模型的协同设计技术，就是从系统工程正向设计角度出发，以固化知识、重用设计成熟技术为目标，剖析产品研发数据、流程以及与之相关的活动要素，梳理研发数据，提炼知识资源，以活动要素为核心，将影响活动的输入、输出数据、使能数据以及控制数据构建统一模型，通过集成研发平台完成这些模型的集成封装，来实现对模型的集成管理，实现设计知识和成熟技术的复用，完成飞机研发资源的重用和共享以及专业协同设计过程。 2现状分析 　　自2013年，国内外已经陆续开展类似基于模型的协同设计环境建设及技术研究工作，欧洲的空客公司以AIMS综合管理系统为基础，通过对全公司业务部门内部、跨部门、跨专业、跨国家、跨项目的流程重新定义和设计，形成了262个职能部门项目和8个跨部门合作项目，覆盖了空客公司的全部流程，实现了公司的整体协同。国内以航空工业为代表的中航商发，结合研发体系流程和研发集成平台，实现对发动机研制过程的任务、流程、软件工具、数据和相关联的工程数据库建设，实现发动机研发流程向数字化流程体系的升级以及发动机研制过程可控、可追溯以及研发方法可重用。航空工业一飞院在自主平台框架的基础上提出数据架构，通过大量二次开发，形成了目前以数据为主的总体协同设计系统。同时开发了大量的专业模块，实现了设计知识的有效积累。重用率达到了60%以上。该系统软件目前在一飞院已经经过了多型号、多机种的验证和应用。 总体来看，国内外企业基本上实现了对设计经验、规则、软件工具等研发数据资源的统一管理和重用，但是这些资源仍处在由不同系统分类管理阶段，设计文档、产品模型、参数数据、知识以及软件工具等仍分散在不同的系统中管理，尚未建立统一的研发数据模型，缺乏对研发数据资源的集成化管理。在研发数据资源共享与知识再利用方面，由于缺乏统一管理平台，使得这些知识、经验和方法的共享和重用受到极大的限制。 因而，目前飞机设计、分析、优化工作方式很难与当前的“设计问题越来越深入复杂、设计要求越来越高而设计周期越来越短”的新形势相适应。如何将孤立的专业软件工具集中管理，实现数据源的统一管理和专业间的数据共享；如何有效实现飞机产品研制过程中多专业数据源的流通和传递；如何实现飞机产品研制过程中总体、结构、强度等多专业的协同设计，成为企业信息化发展中亟待解决的首要问题。 3关键技术研究 　　基于模型的协同设计技术主要是将产品研制过程中各专业用到的知识（包括流程、方法、经验等）、模型、工具（CAD、CAE、EDA等）以及数据通过统一的表达方式集中管理起来，将其有机的进行集成封装，形成自包含的、可测试、可管理、可重用的软件体即知识组件，并将这些知识组件与产品研发流程构建关联模型，以此关联模型为核心，通过流程驱动，实现专业设计过程中基于统一数据模型的多专业间的数据传递和有效共享，从而实现专业之间并行协同设计。 3.1多源异构数据的统一建模技术研究 模型是对实际数据对象（如参数数据、文档、报告等）的一种描述，通过对数据结构的属性特征、动态定义，数据对象父子关系约束、数据映射以及数据展示形式的自定义等方式构建统一数据模型。通过数据模型实现对数据对象的数据组成、数据展现、数据之间的关系、数据的操作规则等的统一管理，如图1所示。 　　图1统一数据模型 3.2基于统一模型的研发流程建模技术研究 以统一数据模型为基础，研究基于统一数据模型的研发流程建模工具和方法，首先分析飞机产品研制各阶段飞机设计和分析流程和特点，梳理型号研制中工作单元对数据模型的需求，并将飞机设计过程中的最小工作单元作为一个工作项，构建统一研发活动模型（如图2所示），确定研发活动与经验、方法以及约束规则等研发知识资源、研发活动相关的输入、输出数据模型等的关联关系。 　　图2研发活动模型 以飞机产品研发活动模型为最小组件单元，构建统一流程模型，明确研发活动串、并行顺序，活动间执行的前提条件以及前后置关系等等，并将高内聚、标准化、能力集中的子流程或过程定义为模块化流程，实现研制流程的快速调用、变更和替换等等。流程实例模型,见图3。 　　图3统一流程模型 3.3基于模型的组件封装技术研究 组件封装是将产品研制过程中各专业用到的知识（包括流程、方法、规则、手册、经验等）、模型、工具（CAD、CAE、EDA等）以及研发数据通过接口有机的进行集成封装，形成知识组件模型（如图4所示），并将这些知识组件与产品研发流程构建关联模型。 　　图4知识组件封装 3.3.1不同专业软件工具集成接口开发技术研究 软件工具集成接口开发（如图5所示），一方面是将研发设计知识经验方法程序化的过程，把公式算法和约束规则通过各种程序代码（如Python语言、VBA等）打包成不同程序的接口组件，把工具软件封装成计算流程节点，通过输入、输出数据、接口组件以及流程节点有机的关联，形成可执行、可重用的知识组件模型。运行知识组件模型时，通过接口调用工具软件从系统中获得输入数据，通过流程节点进行计算后，把输出数据返回到系统中。整个运行过程对用户来讲工具软件也就是一个“黑盒”。 　　图5组件接口封装原理图 另一方面也是不同类型工具软件输出数据融合的过程，在飞机产品设计、分析过程中往往涉及到多个类别的数字化工具，工具间存在着数据传递，尤其是现有大量的设计分析工作过程中CAD和CAE产生的数据衔接很不通畅，CAD模型导入CAE软件后需要进行大量修补和整合操作，导致CAD—>CAE设计循环的效率十分低下。通过对程序接口组件的封装，实现CAD向CAE模型的自动化生成。一方面使平台的设计模板和分析模板规范化，另一方面增加了工具之间接口的匹配和相容性，以更好地实现设计分析一体化衔接，其融合过程如图6所示。 　　图6异构多源数据融合过程 3.3.2基于工具适配器的工具与流程模型关联技术研究 飞机设计过程中各个专业用到不同的软件工具，不同软件工具接口的二次开发语言也不尽相同，为了实现不同工具在设计流程中的传递，结合不同工具的二次开发接口使用不同语言的特点，引入了工具适配器。通过工具适配器将不同的工具与流程模板关联，实现流程在执行过程中对工具及工具中的数据进行自动调用和迭代（如图7所示），一方面避免了设计分析人员的大量重复工作，另一方面也是对知识的沉淀和积累，能够避免企业知识的流失。 另外通过工具适配器将不同工具中的接口调用语言和数据传递格式进行统一，并与流程中的数据传递进行配置和绑定，从而实现各工具之间的数据交互，打通不同工具中的数据在流程中传递的壁垒。 　　图7工具适配器 4技术应用案例 　　运用多源异构数据统一建模技术构建数据模型，运用研发流程构建技术构建活动模型及流程模型，运用组件封装技术集成封装知识组件模型，以这些模型为核心，将流程实例化任务，通过流程模型驱动，实现专业内以及专业间设计定义过程的自动化，实现专业间的数据传递、知识共享以及协同设计，具体详情见图8所示： 　　图8技术应用思路 4.1应用场景 集成总体、结构、强度专业设计组件，构建统一的专业集成研发平台，以某型机机翼方案设计为例针对总体结构强度专业（业务流程如下图），开展专业协同设计场景应用验证。 依托专业集成研发平台构建机翼方案设计研发流程模型，通过流程驱动，验证三个专业间任务的并行协同，同时以专业组件为牵引验证总体结构强度在数据传递的并行协同。具体应用场景如图9所示： 　　图9专业集成研发平台功能应用场景 4.2构建数据模型库 基于企业统一业务模型构建机翼外形参数库，见图10： 　　图10机翼外形参数模型库 界面设计主要是对输入、输出参数的前端展示，建立与参数模型库的关联关系，如图11所示。 　　图11机翼外形设计交互界面 4.3构建研发流程模型库 根据图12所示的总体、结构、强度专业机翼方案设计的业务流程，应用多源异构数据的统一建模技术构建研发流程模型，如图13所示。 　　图12总体结构强度专业业务流程 　　图13研发流程模型库 4.4构建知识组件模型 将机翼外形设计过程中不同环节所运用到的知识、经验、方法、公式算法等封装为不同的知识组件，确定组件与组件之间的输入输出数据传递关系以及控制逻辑节点、流程执行的顺序以及迭代机制，如图14所示： 　　图14机翼外形知识组件 4.5基于研发流程模型分解任务 研发流程模型逐级实例化为所计划、部门计划以及室计划，每级研发流程对应一条相应级别的计划，实例化后的计划继承任务模型中的属性信息，研发流程模型及计划分解的映射图如下； 　　图15基于流程模型的任务分解 4.6专业设计组件的调用 总体结构强度专业在执行任务的过程中通过组件调用，并行开展协同工作，其过程如图16所示：…

BOM管理

BOM（物料清单）是数字工程的一个重要组成部分，它是一份制造产品所需的所有流程和材料的清单。BOM管理对有效的生产和供应链管理至关重要。

– 文章信息 –

本文作者：Zhang Nicole。由「博世制造及工程服务中心」原创首发，数字化企业经授权发布。

记得有位专家曾经提出过一个观点，说BOM是工厂混乱的根源，该专家认为，如今绝大数企业没有对BOM管理有足够的重视，这导致了规划及生产过程中的种种问题。笔者也深表赞同，因为BOM是构成一个产品的所有子项目的材料清单，它包含在研发、规划及制造等过程中出现的所有流程，工艺，物料，产线及相关实体。笔者从近几年的实践中总结了一下BOM在数字工程中的一些基本应用场景：

1.PLM（产品生命周期管理）系统可以利用BOM进行专业的流程管理，可以有效提高企业的生产规划和执行等过程中的管理水平。

2.BOM可以作为制造过程数据管理的核心，它可以帮助组织研发，规划、制造等流程，同时也可以是PDM/ERP/MRP等信息系统中最重要的基础数据。

3.BOM是一种结构化的数据格式，表达了产品的材料组成、加工顺序和其他信息，可根据不同的应用场景进行配置。

在此前的“数字工程”专栏系列中已经介绍了PLM的基本功能，今天笔者就围绕西门子Teamcenter的功能来看看行业内的领先解决方案是如何玩转BOM管理的。

在Teamcenter中，可以存放管理各种文件以及各类BOM，仅BOM文件从类别上大致分为：

● 设计BOM(Engineering BOM，EBOM)

● 工艺BOM(Process Planning BOM，PPBOM)，

● 制造BOM(Manufacturing BOM，MBOM)，

● 资源BOM（Resource BOM，BOR），

● 质量BOM(Quality BOM，QBOM)

● 成本BOM(Cost BOM)等，

这么多类型的BOM都有其使用场景和应用领域。

那么问题来了，有了这些BOM以后我们能干什么呢？

其实，它大有可为！

首先，基于BOM管理实现从物料到产品的EBOM、PPBOM、MBOM的自动转换，因为现在很多BOM转换工作还是依赖工程师手动操作将物料发布到产品BOM。简单描述一下这个发布过程中：产品主数据在PLM组建并完成发布后（设计变更的流程），EBOM是由产品设计师根据他们的知识和专长手动完成的，它可以作为创建其他BOM的参考，如PPBOM和MBOM，制造和生产工程师可以用它来计划和执行生产过程。然而使用了基于BOM管理的系统后，一旦EBOM创建完成，后续的PPBOM、MBOM及生产过程等均可通过系统中的设定的转换规律实现自动转换。当然，如果担心自动转换存在风险，可在自动转换过程中添加必要的审核节点，通过在审核节点的双重确认完成BOM的转换。

另外，实现基于BOM管理的变更流程，可简化变更流程，降低变更风向，提升变更流程中的沟通效率。怎么理解呢？无产品不变更，变更是产品在生命周期过程中最为频繁且复杂的活动之一，因此，变更过程中往往出现各部门信息不对称，沟通不顺畅，执行不到位等问题，特别是跨部门业务衔接存在“灰色地带”，因此基于BOM的变更管理会显得尤为重要，通过先进的工作流程能力，设计变更可以追溯到产品生命周期中的所有相关的依赖关系和决定。在Teamcenter中，用户可以在一个预先配置好的工作流中发起、管理、审查、确认和执行产品变更。在产品的整个生命周期中，变更历史将保持与产品的关联，支持完全的可追溯性，就如下图中所示，不同工艺过程中的数据总能互相找到对应的链接。

最后，如果把产品的设计数据(包括EBOM，PPBOM，MBOM)视为单一的产品数据源，那么各种其它BOM文件（如资源BOM、质量BOM、成本BOM…）就可以看成这个单一数据源映射在生产规划，质量部门和财务部门成本管理等功能的视图，这句话看起来比较难懂，接下来我来举个例子：利用受管理制造物料清（MBOM）和工艺清单（BOP）来实现规划过程的线平衡概念–使用MPP提供时间管理和平衡工具，包括显示操作、工位和操作员的滚动时间，以及计划中的周期时间和等待时间，并通过对增值和非增值活动的可见性支持精益规划。

制造业公司往往容易忽略BOM管理对其制造过程的相关性，制造工程师对产品设计或者规划的影响也很有限，但是利用基于BOM管理为基础的数字工程解决方案，可以使你能够在一个集成的产品生命周期环境中管理研发，规划，制造，工艺，资源和工厂等信息，使各种BOM之间实现了无缝对接，快速响应。因此，研发工程师通过CAD工具完成的装配体，可以在制造过程正确地规划及执行，可以利用线平衡工具帮助你分析增值和非增值活动，还可以生成2D/3D工作指令，将装配步骤清晰地传达给车间，通过在一个工具中显示最相关的信息，能大大增强了你的生产力。

综上所述，如果你还没有使用这类基于BOM管理工具来实现工作流程，变更管理，规划及验证等方面的功能，那么正如开头说的“缺乏对BOM的管理可能工厂混乱的根源”。

基于PLM平台的项目管理实践

概述 对于项目管理，目前市面上有不少管理平台或软件，但基于PLM平台，以制造业的产品开发或研发为视角的项目管理平台较少，而且使用PLM平台进行目管理也鲜有赢得客户口碑的案例。有鉴于此，本文以甲乙双方不同人员的视角，试图复盘某企业的项目管理实施过程，分析从业务调研，技术实施乃至项目管理过程中的得失，以期抛砖引玉，促使后续其他项目能更为健康有序的实施。 1.项目背景 本期项目是PLM的二期工程，一期已经实现了基本的产品数据管理，具体完成内容如下： 　　1.Creo与Windchill集成，实现通过MCAD数据生成EBOM。 　　2.物料及各类图纸发布和变更流程。 　　3.数据查询，可通过字段进行常规数据查询，也支持通过Solr引擎进行模糊搜索。 　　4.产品库，文件夹结构，权限管理，实现基本的数据存放及取用。 　　5.物料取号，结合物料分类（和SAP）获取物料料号。 　　6.SAP集成，实现物料基本视图及产品结构（EBOM）向下游自动准确传递。 　　项目管理的几个先决因素 　　对于项目管理的实施，而且还是基于PLM平台的项目管理，需要甲乙双方步调一致。双方至少需要明确：这是一个中高层级的项目，要站在更高的角度，宏观的来看待。对于项目管理这类项目，应该要对下述问题进行正面回答： 　　1.平台给谁用 　　项目管理平台通常涉及的部门、人员非常广泛，那么如何回答这个问题才能最符合企业当下的实际情况？项目管理平台通常是企业第一次实施，此时最需要考虑得就是企业管理层面的需要。具体来讲涉及以下几点： 　　a)项目类型定义及划分 　　在项目管理实施初期，切忌求全思想。通常企业内部的项目有如下几种：产品开发（变型设计及订单交付）、产品预研（包括市场调查、竞品分析、工业设计等）、技术预研（这部分主要为超前技术研发，例如含WIFI功能的插座面板、多插座转换器等）、精益设计/生产项目等等。 　　通常，没有经过管理咨询的企业，其项目类型的定义及划分的边界是不清晰的，所以往往在实施过程中，会经历频繁的变动，在此建议甲方，在未经过实际实施及验证的情况下，不要贸然进行类型及划分的修改，应在有使用平台的经验后再进行调整。 　　b)项目交付物及齐套性检查 　　对于订单型交付项目，需要将产品研发过程中的交付物进行统一管理。部分企业为了避免相似问题的频繁发生，会考虑进行交付物的过程管理，所以需要进行项目交付物管理。这部分实施内容包括：交付物模板管理，交付物编号/版本管理，交付物的齐套性检查（按项目阶段），交付物变更管理等。 　　c)项目进度及基线管理 　　在企业领导层的日常管理中，常需要关注项目进度。当企业制定了年度战略目标后，就会根据目标并将其拆分给每个部门，并订立KPI考核基准。所以年度目标是否能完成，就势必依靠项目计划来进行统筹。考虑到各任务的难易度不同，每个项目也会给予不同的缓冲时间。所以项目实际总周期及项目预计总周期是PM及PMO都十分关注的重要信息。 　　d)项目变更及控制管理 　　项目执行时，会因各种情况（计划内或计划外）而导致项目周期、交付物、人员、费用、范围等发生变化。此时若对项目总周期或阶段周期有较大变化时，则必须要进行项目变更管理控制。但控制到何种程度？给予PM多大的自由则需要根据企业的实际情况进行斟酌。 　　e)资源负载均衡管理 　　目前企业常面临着骨干工作量过多的现象，具体表现为：只要有新的重大项目就需要技术骨干参与，新员工或者技术较弱的员工常处于“游离”状态，结果就是技术骨干随着资历增加工作忙碌程度也日益增加，且也时而发生多项目并行而顾此失彼的现象，出错也就在所难免了。所以企业急需一套行之有效的人员状态管理工具，以便于项目执行及新项目开发时，进行资源负载平衡。 　　f)项目报表管理 　　项目报表作为项目监控的主要依据，需要体现项目的实际情况。但对于企业，必须要选择合适的数据以避免失真的数据影响PM或者PMO的判断。所以除了要求用户使用系统，并从系统获取原始数据外，还需要制定适合当下的规章制度。让所有人在同一套制度下协同办公，这才是企业项目管理能获得成功的必要条件。 　　2.平台怎么用？平台使用目的是什么？ 　　只有在确定系统主要给哪些部门或者哪些角色用之后，才可以回答使用的方式及目的。其使用方式有：全手工，手工+系统，全系统3种方式。使用目的可根据企业自身情况分为：资源合理安排及交付物管理（侧重项目安排），进度及风险管控（侧重监控）以及全流程全要素协同（侧重协同）。 　　使用方式 　　三种模式的差异，并不一定意味着哪种模式最好。而是要根据企业当前的现状，结合项目类型进行选择及剪裁。 　　a)全手工 　　适用于企业成立时间较短，尚未形成稳定且统一的项目制度，难以提供出一套适用于所有项目相关部门的执行制度。 　　也适用于技术预研或产品预研类型的项目，对于未知领域，项目的执行不能完全按照WBS，需要根据每一个任务的实际情况进行手工微调。甚至当预研出现较大变化的时候，需要及时止损并暂停项目，归档项目执行过程中的所有交付物，以便后续条件合适时再重启。当然也有可能因为外部条件变化，导致项目永久关闭。 　　b)手工+系统 　　适用于企业已具备一定的项目制度，但因种种原因导致项目执行效率并不乐观，所以除系统按WBS执行时，还需要辅佐一定的人为干预，此类情况大多为临时性的，一旦企业理顺项目类型及进度任务关系，并适当修订规章制度后则可全部转为全系统执行。另外如果因为任务涉及核心技术或者交付物中涉及战略客户，则为了保障信息不被泄密，可以将核心信息暂存他处，并沿用手工+系统执行的方式。 　　c)全系统 　　适用于企业已制定较为完备的规章制度，且项目相关人员可以在此制度下默契执行项目。此类模式主要应用于成熟产品的改型设计及订单交付，很少适用于研发性质的项目。 　　使用目的 　　通常使用目的得根据主要使用部门来定，比如项目管理部作为主要使用部门，研发、工程、物流等部门为配套部门时，多以项目进度及交付物为主要管控目的，所以此时偏重于订单合规交付以及项目进度的纠偏。 　　若以研发、工程部门为主要使用部门，则多以项目质量为重。所以综合来看：当企业初具规模时，因各条件尚不具备，所以项目经理多以资源协调及交付物管理为重。当项目管理平台使用半年后，整体项目管理模式成熟及项目经理可以通过数字化平台纵览全局后，则能提升至项目进度监控及风险管控。此时项目经理会根据各成员执行情况进行干预甚至提前协调任务优先级，并管控订单交付或研发过程中的部分质量问题，此时WBS及交付物可能出现比前期更为频繁的变更，所以此阶段的各部门磨合期会持续较长时间。从PMO管理甚至企业战略的角度来看，企业高层在此时应更多的处理好部门及角色的职能边界问题，当岗位职能及执行策略都形成具体的“方法论”后，则进入至全流程全要素协同的状态（可参考IPD）。 2.解决方案 　　2.1 创建项目计划 　　分解复杂项目和方案成可管理的组件，在一个非常大的项目或者方案中，定义一个顶层结构，接着定义一级的活动计划和任务接受者，一级任务接受者可定义二级的活动计划，三级的依次类推。 　　1.WBS在项目立项阶段，其定义过程如下（包括前后事件关系）： 　　2.项目经理根据项目类型（ODM/OEM……etc.）通过模板创建项目； 　　3.系统支持将现有项目另存为新项目。 　　4.通过项目模板创建项目，同时项目经理将OA中关于项目立项的信息填写在创建的项目属性中； 　　5.由项目经理或者财务、产品经理完善项目相关的财务、采购等信息； 　　6.项目经理维护项目团队及其主要成员，例如各职能担当； 　　7.线下通知担当，由担当将项目过程中所需要的其他成员添加至团队中； 　　8.在项目启动前项目经理与各职能担当一起完善WBS，并针对具体的活动设置必要的交付物； 　　9.当项目经理及担当都完成WBS及交付物定义后，由项目经理做最终确认，并执行“启动”操作，至此立项阶段所有工作事项完成。 　　以企业某项目实例为例：…

生产和非生产性采购可以用一套系统吗？

PLM产品主数据应用的三个层级

PLM的核心应用：产品管理、产品主数据管理、项目管理、团队管理、上下游集成。 PLM产品主数据管理三个层级：物料层级、BOM层级、产品层级。 BOM层级是多数公司应用的层级。 PLM应用三个层级：产品主数据管理、研发项目管理、产品需求与主计划管理&生命周期管理。 产品BOM级主数据管理及研发项目管理，是绝大多数公司应用的层级。 以产品为核心的领域实施的内容与完整架构： 要想用得好，自己人的质量，决定了实施的质量、应用的质量！ 如果企业没有自己的规划能力，核心价值的识别与提炼能力，容易被乙方牵着鼻子走，是难以将PLM的核心价值体现出来，规划出来，应用起来的。 PLM整体应用的还算不错的企业，整体规划的架构逻辑非常清晰、本领域、上下游领域基本能全部打通，不仅仅研发领域的效率效果看得到，同时也能高效支持营销、制造、供应链，打通前后端的高效协同、可视化运营管理。任何时候随时打开PLM，查看任何产品全生命周期的各类运行管理状况，支撑公司的产品经营管理。 PLM平台能力不错可满足整体规划需求的产品，海外品牌有PTC Windchill，DS ENOVIA，国内的易立德PLM 是其中的佼佼者，为国产化替代提供更好的选择。 1）产品主数据管理。 对PLM系统，行业公司如果能把PDM产品数据管理用起来、用好，已经是非常不错了，这也是很多公司先上产品数据管理/PDM的原因。 从几个维度来看产品主数据的管理。 很多企业甚至很多乙方，都喜欢以BOM来讲产品主数据，要么以项目管理为主来讲述，这样表述很片面，没有把握PLM的核心架构、核心逻辑、核心价值。所以，很难获取甲方的认可、推行起来困难重重也就在所难免。 分享墨竹理解的什么是产品主数据管理，什么是PLM产品主数据管理方案与应用实例，项目管理与产品主数据之间的逻辑关系，产品与项目之间的逻辑关系。 产品与BOM是两个不同的概念，所涉及的内容与范畴决然不同。   A）产品维度： 产品主数据的整体管理体系： 产品主数据是个大的范畴，包含了产品管理团队与组织、产品数字化对象识别、对象定义、对象的业务规则、对象的上下游应用等。 如产品定义：从销售视角、生产视角、采购视角、研发视角、财务视角、产品线视角、客户视角、售后视角等定义产品，产品从生命周期起点至EOL终点的所有阶段、产出的数据，均以产品&产品编码为核心结构化管理。 含产品的定义、产品主数据的产生、审核发布、变更、EOL等；以及发布。 如产品发布： 如产品与产品团队发布至各业务系统的全业务链打通与协； 发布至CRM的产品、GTM材料、团队等； 发布至ERP的物料、BOM、发布至MES的工艺、生产资料； 发布至SRM的物料、打样生产图纸、变更认证数据等。 这些都是产品主数据的范畴。 以BOM为主的产品主数据管理定义，范围就窄很多，在这个框架内难以从更高的高度来规划出产品数据管理的整体核心架构和呈现核心价值。 B）BOM维度： 以BOM为核心，将物料&规格书&图纸&认证信息、BOM&设计图纸&工艺进行结构化的管理，在离散的数据以产品和项目维护进行输出后，自动以BOM形式进行归集、归档、结构化呈现。当这些数据以BOM成品料号为主键进行链接、汇聚、结构化呈现时，在过程管理、预警、交付件管理、变更控制（最容易出问题的地方），都能有很好的局部与全局的系统化管理。 对与ECAD集成、MCAD集成，能做到系统完全自动化对接的，实际上是非常困难，但也可有所作为。 主要如MCAD涉及两个系统之间属性定义的自动对接，差异太大，一个系统难以匹配其它系统；同时基础的工作及涉及环境的标准化，需要有专业人员的投入，这部分的标准化做不好，设计就难以用起来，这是与MCAD协同应用的2个难点。 ECAD配套器件标准化插件，对标准器件、封装等进行有效管理与维护，实现元器件、封装、图纸、原理图、BOM之间的联动与变更控制，将ECAD，PLM完整地整合使用，效果较好。BOM、物料、图纸包括可自动转化为PDF格式，自动传递至PLM；器件、原理图等任何变更时，可识别从器件到设计到封装到BOM的完整变更全过程的管理，这个就是整体规划与集成的优势。这个集成对器件标准化库的维护，同样是重要的基础工作，这块做不起来，与ECAD的集成就难以用好。 主要不足是替代料需要另行维护；如果是全局替代，系统可自动处理，但这类场景不多；更多还是需要按不同产品类型来分别进行认证（首先需要维护至BOM），这块的手工工作还是需要的。瑕不掩瑜，这也是核心价值的体现。 不同企业，根据自身特点，可以设计出设计BOM、工艺BOM、制造BOM、维护BOM，甚至超级BOM，按需推送至ERP、MES、SRM、CRM等。 C）以物料维度的全景图： 对PLM系统，行业公司如果能把PDM产品数据管理从产品维度、BOM维度、物料维度三个层级分别规划好、实施好，用起来、用好，已经是巨大成功，PLM核心价值就开始呈现出来了。 但对产品主数据的输出、组织形式、风险管理、预算成本管理、人力团队管理、计划进度管理、风险与质量管理、变更管理等，就需要通过项目管理的形式，将所有项目管理领域涉及内容、产品主数据涉及内容，进行综合的项目管理。 2）项目管理： 包括项目进度计划管理、资源管理、需求管理、风险管理、质量管理、变更管理、综合项目管理等。 从产品立项到产品生命周期维护这几个阶段，可以分为立项项目、研发项目、生命周期维护项目。如果流程再往前，还会有更多的项目如需求管理项目、创新解决方案项目等等。项目管理贯穿产品生命周期全过程。 对项目整体管理，可规划在PLM中进行管控，对需要敏捷开发的如软件版本持续迭代，可通过子系统进行管理与集成，如海外的Jira，国内的Ones、飞书等。如对软件生命周期ALM要求较高的，可引入专业的子系统进行管理。 对产品及硬件的需求管理，其评估评审、不同阶段的设计、开发、验证、发布等，在PLM中进行需求管理也是可以的。 质量与风险管理类似需求管理，可以在PLM系统一同管理，也可以通过专业的子系统来进行管理，视不同公司的规划与预算来决定。墨竹所经历的，两种模式都实践过，各有优势，整体架构规划好后，选择适宜的系统来落地即可。 项目计划管理这块，重点是做好计划的变更控制、基线管理；以及项目各阶段的交付输出过程与结果的可视化管理，提升管理的便捷度与容易度，这块规划实现的好，对系统的整体应用推广的助力很大。 对高层与管理层，特别是高层，必须有面向他们的主界面、功能与内容，否则系统上线，没有高层可看想看的，就会失望，就可想而知项目的实施效果了。 我们从功能模块维度、角色维度、产品经营维度看高层与管理层的关注点，如下图：  3）产品生命管理： 研发项目管理是产品生命周期中其中的一段，也是很多企业关注与投入最多的一段，常见的是弱前端（产品规划、需求至立项）、强中端（产品研发）、虚后端（生命周期运维）。 完整的产品管理往前延伸是产品立项、产品Charter、产品主计划管理、产品路标、产品创新解决方案、需求管理。这些都可以是以项目管理的模式，在PLM系统进行管理，打通IPD全流程。 企业越规模化、规范化发展，在产品前端的管控要更强、投入的资源更多，需求管理、创新方案、产品主计划与路标、转化率，需要更专业的人员来专职管理。 往后延展是生命周期维护，重点关注是产品转化率、营收、服务、产品成本管控、变更控制、产品退出的最佳时机点评估与决策、产品EOL管理等。在产品的BOM与人力投入成本管控、变更控制，物料与产品EOL管理方面，更是PLM的优势，也需要PLM进行有效管理。…

需求管理全过程流程图及各阶段要点

分析报告指出，多达76%的项目失败是因为差劲的需求管理，这个是项目失败的最主要原因，比落后的技术、进度失控或者混乱的变更管理还要关键。很多项目往往在开始的时候已经决定了失败，谜底就在谜面上，开始就注定的失败，你后面多努力都很难，注定背锅！ 很多PMO和项目经理却没有把需求管理重视起来，甚至认为这只是产品经理的事情，自己只做交付即可，俗话说：好的开始是成功的一半，一开始就没有管理好，注定为后续埋下了很多坑。 项目的全生命周期绝对不是到了需求给你才是项目管理的开始，而是从项目的开始有意向和萌芽开始的，越往前参与越深，你的价值就越大。 今天就分享给大家一个需求管理全过程流程图及详解，供大家参考！ 需求管理全过程管理详解–PMO前沿 阶段 检查项目 详细描述 需求输入 1. 来源可靠性 需求是否来自客户、市场调研、业务部门或其他正规渠道，是否有足够的依据和可靠性。 2. 充分和准确性 需求是否描述清楚，是否完整覆盖了所有有价值的需求信息，如需求的功能、性能、安全等等，是否准确无误。 3. 可行性和可实现性 需求是否能够实现，是否需要进一步的研究和分析，是否具有实现的可行性。 4. 普适性和标准合规性 需求是否符合相关标准和规范，是否是产品和服务可扩展的。 5. 目标性和实用性 需求是否符合产品和业务目标，是否具有实际价值和可用性。 6. 可跟踪性和可管理性 需求是否能够被有效地跟踪和管理，是否有足够的指标和标准来进行跟踪。 7. 优先级和紧急程度 需求是否具有优先级和紧急程度，是否需要进行排序和重点关注。 8. 规范性和记录整理 需求输入是否符合产品需求管理规范，是否有足够的模板和记录档案来支持验证和管理，以及整理形成完整的记录。 需求检查 1. 需求战略一致性 提出的需求是否符合产品定位和战略规划。 2. 需求体验性 需求是否可能造成客户/用户体验下降。 3. 需求冲突性 需求实现是否会对现有功能造成冲突。 4. 需求重复性 需求是否与已有需求存在重复或相似之处。 5. 规范性 需求数据格式、定义是否规范正确。 6. 需求可拆分性 需求是否可被拆分为多个子需求。 7. 需求合规性 需求在法律合规性方面是否有风险。…

基于MBD技术的产品全三维设计