按照“碗、锅、田”理论，已有产品是去年已收获，可以快速做到锅里、碗里的白米饭；要想吃新米，需要年底先耕地、播种、浇水、施肥、除虫，来年才能收获。田里工作主要是研发（广义角度，只要是研究开发新东西的，都是研发，不局限于硬件产品，可能是软件代码，或咨询方案，或服务策略，或预想理论。这里主要以有常规实体产品输出的研发组织）。一个简化理解如下图所示：

先是准备田里的：营销用服提出需求和销售规模，研发积累和确认技术趋势，财务核实预算和增长。
然后执行锅里的：研发启动新产品的设计、实现，按照预定的成本、规模，实现产品的批量生产能力。
最后放到碗里去：营销用服、供应链按照销售订单、价格，不断将产品商业化，实现利润和公司目标。

研发工作的特点之一是“创新”，新东西的目标设置、执行控制、业绩评估不太容易。随着对产品创新要求的提高，现在研发管理已成为现代企业管理的研究热点，方法论也层出不穷。从项目开发管理，产品开发管理，到广义的PACE(Product And Cycle-time Excellence，培思)，IPD(Integrated Product Development，集成产品开发)，再到敏捷管理，去KPI，每种方法都有各自的特点和适用场景。

可以从研发工程师拆解一下研发的主要工作。研发工程师全称是研究开发工程师(Research & Development Engineer，RDE)。

主要工作方式是三种：研究、开发、工程化
主要工作内容有三类：技术、项目、产品

如下表所示：

我们日常听得比较多的可能是：研究技术、开发项目、工程化产品。实际上，不同目标、阶段、类型、规模的研发组织，研发的定位、工作方式不尽相同，各种组合都有可能。老板和研发负责人才是最佳表述人。

研发需要投入人、钱、物、时间，存在技术难度，具有投资性、滞后性、积累性和风险性。研发内部常用项目管理方法，使用各种支持系统，如：PM(Project Management，项目管理系统)，或RDM(Research & Development Managemetn)，或PLM(Product Lifecycle Management，产品生命周期管理)，或CPD(Collaborative Product Development，协同产品开发管理)。

从用户及其他业务部门角度，研发的落地成果是工程化的新产品。所以ERP中，研发相关的内容，主要是钱和新产品数据。

2 ERP主要操作

钱

ERP中，很难量化评估研发过程和结果产出，但研发花出去的钱可以记录统计。

费用。研发过程会产生费用，ERP中要及时根据财务规定的类别做记录，便于后续使用。研发主要的费用类别包括：人力类(如工时工资、福利、社保等)，资产类(如设备费、仪器费、样机费、工装费、材料费等)，沟通协作类(差旅费、业务招待费、培训费、技术资料费、科技合作费等)，产品化类(注册费、认证费、开模费、仓储费等)等等。在研发发薪、采购、外协、报销等等操作时，需要在ERP中归类费用。
项目费用VS产品成本。除了按费用类别，研发过程的费用常规按项目统计；工程化产品，还会按产品维度管理。项目维度，更多根据项目进展阶段，看实际产生的费用和预算偏差（项目的成果可能是原型机、技术文档、专利、研究报告等等形式，可能不会有直接商业目标）。而工程化产品，有直接商业目标，费用要按“投入产出比”计入，需要按“产品研发成本”，“工程化产品的生产单位成本”来计算，是否值得投入，定多少价格、卖多少能开始盈利？在ERP中，需要及时按项目、产品维度，记录、统计。
预算。研发费用繁杂且多变，做预算可以做一定管控，研发预算常规按部门、项目/产品、均摊共用项目等方式。按时间段（常规是年度）、类别做好后（预算是另一门科学和艺术，按下不表），需要导入到ERP(或者更专业的预算系统中)，与每一次的实际费用关联起来，在半年、年度时统计，总结偏差原因，下一年改进预算。经过历史数据比较和几次PDCA，预算就会趋向准确。
监控。做了预算，除了事后统计偏差，可在ERP或OA的具体费用流程中，做好申请/审批控制点，这样能做到事中控制，事前提醒。根据管理成熟度可实施不同方案，可以做偏差说明，如申请、填写、审批费用时，数值超过剩余预算的，必须填写超过预算的原因；也可以做例外审批，如申请、审批时超过剩余预算的，审批权自动上移一层；还可做强制规范，如申请费用时最大数值不能超过剩余预算，填写或审批时超过预算部分将自动减掉。
变更。研发过程需要应对变化，预算的项目、类别、金额，可能发生变化，一次预算后总是违规操作，会导致规则形同虚设，此时可以做合规变更。变更之前，ERP可以统计提供已经产生的费用（结合项目管理可以查看已经到达的阶段和交付物）；线下变更确认后，可以及时导入ERP中，项目将会按新的预算执行。

