根据国内当前的药品研发形势及未来发展走向，仿制药研发公司必须全面构建符合国内乃至国际（FDA）要求的规范性研发体系，确保研发项目的科学性、规范性和完整性，才能在动荡的医药变革中得以生存与长足发展。 一度对研究院的项目统筹与申报起到过关键作用。但是，随着近年来国家医药政策的频繁调整以及药品监管标准的迅速提升，迫切要求将项目管理部的工作职责进行“全面升级”，同时增加各个学科从业背景的管理人员，以进一步增强项目管理的深度与广度，规范药品研发流程，构建全面的药品研发质量管理体系，以适应行业发展。   一：项目管理的概念 项目： 是为创造独特产品、服务或成果而进行的临时性工 作。为了实现一个目标，我们形成一个组织，一起做出努力，并且在预算内 按时提供符合要求的产品、服务或成果。 项目管理：就是计划、组织、协调、领导并控制资源来完成项目目标。项目管理的过程就是制定计划，然后按照计划工作。 项目化管理： 把临时性的、具有明确目 标、预算和进度要求的复 杂任务，组织跨部门的团 队，按照项目的技术和方法进行管理。（未来目标） （1）项目管理三要素： 项目管理是西方的一个管理方式和方法。一提起项目管理，几乎看到的教材都是这么说：项目管理三要素“时间、成本、质量”。 1、时间：项目计划在什么时候完成？有哪些工作，分别在 什么时候完成？是否发生了延期？如果发生了延期如何处理？ 2、成本：项目计划花多少钱？每项“子任务”分别打算用多少钱（多少人月）来完成？是否发生了偏差？如果有偏差，怎么处理？ 3、质量：处方工艺可行性么？研发过程合规么？申报资料完整么？ （2）仿制药研发项目的特点： 1、独特性：不同的品种，或者同一API不同规格、不同剂型 2、明确的目标性：临床批件、生产批件 3、具体的时间计划：2年、3年、甚至更长 4、项目小组的临时性和开放性：不同项目，均是合成、制剂、分析、医学、注册等的不同组合！ 二：项目管理部工作职责 （1）科研管理架构： （2）科学委员会： 科学委员会研究院是研发策略的最高裁决机构。当项目遇到技术瓶颈和研发策略问题，各部门应 经由项目管理部将问题提交至科学委员会，组织科学委员会讨论。 （3）项目管理部工作职责 核心职责： 1、负责组织科学委员会根据法规政策的变化，不断完善仿制药研发流程和研发标准； 2、定期组织项目工作汇报，结合项目研发进程及时调整研发策略，力争做好每个项目的顶层设计与及时决策，让研发人员在正确的指引下开展工作。 具体内容： 三：项目管理体系 （1）仿制药研发流程： （1)建立目的： 根据《总局关于发布化学药品注册分类改革工作方案的公告》（2016 年第51 号）、《国家食品药品监督管理总局关于化学药生物等效性试验实行备案管理的公告号》（2015年257号）、《总局关于发布化学药品新注册分类申报资料要求（试行）的通告（2016年第80号）”等等一系列的法规要求，重新梳理研发流程，明确各部门研发内容。 （2）附件： 1、原料+制剂项目研发流程图 2、单制剂项目研发流程图 3、单原料项目研发流程图 （2）仿制药研发标准 （3)项目管理文件夹 l 建立目的：为保证各项目关键节点关键文件的完整性及统一性，便于项目研究资料的溯源，有效的开展项目管理工作，特建立此制度 l 文件夹形式：各部门根据项目管理部明确的关键节点，提供相应的验收文件，交由项目管理部备案，包括电子版、纸质版。 （4）验收节点&奖金分配 （5）项目小组制 为了提高工作效率，进行有效沟通与协作，保证项目开发进度，设立项目小组制。项目组长的项目管理工作由项目管理部协调管理 项目组长工作职责： 项目管理部根据项目成员的：工作经验、工作能力、综合素质等任命一位成员为项目组长。 项目小组工作制度：…

