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. 需求合规性 需求在法律合规性方面是否有风险。…