实际上，ERP中，常规会对所有业务单元的钱，进行预算、监控、变更，做业务财务化管理。

新产品

ERP中，新产品数据是研发最重要的输出，为后续所有操作提供操作数据来源。

新物料。新产品会尽量复用原有零部件，不能复用的零部件需要在ERP中增加新物料，并承认。新物料的增加，除了编码、技术参数外，更重要的是考虑批量生产的供应商、成本、加工信息、质量检测、备选物料替代等信息。新物料的承认，是从产品工程化的产出之一，需要严肃对待，一旦承认发布（如果是新供应商，还存在新供应商的承认），就说明该物料的状态，从研发内转换到了研发外，可以按照工程化的批量规则进行操作。
新产品BOM。新产品的组织结构，是产品工程化的里程碑产出，是研发向供应链最重要交付之一。ERP中，每次发布新产品BOM，是一个奠基型的大事。研发准备好物料、新产品BOM后，经过财务、营销、供应链、质量等各部门严肃评审，后续该产品相关的各业务，在ERP中能正常运算和执行。ERP中发布新产品BOM后，营销、供应链可用来做新的预测、计划。
新工艺。新产品、新物料，批量生产时可能引入供应链的新工艺。研发将做好的生产工艺、生产工作等，培训、移交给供应链。ERP中，供应链将新增或调整工艺路线、工作中心等，匹配新产品的各种计划计算和执行。

ERP中，新物料、新产品BOM、新工艺等新数据，会成为供应链工作的支持元数据。

ECR (Engineer Change Request，工程变更需求)

ERP中，元数据是各种后续操作的因子和参数，ECR将会变更这些因子和参数。

影响分析。ECR会解决具体问题，也存在实施成本。ECR需要记录变更类型（如性能改善、设计变更、工艺变更、降低成本、物料采购、客户请求、软件变更、BOM变更、法规变更等），分析问题、不修改/修改后的风险，修改后方案，及验证方法，还有最重要的影响分析。影响分析可以从ERP中获取，包括钱、时间、人力（如新料采购、新工艺、库存物料处理、在制产品返工、在库成品返工、客户已使用产品召回返工、新老产品兼容识别等等）。
执行。ECR本身的流程审批在线下（包括ECR/ECO/ECN/ECA，Request，Order，Notice，Authority等），一旦确定执行，ERP中，需要能在某一时刻，切换新BOM、新物料，开始变更后的新计划、新工艺。并且，ERP中，要能查询到变更前、后的差异，便于后续比较。ERP中的变更替换，涉及面广，靠人工很难保证完整性、及时性，需要由ERP系统自动完成。

ERP运行着“流”，ECR类似于“坝、石头”，会阻碍流动。

3 支撑

ERP中，研发是新产品元数据的整合者，元数据的有效性，需要以下重要支持。

新产品开发模式。新产品BOM只是最后的落地产出，实际上，客户角度的新产品需求($APPEALS)，需要公司各业务的协作才能完成。如何让新产品的落地产出，稳定地变成物流、钱流，而不是移石头、打补丁，时断时续？ERP可以反映新产品发布后呈现的结果，加快流的过程；但进入ERP之前的新产品开发工作，需要另行完成。这点属于新产品的方法论问题，业界已有很多方法论可以选择，如传统贸工技企业，常用的是IPD及其变种，产品不是研发一方完成的，而是由各业务主持的集成产品开发团队完成的。
工程商人。研发的工作方式有研究、开发、工程化，工作内容有技术、项目、产品，对研发外的供应链、营销、老板、客户而言，最关注的是落地产出的“工程化产品”，这是放到锅里已做好，随时能盛到碗里吃的。研发的主战场在田里，但只有放到锅里，才能被端上桌，否则会烂到田里。研发除了研发人员，还要有工程师，还有要有工程商人，把研发的技术、项目成果，转换为商业化产品。这点属于人的问题，怎么做企业各有妙招，关键是效果。
设计BOM(研发BOM)，转成生产BOM(制造BOM)、配置BOM、维修BOM。新产品的落地产出载体主要是BOM，对于供应链、营销、用服而言，如果只有一套所有物料组成的BOM结构，他们将被迫从研发角度来理解和使用产品数据，这对用户要求很高，实际上分业务单元的目的之一，就是减少其他思考，聚焦到核心工作中。这点属于交付件问题，ERP中，产品BOM，需要能按不同业务角度查看，隐藏不需关注的细节，快速聚焦关注点。

4 小结

ERP中，研发是“物流”的“渠道”，研发把新产品持续地推上货架清单，让“钱流”的“渠道”有具体载体，能够落地对客户承诺。

以上是关于浅析ERP系统--研发的主要内容，如果未能解决你的问题，请参考以下文章