如何建立一套简单又高效的研发管理体系   对于一个研发管理体系，其核心是围绕着产品的整个生命周期来进行的。因此，根据一个产品的生命周期，可以把研发体系划分为几个关键的环节，如图所示： 可知，即时沟通和技术提升虽然不属于研发流程中的某一个环节，但它们是贯穿整个研发体系不可或缺的一部分，有着不可替代的作用。此外，任务管理需要对任务做整个研发生命周期的管理，除了作为其中的一个关键环节，也是贯穿整个研发流程的。 任务管理 任务管理是产品整个生命周期首要的环节，其对研发体系也是至关重要的。项目生命周期模型，传统的有五种：瀑布模型、原型模型、螺旋模型、增量模型、V模型，而现在最为流行的是迭代开发模型，敏捷开发则是采用迭代模型的一种典型项目管理方法集合。Scrum是目前敏捷开发中最为大家熟知的开发模式(XP极限编程也是一种比较常见的敏捷开发模式)，其开发流程的概览如下图所示： 简单来说，Scrum是依赖于三种角色、四种会议的自组织、信息透明化、成员平等的一种敏捷开发流程。更为详细的描述，可参见此篇文章：。 除了Scrum之外，看板是最近兴起的另一种开发模式，在最近很火的美剧《硅谷》里面“魔笛手”就是采用的这种方式。看板将工作流程形象化，首先把工作细分成任务并根据需要将任务分为Pending、Analysis、Development、Test、Deploy等状态，然后根据任务的进行，在几种状态之间进行转换。对比Scrum，看板使用开发周期作为计划和过程改进的度量数据，不强调迭代的概念，也没有很强的时间期间概念，也不需要制定任何团队角色。对于看板方法论的详细介绍可见此篇文章：，这篇则做了比较形象具体的说明。这里有一点需要注意，Scrum和看板并非是对立的，它们是可以结合起来使用的。使用看板来管理每一次迭代的任务是一种可取也是很常见的精益实践。 依赖于任务管理方法论，市面上很多软件都做了相应的支撑，自己曾经使用过的任务管理软件如下： : 这个是自己最开始接触的任务管理软件，使用也比较广泛。比较遗憾的是，redmine安装有点繁琐，而且基于ROR，如果需要二次开发，需要重新学习ROR。 : 这是一个任务管理云服务，界面设计的简单优雅，一目了然。很多小的私有项目，我都会用这个进行任务管理。类似的还有teambeation等。 : 这款软件是商业版的任务管理软件，对于这一块做的是非常专业的，很多大公司都在使用。但是，它是收费的。所以，如果你要用，要么付钱，要么去破解。。。 ：这款软件最早是叫做bugfree, 是开源且主要针对Bug管理的，后面慢慢发展成现在的集任务管理、bug管理、团队管理等的项目管理软件，并开启了收费策略。总体来说，功能很全，也比较专业，但是ui上有种传统it系统的感觉，流程上也不具有现在敏捷开发的一些优势。 : 是实现了Kanban方法论的任务管理软件。 对于个人的项目，其实依赖于tower.im这种第三方云服务完全足够了。如果担心数据安全的话，那么推荐在内网搭建Kanboard进行看板任务管理。 文档协作 研发中首当其冲的就是文档撰写，这个很多情况下都决定了项目的可维护、可管理性。有人会说现在流行的是敏捷开发，根本不需要写文档，但其实这是对敏捷的误解。敏捷开发强调的是快速试错、快速迭代，而非简单粗暴，对比传统开发模型虽然并不强调文档，但并不代表不需要。对于一个项目，从开始就需要需求文档、产品原型文档、项目进度文档等等，而到了研发这一步，在系统实现、写代码之前最好的就是先“想”再做，而“想”的一种比较好的输出形式就是文档。对于一个软件系统，一般来说需要写的文档有以下几种： 系统业务流程文档：描述系统业务逻辑的文档，能清晰的说明真个业务的流程。 系统架构设计文档：对整个系统的架构的描述，需要包含系统的各个关键组成模块以及相关的各个关键技术点等。 系统功能模块概要设计/详细设计文档：对于某一个模块的流程、逻辑的描述。 数据DDL/DML文档: 与系统相关的数据库的DDL和DML文档，对于前者，是需要包含所有的操作的，而对于后者，必不可少的是查询语句，用来提供给DBA，来做查询sql的review，以保证索引的正确建立等。 系统部署文档：描述系统关键部分部署在哪里，需要做哪些配置。 尤其对于一些相对复杂的功能来说，整理思路形成文档，不仅可以让自己逻辑清晰，也能让后续维护的人更快的接手下去。 而对于文档撰写协作的方式，我自己经历过的有以下几种： 使用word撰写各种文档，提交到svn等版本管理工具上 使用google doc进行协作 使用word撰写文档，然后提交到项目管理软件中进行管理 使用markdown撰写文档，提交到版本管理工具上 我自己比较推崇的是使用markdown撰写文档，然后使用git、svn版本管理工具或者是其他团队协作工具做版本管理。之所以使用markdown, 能够极大地节省使用word时调各种格式、样式耗费的时间。对于程序员来说真的是如虎添翼。如果是对文档多人协同编辑有刚需的团队，可以选择使用google doc或者国内的石墨()。 此外，在移动app开发中，还有一个非常关键的文档就是api文档，是服务端提供给客户端调用接口的说明文档。比较简单直接的方法就是定制一套api文档模板，然后在写接口代码之前或者之后，按照模板编写接口文档。此外，可以实现一套根据源码自动生成文档的机制，在代码编写的同时就能自动生成相应的接口说明文档。在使用Spring MVC开发的后端应用中，个人推荐，使用此项目能够通过在Controller中加入相应的注解信息从而自动生成Api接口文档，同时也提供了在线调试的功能，极大减少了api文档的工作量。 代码协作 对于一个技术团队，最最关键的肯定是写代码。一个人单打独斗那倒好说，但是这就像篮球场上，一对一靠个人硬实力，但是5对5，那就不仅仅是一个人实力强就赢得了的了。因此对于技术团队来说，代码协作是至关重要的一个部分。 代码版本管理：Git + SVN 几年前最流行的代码版本管理工具是svn（当然此前，更加古老的还有cvs之流），的确为程序员们的代码管理带来了很多便捷。但到了现在，相比起这种集中式代码管理，目前最为火热的当属git这种分布式代码管理工具，在Linux上直接搭建git服务器来构建项目的git系统的。而这几年随着Github以及类似系统的涌现，对于很多私人项目我都是采用oschina或者gitcafe提供的git私有代码管理来做代码版本管理的。当然，对于公司来说，有很多开源类github系统可以搭建在企业内网。详细的可以参见：。当然，对比svn，git也是有缺点的。无法天然的支持对于目录级别的权限管理和基于目录的版本管理操作是目前不得不结合svn和git一起使用的重要原因。通常情况下，可以使用git做版本管理，辅以svn做基于目录级别的发布包管理。 代码分支/Tag管理： Git Flow 其实分支/Tag管理是代码版本管理包含的内容，之所以单独出来，是因为对于分支的使用其实还是有一定的原则和技巧的。并非如很多人一样，所有项目就一个master分支，所有修改都往这里塞。目前，最为流行的一种基于分支的工作方式就是:Git flow。介绍可以见: 。简单概括就是： 用于开发新功能时所使用的feature分支； 用于辅助版本发布的release分支； 用于修正生产代码中的缺陷的hotfix分支。…

林氏木业行业“数字化天花板”再次加固，PLM系统重磅上线 　　对于当下的中国制造业而言,利用数字化管理产品开发已经成为了企业的首要选择。数字化的应用无论是对企业产品力的锻造还是服务质量的提升,都发展有着非常重要的意义。而数字化的运用对于林氏木业来说更是早已驾轻就熟的事情——正是凭借着对于数字化技术的纯熟应用,林氏木业才能够在拥有行业数字化天花板的地位,才能从激烈的家居品牌竞争中脱颖而出。 　　说起数字化管理,PLM系统就是一个热度极高的项目。PLM,全称商品研发管理系统,其最大的应用就在于统筹协调企业内部从设计、开发,到采购、制造等各个部分,将单兵作战的模块连接为一个完整作战的军团,从而实现产品研发的高效协同。 　　而就在去年年底,林氏木业已经成功上线了PLM系统,这不仅意味着林氏木业行业数字化天花板的地位再一次加固,更能代表林氏木业已经建立起了统一的产品研发设计工艺协同及研发项目管控平台,走向产品研供信息化的新时代。 PLM系统从高精尖的制造领域走来,下沉到家居领域尚属罕见。作为全行业最早一波“吃螃蟹”的企业,林氏木业对于PLM系统的理解非常深。在家居产品品类与数量呈现爆炸性增长的当下,像林氏木业这样以互联网起家、以全品类、全风格著称的品牌的发展亟待全新的管理流程。而且,在材料工艺和制造方式发生极大改变的当下,只有保证设计师、产品开发、生产团队都能够全面及时掌握产品各个方面的信息,才能够保证产品上新的速度与市场竞争力。此外,出于提升效率方面的考量,林氏木业也非常需要能够显著提升效率的PLM系统的加持。 　　林氏木业素来以效率而闻名,依靠科学与高效的PLM系统,林氏木业将实现在产品研发上再次快人一步,其服务市场的能力势必将得到进一步的飞跃!

什么是“不平衡报价”？ 评标委员会是怎么来判断标投人的报标报价有没有进行了不平衡报价？ 先来说说什么是“不平衡报价”。 不平衡报价通常指的是在工程的招投标阶段，总价基本确定后，通过调整某个子项的报价，在不影响中标的情况下，确保在结算时能够获得理想的经济收益。 在实践中，常见的方法大致有以下几种，分别是： 1、提高前期所发生的分部分项工程费或措施项目单价，降低后期实施的项目单价； 2、提高可预计工程量增加项目的单价，降低可预计工程量下降的项目单价； 3、提高招标文件中需求不明确、图纸表达不完整、工程量清单描述不清晰，预计实际工程量比招标文件工程量清单多的项目单价； 4、对于实施周期较长、工程量较大的项目，提高资源占用较多的项目单价，而降低物价涨幅大的项目单价。 昨天给大家分享的案例是个例外，施工单位现场踏勘，根据自己丰富的工程技术经验，发现设计单位所采用的基础做法并不适合当地的地质条件，预计今后基础形式必定要被否定，聪明地把基础部分的综合单价调低，而调高了上部主体结构或其他分部分项工程的综合单价，确保中标后，在工程实施过程中采用设计变更，对原设计图的基础部分全盘否定，从而获得了较大的利润。 无论是哪一种情况的不平衡报价，对于建设单位来说，均会带来投资目标的偏差，从而在项目的整个目标体系实现过程中，带来较大的不确定性。故而，建设单位在招标过程中应着重加以识别。 当然了！实际的评标工作并不是由建设单位来完成，而是评标委员会。那在评标时，评标委员又是怎么来识别不平衡报价的呢？ 因为我个人并不擅长评标，于是我请教了我的一位朋友，他精通此道，为此我还奉献出了一瓶价值不菲的好酒…… 在评标委员会评标时，通常会从措施项目总价和招标控制价的分部分项工程量清单综合单价，两个方面入手评判标投人是否存在不平衡报价。 1、措施项目的不平衡报价 当投标人措施项目（除安全文明施工费用）总价低于或高于招标控制价15%-25%时，可视为措施项目不平衡报价；（若措施项目费用占工程总造价比例较大，可适当调整增加比例值，建设单位通常也在招标文件中给予说明） 2、分部分项工程量清单综合单价项目的不平衡报价，这里分为两种情况： （1）投标人的某个分部分项工程量清单项目综合单价高于或低于招标控制价对应项目综合单价一定比例的时候（具体比例，建设单位可在招标文件中说明，如15%-25%），该项目报价可视为不平衡报价。 （2）当投标人所报的综合单价与投标人拟采用的施工方式方法有关联时，如果投标人的综合单价低于或高于招标控制价对应的综合单价达到一定比例（具体比例，建设单位在招标文件中应给予说明，如20%-30%）时，是否判断为不平衡报价，分为三种情况： ①投标人在投标报价中并未明确做出说明或其说明理由明显不合理的，视为不平衡报价； ②投标人在其施工组织设计中没有编制相应的施工方式方法，施工组织设计评审未否决其投标的，视为不平衡报价； ③综合单价的组成与其施工组织设计内容不对应或其报价经评审后认为其综合单价组成不合理的，视为不平衡报价。 综合1、2两点，通过计算，得出投标人不平衡报价项目的具体金额。 即：不平衡报价项目金额=∑（确定为不平衡报价的分部分项综合单价项目*对应工程量）+确定为不平衡报价的措施项目总价 当投标人不平衡报价项目的金额数量超过经最终修正后的投标总报价一定比例（具体比例由建设单位在招标文件中明确）时，评标委员会否决其投标。 如果没有超过，评标委员会则会在评标报告中记录，提醒建设单位签订合同时给予注意。 工程项目管理软件（EPC、业主甲方、工程ERP系统） – 【华腾】领先专业项目管理软件商-工程施工、科研研发、基建投资大数据项目管理系统平台。

引言 笔者近年来参与了汽车主机厂及零部件企业大小十几个企业级BOM项目的实施工作。无论是运营多年产品线丰富的企业、新能源造车新势力还是汽车零部件企业，对于BOM管理的诉求最终都能总结为一句话：BOM不准，有什么解决办法？ 看上去很简单直接的一个问题，但却不是一两句话就可以回答清楚的。而要制定行之有效的解决方案，首先就要精准地识别出导致BOM不准的根本原因是什么，即识别出影响BOM准确率的因素。 2 BOM准确率影响因素分析 在分析BOM准确率的影响因素之前，首先要解决的一个问题，就是何为“BOM不准”？在产品生命周期之内，BOM是一个动态的数据，一直都在发生变化，那么对于一个产品来讲，BOM不准可以概括为两个方面：一是对产品的定义不准、二是生效时间不准。 产品定义的不准，从配置角度看可能是配置定义的错误，如单一产品配置互斥、上下游配置定义不一致等等。从零件角度看可能是零件信息错误，零件基本属性、数模图纸编号、版本、特殊标识等错误。 从BOM角度可能是构成BOM的零件数量、BOM结构、零件用法、供货方式等错误，也可能是一个产品不同管理形态的BOM单独管理且无法关联匹配，这些错误的直接体现就是一个确定的产品配置定义在各应用领域都没有一个准确的BOM数据与之相匹配。 生效时间不准，主要是产品定义或设计变更在不同管理形态的BOM中采用时间的不准确，如断点在BOM上的时间与实际执行的时间不匹配。这些BOM的错误，在工艺制造、物料管控、成本核算、售后维修等业务领域都会带来较大的问题。 另外，无论何种BOM管理模式、BOM数据是集中管理还是分散管理、业务链上有多少管理形态的BOM数据，以及有BOM系统管理还是线下管理，BOM准确率首先是一个业务问题。 因此分析影响BOM准确率的因素，本文仅从业务角度出发，各方面影响因素总体归类为BOM架构和BOM管理方式两大类，以此展开分析。 2.1BOM架构设计不合理 第一，不同BOM管理形态的异构管理，容易带来BOM管理工作量大、BOM管理效率低下等一系列问题，这些问题都会在日常BOM管理中影响到BOM的准确率。 最常见的是EBOM和MBOM之间的异构管理，这种管理方式在国内制造企业占有很大比重，造成这种问题最根本的原因在于CAD设计结构和EBOM的同质化管理，且大多为EBOM向CAD设计结构上靠。 这种管理方式的优劣此文不做赘述，然而就BOM管理而言，这样一来，EBOM的结构必然不能满足对各业务领域（包括成本、采购、制造、售后等）的协同要求。 在超级BOM组织模式下，BOM重构的复杂度比精确BOM要大得多。如果BOM管理是一次性的数据构建工作，这点复杂度倒是不算什么。 但是对于制造业尤其是国内汽车制造企业，相当比重的企业产品开发管理的成熟度不高，在设计工程发布之后仍然会产生大量的工程变更，一直贯穿整个产品生命周期。在这种业务背景下，不同BOM管理形态的异构管理会给BOM准确性的保障带来巨大的困难。 第二，BOM管理单元设定与业务成熟度不匹配带来的BOM准确性问题。 超级BOM是产品配置丰富之后必然要采取的BOM管理模式，是随着业务管理水平的逐步提升水到渠成的事情。国内车企起步较晚，平台化的开发模式成熟度不高、模块化开发更是处于摸索阶段，因此产品型谱的划分缺乏合理的技术支撑，这就对BOM管理单元的确定带来一定的困扰。 有些企业BOM管理单元设计过大，又没有与之相匹配的管理水平来支撑，导致超级BOM数据管理混乱，准确率较低。有些企业BOM管理单元设计过小，这种情况在采用强项目管理产品开发模式的企业普遍存在，平台化程度低且产品数量多，结果就是BOM的数量非常庞大。 在发生变更时要确保变更对所有相关产品的影响都能考虑验证到，是一个很花功夫的事情，如果管理不到位，各车型之间的重用度会越来越小，带来的问题不只是BOM的准确率低，整车成本也会不断升高，直接影响企业受益。 最后，BOM的管理形态和应用形态划分不清，BOM管理主线不清晰，容易导致全业务链BOM管理的混乱。 直接体现就是一个产品在不同业务领域都有各自的BOM数据，且各个BOM数据独立管理各自为政，导致全业务链BOM数据割裂，BOM数据流转极为不畅。 例如有些企业一旦产生BOM应用需求，就编制一个BOM进行管理，导致一个产品存在CAD_BOM、早期BOM、EBOM、采购BOM、试制BOM、工艺BOM、制造BOM、订单BOM、售后服务BOM、KD_BOM、成本BOM、重量BOM等等一大堆BOM形态，各BOM形态之间缺乏有效的数据同步机制，BOM数据的准确率无法得到保证。 产生这些问题主要是因为缺乏面向全业务链的BOM总体设计，BOM作用与形态未理清。因此，在BOM的总体设计上，要遵循面向Dfx的BOM管理思路，首先应分清主线的管理形态BOM如EBOM、MBOM、SBOM，应用形态BOM如采购BOM、成本BOM、重量BOM等，理清各BOM之间数据关系。 不能狭隘的将BOM的作用仅仅局限在满足个别业务应用上，例如EBOM数据不能仅站在产品设计思维角度进行管理，而是要将其定位为面向产品开发同步工程的数据桥梁，既承载产品设计的关键信息，又要支持同步工程范围内各业务的实际需求及关键信息承载，并最终面向制造、售后等业务进行发布。 2.2管理方式不合理 第一，BOM业务管理流程、规范的缺失，会导致BOM在全业务链的混乱，就更不要谈BOM的准确性了。 总体来看，各管理形态的BOM业务输入、输出不明确，BOM应用对象不固定，BOM的初始化及发布时点自由随意，不同阶段BOM变更处理不合理，缺少必要的BOM管理校验规范，缺少严谨的BOM问题反馈处理机制等等，均会导致BOM数据错误。 这种混乱的管理局面如果不扭转，再优秀的设计和产品开发能力，也会因为管理问题无法最有效的转化为精益的生产制造。从各个业务点上看，零件换号原则不考虑下游执行需求，零件配置条件不规范、零件信息或BOM信息的受控方式及受控范围不明确等等，均会导致BOM准确率低下。 第二，BOM管理职责划分不合理，也会影响BOM的管理质量。 首先，BOM数据分散管理且无整体监管的机制作为保障。在这种情况下，BOM管理规范很难执行到位，缺乏统一的数据完整性的监控，很容易造成BOM数据在各专业系统之间协同差、数据交叉重复或者缺漏数据。另外，BOM数据的分散管理，很难制定行之有效的KPI管理指标来监督BOM管理者的工作质量。 其次，如果BOM管理职责划分不合理，会导致沟通效率低下从而影响BOM的准确率。以售后领域为例，SBOM作为售后开展的数据来源，行业最佳实践是在研发领域设置售后工程部门管理SBOM、售后图册等相关售后业务，并能很好的在开发过程中与设计部门一起开展同步工程，在开发过程中与设计部门一起确定售后可维修性及售后维修策略如售后拆分等等，并且在先期定点的过程中就一并考虑到售后备件需求。 但是如果SBOM的管理职责设置在销售部门，行业实践证明，在流程体系不够成熟或者执行力不够的企业，这种管理方式只会造成售后与研发交流不畅、SBOM与EBOM的数据断层、拆分备件采购定点困难、工程变更售后难以执行等等一系列问题。 第三，产品配置管理与BOM管理各自为政，两条线平行管理，无法有效的进行数据协同，尤其是在超级BOM管理模式下，这种管理方式对BOM数据质量而言是致命的。 产品型谱和配置都是针对整车级的产品定义，直接决定了BOM的组织形式，而BOM数据定义的是对产品配置的开发实现，如果二者数据不匹配，就无法从超级BOM获取精准的车型BOM定义，对整个产品开发、生产制造、售后各个领域的业务活动带来影响，尤其是对于强依赖于精确BOM的业务活动如工程验证、工艺设计及验证、生产制造、MRP、物料配送及反冲、成本核算等等，都带来巨大的影响，甚至会直接导致下游个别业务无法开展。 最后，变更管理不到位，会导致BOM准确率低。缺乏严谨的变更管控机制，导致变更管理和BOM更改脱节。 部分企业新产品开发前期对市场需求的调研不充分、开发质量又不高，在工程发布之后仍然会产生大量的配置调整以及影响到产品质量的工程变更，同时因为降成本等因素也会产生大量的工程变更、多点供应商开发等等。 如此频繁的工程变更，如果在变更在流程管控上与BOM更改管理上协同不到位，即变更和BOM两条线管理，使BOM的更改缺乏有效的监控，BOM数据的准确性全靠设计人员或BOM工程师的工作自觉来保证，这种管理方式下BOM准确率低是难以避免的。变更执行不到位，会导致全业务链BOM准确率的降低。 研发、制造和售后各自的业务特性，必然带来EBOM、MBOM和SBOM之间在产品定义和生效性控制上存在必然的管理差异，如MBOM与EBOM之间生产生效性和工程生效性之间的差异、SBOM与EBOM之间售后配件定义与工程定义之间的差异、SBOM与EBOM之间售后生效性和工程生效性的差异、SBOM与MBOM之间售后生效性和制造生效性的差异。 基于此，如果在产生工程变更之后，在变更执行端管理不到位，逐步会导致EBOM、MBOM、SBOM三大BOM数据脱节，一致性差。 临时变更随意发起且未闭环管理，会导致MBOM与EBOM差异越来越大。临时变更是必须有时效性的，且在正常的生产运营中是应该尽量避免，临时变更使用范围的定义应该清晰明确，临时变更执行应该最为严格。 但是有部分企业的临时变更包含的范围极大，除了正式的工程变更之外的所有业务场景，都可以基于临时变更来解决问题，例如生产端的物料临时替代、来不及走正式变更的紧急变更、质量让步放行、零件偏差许可、工艺临时替代等等，均采用临时变更流程进行管控。 从管理设计上来看，这种方式并不是不可行，但是在管理执行环节，这种万金油一样的设计，会随着执行惰性的不断累积而人为的制造出许多管理漏洞。 最为严重的情况是，不断的用临时变更来代替工程的紧急变更流程，而本该发起的正式变更未发起或发起后管控不到位，久而久之带来的后果就是产品数据、BOM数据混乱不堪，谁也搞不清楚什么应该是正确的产品设计、甚至连售后应该用什么状态的零件来维修都查询困难。 所以，临时变更的管理，首先要确定适用范围，其次要闭环管理。闭环的不仅包括物料临时替代的切回，也包含上述正式变更的发起和执行，当然从业内最佳实践来看，紧急的工程变更也应该走工程变更流程，可以视业务情况加快某些流转环节，而不是采用临时变更流程来提高审批和执行效率。 另外，还存在一些人为的因素导致的BOM准确率低，如零部件设计变更不遵循换号原则、数据维护错误、数据流转中的错误等等，均会影响到BOM的准确率。这就需要各企业在加强业务人员专业培训之外，更应该建立起完善、有效的变更管理、数据维护和发布的检查审核机制，并结合业务现状制定合理的KPI指标以确保BOM数据在全业务链的准确率保持在合理水平。 以上从两个维度多个方面对国内制造企业普遍存在的影响BOM准确性的因素做了简单的汇总和分析。对于一些共性问题，希望对大家在BOM问题诊断时带来一些参考作用。 有些因素本身并不是导致BOM准确性差的充要条件和直接原因，而是在特定业务背景下如是管理会带来BOM准确性差的问题，例如不同管理形态BOM的异构管理，等等。 以上分析的结果，也不一定对所有企业都适用，不同企业所面临的BOM准确性的问题需要具体情况具体分析，相同的管理方式在不同的业务背景下，可能会带来截然不同的管理效果，因此不能忽视业务背景而直接套用。 3 结语 发现问题并精准识别问题的根本原因，才能针对问题制定相应的解决方案。 BOM业务管理模式在每一个企业都有自身的特点，问题产生的背景复杂，职责分工也不尽相同，要有效的解决BOM问题，就需要展开深入的业务调研，向下具体入微的梳理痛点问题，向上从全业务链出发进行总体设计，并经过反复验证才能给出有针对性的解决方案。 概括来说，就是在进行BOM问题分析诊断时，要举轻若重，小问题要重视；在制定BOM解决方案时要举重若轻，做好全局设计，不能只着眼在一个点上，做到治标先要治本，才能真正的解决问题。…

一、前言 近年来，随着云计算、大数据、人工智能（AI）、边缘计算、第五代移动通信（5G）、区块链等信息技术的蓬勃发展，新的生产方式、组织方式、商业模式不断涌现；世界正处于工业经济向数字经济加速转型的过渡期，以数字经济为核心的产业融合发展成为趋势。工业信息化是数字经济与工业融合的典型代表，依赖工业软件的发展革新。 工业软件作为工业 4.0 时代实现智能制造的关键要素，是实现工业企业数字化、智能化转型升级的核心与“灵魂”，迎来了空前的发展机遇。工业软件成为具有工业品意义的“软零件、软部件、软机器”，是不可或缺的工业软装备。在工业企业中，依靠工业软件提升产品价值、降低制造成本、提高核心竞争力，是“两化融合”的切入点和突破口，对推进工业结构调整与产业升级、保持经济平稳较快发展具有重要意义。 工业软件指在工业领域设计、生产、管理等环节应用的软件，可划分为系统软件、应用软件以及介于两者之间的中间件；具体发展主要分为三阶段：软件本身的发展阶段；软件的协同应用阶段，重在业务流程的串通与优化；“工业云”阶段，不再是单一软件，而是集成多类功能并提供“软件 +服务”整体解决方案。目前，工业软件一体化是主流趋势，通过技术手段将若干个相互独立的工业软件以横向或纵向的方式进行集成，实现工业软件的异构数据互通、企业协同优化、产业链资源配置。 工业软件广泛应用于工业生产的各个环节，伴随着产品从研发到生产再到销售及售后服务的全生命周期。世界工业软件市场发展平稳，2019 年产值约为4100 亿美元。我国工业体系规模庞大，加之正在从制造大国向制造强国转变，使得工业软件成为亟需且应用范围和深度在不断扩大；2016—2019 年，我国工业软件产品收入年复合增长率为 16%，超过世界平均水平；2019 年工业软件产品收入达1720 亿元。 在新基建、双循环的背景下，产业数字化将助推工业软件一体化的快速发展；与其他新基建要素加速融合，形成产业链上完整的工业互联网，补齐工业企业短板，加速数字化、智能化转型。 随着工业互联网平台的快速兴起和应用推广，工业互联网标识解析与工业软件一体化成为驱动行业创新发展的重要动力，赋予智能制造更为丰富的内涵特征和应用场景。面对工业互联网发展的显著趋势与迫切挑战，本文针对工业软件一体化与标识解析路径展开研究，分析应用需求、梳理发展现状、剖析面临问题，提出新技术思路、论证新技术架构、提出发展建议，以期为工业软件行业高质量发展提供基础参考。 二、工业软件一体化需求分析 工业软件服务于工业流程中的特殊环节，需要通过数据集成来覆盖产品全生命周期的各类应用。工业软件围绕产品、生产、业务三大主线部署应用，每款工业软件可能只适用于单一的业务环节（见图 1）。 图 1 工业软件业务场景 工业软件主要分为设计研发类工业软件，如计算机辅助设计（CAD）、计算机辅助工程（CAE）、计算机辅助制造（CAM）、计算机辅助工艺（CAPP）等；信息管理类工业软件，如产品生命周期管理（PLM）、企业资源计划（ERP）、生产执行系统（MES）等；工业控制类工业软件，如数据采集与监视控制系统（SCADA）、可编程逻辑控制单元（PLC）等。在工业产品的全生命周期内，需要多类工业软件的协同合作，因而跨软件的数据互操作极为重要。 （一）宏观需求 工业软件的信息孤岛现象严重阻碍了企业数字化转型。一个工业产品在其全生命周期中可能涉及跨功能、跨学科、跨品牌的多种工业软件，相应的底层逻辑、数据格式、应用场景区别明显；在一个完整的工业流程中，研发设计、生产控制、信息管理等工业软件，其数据、指令、信号的传递层层受阻，导致生产链条难以实现有效承接。 ①研发设计类工业软件侧重于基础学科，覆盖产品的研发设计阶段，工具属性明显；②生产控制类工业软件侧重于产品生产的流程和工艺，工程属性明显；③信息管理类工业软件侧重于企业的业务管理与业务模型，管理属性明显。这些工业软件由不同厂商提供，服务于不同业务、涉及多种学科，加之各软件之间没有集成，造成企业在各个业务环节存在多个信息孤岛，影响了产品的设计迭代周期、质量追溯效果、供应链金融效率。 目前，国内外工业软件厂商、工业企业积极关注工业软件的一体化集成，追求各工业软件的数据无缝地在设计生产流程中双向传递。发达国家率先建立了相对完整而又特色鲜明的工业体系，依托信息技术进步实施了工业软件一体化建设。相比之下我国的行业发展存在差距，可能制约制造强国建设进程。因此，随着我国智能制造能力的稳步提升，推动工业软件一体化是完善并强化工业体系的迫切需求。工业软件一体化集成既可保障智能制造、高端制造发展，加速工业互联网的广泛落地应用，也可提高工业软件的行业渗透率，形成良好的规模效应和协同优势。 （二）技术需求 产业链协同是工业的发展趋势，也是企业数字化转型的终极目标之一。而在当前，实现产业链协同对工业软件的要求极为苛刻，要么只能使用指定的软件，要么需要高昂的对接成本（多数情况下也只能实现指定的功能），收益率极低。工业互联网协同制造在以下方面对工业软件一体化提出了技术需求。 1. 缩短产品设计生产的迭代时间 异构 PDM 之间的产品信息获取困难，进度难以掌控，异地协同设计评估手段也显缺乏。不同企业、不同产品的开发数据通常分别存储在各自的PDM 数据库中，跨企业的 PDM 设计数据查询、共享困难。在产品数据交换的过程中，没有统一的对象元数据模型标准（如产品类、名称、标识编码、版本、产品对象的数据与文档），产品数据的异构特性使得数据的惟一性、一致性、实时性很难保证。 异构 PDM 之间缺乏产品协同设计过程的统一管理能力，主厂商很难第一时间从供应商处获取采购件、外协工装的设计开发进度，设计需求、进度要求的更改也很难实时传递至采购件供应商，导致无法及时评估外协部件能否满足总体设计需求。对于产品的异地协同开发，企业间的信息传递等非开发性工作环节耗时过多，影响了产品设计周期，亟需可靠高效的多人异地协同评估手段，开展产品的异地协同评估。标识解析与工业软件一体化技术能够打通项目管理信息孤岛，辅助项目高效管控，保持生产执行对工艺优化的快速响应，提升工艺柔性能力。 2. 降低质量信息追溯难度并提高信用 质量信息追溯过程的数据开放不足、相互孤立，导致企业间存在信任危机；解决方案缺乏开放的开源工具，导致技术要求高、开发难度大。 单个工业软件覆盖面有限，质量追溯很难实现全链条覆盖，标识数据的开放不足进一步制约了产品追溯体系建设。工业产品的生产、流通、监管等过程分属不同部门管理，相应平台互相独立（不直接连通）；区域性、行业性质量追溯平台设置重叠，跨区域、跨行业数据需求难以满足的问题随之而来。追溯信息难辨真伪、可信追溯新技术不成熟等，弱化了追溯数据的可靠性及应用价值。追溯数据仅来源于单一企业内或少数相关联企业，无法确保产品信息准确，致使追溯范围产生局限性；企业与客户在产品质量与信用信息方面存在不对等，可能导致卖方投机、消费者失信等情况。标识数据的有效溯源，将突破消费者与厂商之间的信息交互壁垒，提升售后产品的信息透明度。 3. 破除企业“业财融合”的信息壁垒 产品供应链受全生命周期数据壁垒的影响，造成供应链金融长期存在“强需求”“弱信用”的矛盾；核心企业渗透产业全链条难度大，对二级以上供应商的信用传递不足，而小微企业信用自证与融资困难问题突出。银行认可的是核心企业控货与调节销售能力，在无法可靠获取上下游企业生产数据的情况下，仅有对上游供应商（核心企业有直接的应付账款义务）提供预付款或注资的意愿，由此导致二级、三级供应商 / 经销商的融资需求得不到满足，供应链金融的业务总量受到制约。标识解析与工业软件一体化能够构建支撑“双循环”新格局下的供应链信息全球互通，通过实时动态、全面精准的供应链金融能力来加强企业信誉评估体系。 三、工业软件一体化发展现状 （一）国际龙头企业主导行业发展 国际龙头企业立足自身特色，通过兼并收购快速扩充能力，形成了平台化、云化的工业软件生态，以工业软件云平台的方式进行跨工业软件的数据集成。达索系统集团、西门子股份公司的相关产品代表了国际工业软件一体化的发展趋势 。 2019 年，达索系统公司将…

华润三九蝶变平台项目上线验收了，再项目实施过程中，时间紧，任务重。蝶变平台上线运行至今，系统运行稳定，项目团队敬业不辞辛苦的态度，得到了华润三九各级领导的一致认可，并给予书面表扬。

一、DCP评审时IPMT团队和PDT团队互动的关键点  DCP（Decision Check Point）:业务决策评审点，在IPD流程体系中，是由IPMT来评审PDT团队的业务计划书，并对PDT团队的给予指导，并且评审通过的话，IPMT要承诺提供资金和资源给PDT，PDT团队则向IPMT汇报业务计划、方案并执行业务计划。IPMT和PDT在DCP的互动可以用下图表示： 其中IPMT的职责简单介绍如下： 由公司总经理或事业部总经理领导，对整个产品或产品线负损益责任 明确业务使命、愿景、目标、战略方向和投资组合优先顺序 选择或取消细分市场 建立产品投资标准并管理投资 批准产品线业务计划、产品业务计划 授权PDT执行决策评审的结果 对PDT成员代表的功能领域提供指导 承诺和提供资源和资金，以确保功能部门的产出 在跨项目间安排资源管道的优先分配顺序 在公司内部处理从功能领域或外围团队上报的问题 支持产品开发流程改进 四个决策评审点（DCP） 二、各DCP评审的内容： 1．概念决策评审(CDCP)： 在概念阶段结束时召开概念决策评审 PDT向IPMT报告初始的业务计划，由IPMT来决定项目是继续还是终止 若初始的业务计划得到批准，IPMT会做出下一阶段开始所需的承诺，项目进入计划阶段 关注：该概念阶段业务计划作为一个产品，是否具有足够的业务发展潜力（相对于其他项目而言）？ 对市场的了解 产品 业务潜力（相对其他产品而言） 开发计划 分销渠 计划决策评审(PDCP)： PDT向IPMT提交最终的业务计划和产品开发合同书，由IPMT做出继续/终止的决策 若业务计划获得批准，则PDT与IPMT签订合同，合同中列出允许的偏差，项目进入开发阶段 合同代表了IPMT做出的坚实承诺，即每个主要部门都将支持项目以及给PDT必要的资源。另一方面，PDT将承诺按合同要求完成项目的交付目标 关注：建议的产品能否被及时推向市场并赢利？ 具有竞争力的产品（分销渠道和客户） 业务潜力 开发计划 分销渠道 风险管理 可获得性决策评审(ADCP) ADCP在任何主要的发布费用（Launch expenses）投入之前进行，是产品正式公开发布及推向市场前的决策评审 ADCP评审的目的是证实在计划阶段制定的业务计划中的估计和假设，并评估产品发布前公司的准备情况 与其它决策评审一样，PDT向IPMT提供是否将该产品推向市场或取消项目的建议，需要IPMT明确做出继续/终止决策 若产品获得批准，则由IPMT分配资金，项目进入发布阶段 关注：该产品是否已准备好发布和发货？ 业务展望 发货质量 发布和宣传推广计划 渠道搭建 服务架构 风险 生命周期终止决策评审(LDCP) 在产品生命周期结束时，生命周期管理团体（LMT）要向IPMT给出停止销售、停止生产、停止服务等方面日期的建议，由IPMT做出继续/终止的决策 IPMT必须要审核产品生命终止的发布是否与新产品战略保持一致，以及是否已很好地考虑了潜在的客户满意度方面的问题 关注：该产品应该继续保留在市场上吗？如果不需要，是否有将策略和费用都考虑进去的详细退出计划？…

IPD，集成产品开发流程管理体系思想 虽然任正非从来不认为华为已经成功了（他认为华为只是暂时没有失败）。 管理体系是否有效，要和企业所处行业、历史、规模、人员结构、外部环境等相吻合， 黑格尔说，人类最大的教训就是人类从来没有从历史上吸取教训。 IPD（integrated product development，集成产品开发） 我们学的方法是IBM的。IBM教会了我们怎么爬树，我们爬到树上就摘到了苹果。我们的老师主要是IBM。” 说：“创造力就是连接……连接生命中的各种体验，然后把把它们组合成一种新的东西。” 向榜样和标杆学习，采用业界成熟的管理体系，是企业提高创新和研发管理水平的重要方法，但在如何学习上不少企业走了弯路，其中的一个原因就是引入过多的管理体系让管理者和员工无所适从。华为过去10多年的实践为我们指明了一条如何学习榜样的有效路径。这条路就是持之以恒地模仿、跟随、固化、优化一套经过验证的管理体系，结合企业特点不断向深度发展，然后超越，最终形成自己的管理体系。 这家企业出身卑微，没有显赫背景，在老套的价值观（以客户为中心+艰苦奋斗+自我批判）的带领下从2万元起家，在竞争异常激烈的通信市场用20年时间进入世界500强。 在歌功颂德的同时，也以寻找华为公司和任正非的破绽为己任，当任正非说要追求利润的时候，他们说这个和互联网精神不符合，互联网精神要的是烧钱买流量，小米、京东、BAT一开始都不追求利润，最终才有利润；当华为任正非说要科学管理，管理要规范化，化，向“蓝血十杰”和西方管理持续学习的时候，他们说任正非老了，跟不上时代的发展，华为因为管理太僵化已经遭遇“创新者的窘境”，快要步诺基亚、摩托罗拉、北电网络等的后尘了;当任正非说要艰苦奋斗、加班加点奉献（尤其是管理层）的时候，他们说这不符合80、90后的需求；当任正非说要坚持自我批判的时候，他们说这是什么年代了，现在年轻人要的是个性、自我，这样才能创新；当任正非说要以客户需求为中心、围绕客户需求创新的时候，他们说客户不知道客户需求是什么，乔布斯从来不做市场调研…… 任正非曾多次强调，华为没有什么秘密，取得一些成绩在于20多年持续坚守一些常识，那就是：以客户为中心，坚持自我批判和艰苦奋斗，长期坚持压强原则，只做一件事（通信设备）。轮值CEO徐直军强调，华为的成功，一是利益分享机制，通过股权稀释让大部分员工成为华为股东，分享经营利润；二是持续坚持自我批判和艰苦奋斗的企业文化。最高层强调的这些要素，华为在2009年以核心价值观的形式进行了固化，在6大核心价值观中，成就客户、艰苦奋斗、自我批判位列前三。 总结下来，除了上面提到的“官方”认可的全员持股、以客户为中心、艰苦奋斗、自我批判以外，主要集中在几个方面：（1）压强原则。（2）创新与研发。（3）市场营销能力。（4）低成本优势，尤其是研发低成本。（5）管理体系和IT。另外，还有作者总结为外部市场环境，比如中国通信市场高速发展、固定汇率带来的海外市场低成本优势等。 华为CEO用这个比喻来强调跨部门流程的重要性。 华为有多少个跨部门流程？从满足客户需求角度，华为只有3个流程 （1）IPD流程（Leads To Cash）：各层级和各领域战略规划、需求管理、产品规划、项目任务书开发、产品开发、上市、生命周期管理。 （3）ITR（issue to resolution，从问题到解决）流程：包括从客户问题产生到最终得到解决的流程。 LTC即L2C,Leads To Cash,从线索到现金的企业运营管理思想，华为的LTC流[4]程也深入的应用了这一思想[5]，L2Cplat是这一思想的践行者。是以企业的营销和研发两大运营核心为主线，贯穿企业运营全部流程，深度融合了移动互联、SaaS技术、大数据与企业运营智慧，旨在打造一个从市场、线索、销售、研发、项目、交付、现金到服务的闭环平台型生态运营系统. （3）ITR（issue to resolution，从问题到解决）流程：包括从客户问题产生到最终得到解决的流程。   华为在流程建设方面，首先从方法论上确定了规则，即“流程的核心是要反映业务的本质，还原以后，该是谁的就是谁的。” 然后，针对三大业务流，建立对应的三个系统，即IPD（产品集成开发）、LTC（机会至收款）、ITR（售后），同时用流程IT的方式进行固化。这样就可以避免“前面一段说日语，中间说德语，后面说汉语”、“各段都是李云龙”的问题。大部分企业都可以参照梳理成这三大业务流。 最后，在“以客户为中心”的理论指导下，进行组织配置，包括责任人、考核方式等。保证瞎子能共同拼出一头真正的大象。 一个公司就三件大事： ●第一件把产品开发出来，产品从有概念开始，到面市； ●第二件是把产品变现，要有客户买，形成订单，发货、安装、验收、回款； ●只有上帝做的东西才没问题，当时没问题，时间长了也有问题：客户有这样那样的需求，产品要不断地改进升级。因此，有了第三件事情，网上有问题，发生了，就要解决，然后关闭。某代表处的问题解决了叫“解决”，全球此类问题都根治了才叫“关闭”！ 这三件事情对应三大业务流，这三大业务流有起始终止，对应三个系统（IPD/LTC/ITR），还要有相应的组织去适配（不仅是流程IT），也要和客户去匹配，很多订单要和客户去对接。 日复一日，年复一年，简单、海量、重复的工作怎么去做更好？就是先要把它流程化，模板化，固化下来，最后采用IT支撑。公司三大业务流，日复一日，一年运行下来，就形成了公司的业绩：财务三张表。 业务就上面的三件大事，流程要匹配业务流，不长也不短，够用就行。其核心是：流程要反映业务的本质，尤其是完整系统地反映业务的本质。业务中的各关键要素及其管理不要在流程体系外循环。基于流程建设的管理体系（IPD/LTC/ITR），是一个运营系统，是一个业务操作系统（BusinessOperationSystem），其中最重要的是落实到组织中，就是流程化的组织建设和运作。 产品是满足需求的交付物的总和，包括有形部分和无形部分。为了强化这点，IPD体系用offerings来替代产品这个概念，中文翻译为“产品包”，是对客户和下游环节所有交付的统称。 产品包需求（offerings requirement，OR）就是对原始需求进行分析、判断和加工后，最终向客户（包括外部客户和内部客户）交付的需求，是对产品包的正式描述，完整且准确，是对产品包进行开发、验证、销售、交付的依据。 （1） 开发（development）：开发是创新性活动，目的是在企业有盈余的前提下满足市场和客户需求。 （2） 产品（product）：产品是满足客户所有需求（$APPEALS）的提供物的总和，也就是前面定义的产品包（offerings），包括有形部分和无形部分。 （3） 集成（integrated）：IPD的威力体现在“集成”上。首先，IPD集成了若干中有效的工具、方法和流程。其次，IPD把企业内各资源部门通过跨部门团队的方式集成在一起，共同完成规划和研发工作，满足客户需求。最后，也是最重要的一点是：IPD集成了若干重要的思想，这些思想是IPD的核心。 所以，IPD是基于市场和客户需求驱动的规划和开发管理体系。其核心是由来自市场、研发、制造、服务、采购等方面的人员组成的跨部门团队共同管理整个规划和开发过程，即从客户需求、产品规划、任务书开发、概念形成、产品开发、上市，直到生命周期的完整过程。通过IPD管理体系，使产品开发更加关注客户需求，加快市场响应速度，缩短产品开发周期，减少报废项目，降低开发成本，提高产品的稳定性、可生产性、可服务性等。 可以从3个不同视角来定义IPD： （1） 狭义IPD：也叫“小IPD”，指的就是新产品开发。 （2） 中观IPD：包括产品开发（狭义IPD）、市场管理及产品规划（market management，MM）和需求管理（requirement…

虎年新春携手国家卫健委直属医院山大二院共建基建项目管理平台，实现基建项目管理全过程实时监、管、控，高效实现全过程管理和考核，同时实现数字化交付管控。 包含院东扩建、黄河北新院区一期、二期等新建改造扩建项目7余个项目，40多万平米。