简介这份 NPI新产品引入指导流程图以清晰直观的节点串起从客户 SOP 资料准备到最终发货的全流程覆盖工程文件制作BOM、备料核对、QAE 审核、排产生产、老化汇总、试产评审、发行报告书及维修判定等关键环节适合制造型企业项目管理人员、质量工程师与试产团队用于梳理导入顺序、明确阶段分工与把控放行标准。资源为单个 docx 文件约 69KB便于直接查看、标注或按需二次编辑。目前已有 118 人浏览学习。借助这份流程图读者可快速理解 NPI 每一阶段的输入输出与判定节点统一团队对试产、中试和量产衔接的认知也能作为内部培训、流程审计和体系文件编写的参考底稿。1. NPI指导流程图让新品从研发手里到产线手里少折腾几轮一个看似简单的道理产品从研发转到量产真正难的不是试产通过那一刻而是从样品到稳定出货之间那一长段没人说得清楚的灰色地带。NPINew Product Introduction新产品导入指导流程图就是把这段路拆成阶段、门槛、责任人和检查表的一份可执行文档。它解决的核心问题是研发与制造之间我以为可以量了和实际还差得远的认知差。适合项目经理、NPI工程师、品质工程师以及所有被新产品导入折磨过的人。别看它只是一份Word格式的.docx文件里面要是不把阶段入口、输出物、评审标准写清楚量产翻车是迟早的事。2. 先定流程骨架NPI五阶段怎么切分输入输出在哪里交接2.1 从Proto到MP五个阶段的划分依据常见做法是把NPI拆成Proto、EVT、DVT、PVT、MP五个阶段。Proto阶段做设计可行性验证样品能不能点亮、能不能装配先确认EVTEngineering Validation Test验证设计功能有没有实现DVTDesign Validation Test验证设计是否符合规格PVTProduction Validation Test验证产线能不能稳定造出来MPMass Production才是正式量产放行。五段式的好处是每段都有一个明确的主人Proto和EVT由研发主导DVT由研发加质量共同把关PVT由制造工程主导MP由工厂运营接手。这样分责任不会悬空。值得注意的是很多项目死在阶段定义不清晰上。比如有些团队把DVT和PVT混在一起一边还在改结构一边就让产线爬坡最后查良率问题根本分不清是设计问题还是工艺问题。所以流程文件第一步不是画图而是先把阶段边界钉死什么时候算进入下一阶段要有硬性条件不是研发说OK就算OK。2.2 阶段输入输出与评审点对照表把每个阶段的输入、活动、输出和评审节点做成表格是流程文档最实用的呈现方式。直接看图的人可能各看各的但看表的人能对齐进来什么、出去什么。阶段核心目标主导角色典型活动Proto验证设计可行性研发手工样品、点亮测试、结构装配EVT验证设计功能研发工程样品组装、功能测试、问题闭环DVT验证设计符合规格研发质量可靠性测试、合规测试、环境测试PVT验证产线可量产性制造工程小批量试产、良率爬坡、工艺确认MP正式量产放行工厂运营批量生产、产能验证、持续改善上面的表只是主骨架真正写进指导流程图文档的还要有输入和输出阶段输入条件输出物Proto原理图、结构初稿、物料清单初版原型样品、问题清单、设计可行性报告EVT原型闭环报告、可采购物料清单EVT测试报告、设计失效模式分析更新、变更清单DVT工程图纸归档、BOM修订版、样机DVT测试报告、合规认证资料、可靠性报告PVT试产工装夹具到位、作业指导书初版、物料齐套PVT试产报告、良率报告、工艺参数表MPPVT问题关闭、量产BOM冻结量产批准书、产能评估、售后备件方案评审点穿插其中EVT结束后做第一次设计评审DR1DVT结束后做第二次设计评审DR2PVT结束前做量产准备评审RR。这三个评审点在流程图上要画成菱形判断框不通过就要走返工回路。2.3 流程节点怎么编号让每个活动都能被追溯画NPI指导流程图最大的坑是活动没编号。没有编号后面开会说第三个框那里有个问题每个人理解的第三个框可能都不一样。我习惯用三段式编号比如E02-03表示EVT阶段第2个泳道里的第3个活动。编号规则要写进流程文档的附录同时要求所有会议纪要、问题跟踪表引用节点编号。给每个活动配字段时至少要包含活动编号、活动名称、输入物、执行人、输出物、评审要求、关联文档编号。这样做的直接好处是后期可以按编号追溯到具体的问题来源。比如PVT阶段良率不达标你查记录发现是D02-07老化测试参数确认没有执行责任人、原因、影响范围马上能圈定。3. 用python-docx把NPI指导流程落成可查的Word文档3.1 为什么我要用脚本生成docx有人觉得画NPI流程图用Visio拖拽就行何必写代码。我自己的血泪经验是纯手工画的图阶段一多、评审点一密改一处就要连带改文字、改箭头、改版式最后文档和实际流程对不上。用脚本生成docx把阶段、输入、输出、评审存成结构化数据要改流程时只改数据重新跑一遍脚本表格和正文自动更新。另外.docx本身是工程团队最常交换的格式发出去别人能直接改不用额外装软件。3.2 最小脚本生成带阶段表和评审节点的Word文档下面是用python-docx生成NPI阶段表的最小示例。先定义数据结构再创建文档、表格和标题最后保存为docx文件。from docx import Document from docx.shared import Pt # 阶段数据名称、目标、输入、输出、评审 phases [ { name: EVT, goal: 验证设计功能是否实现, input: 原型闭环报告、可采购物料清单, output: EVT测试报告、DFMEA更新, review: DR1设计评审 }, { name: DVT, goal: 验证设计是否符合规格, input: 图纸归档、BOM修订版, output: DVT测试报告、合规认证资料, review: DR2设计评审 }, { name: PVT, goal: 验证产线可量产性, input: 工装夹具到位、SOP初版, output: PVT试产报告、良率报告, review: RR量产准备评审 }, { name: MP, goal: 正式量产放行, input: PVT问题关闭、BOM冻结, output: 量产批准书、产能评估, review: 量产放行评审 }, ] doc Document() doc.add_heading(NPI指导流程阶段定义, level1) # 阶段总表 table doc.add_table(rows1, cols4) table.style Light Grid Accent 1 hdr table.rows[0].cells hdr[0].text 阶段 hdr[1].text 目标 hdr[2].text 输入 hdr[3].text 输出 for p in phases: row table.add_row().cells row[0].text p[name] row[1].text p[goal] row[2].text p[input] row[3].text p[output] doc.save(NPI_guide.docx)这段脚本的核心逻辑是先用列表存阶段数据再通过add_table创建四列表格表头用阶段、目标、输入、输出然后逐行写入数据最后保存文件。关键在于数据结构化——你想加评审节点就往phases里加一个review字段再在表格里加一列。参数方面table.style用的Light Grid Accent 1是python-docx内置样式如果你用的Word模板样式不同直接换成Table Grid这类基础样式更保险。用脚本跑出来的docx正文描述也要同步写进去。我常用的做法是每个阶段单独生成一个小节先写阶段目标和出口条件再放输入输出表格最后是一个评审关闭项列表。这样读者拿到文件不至于只看到一张孤立的大表格。3.3 嵌入Visio/SmartArt的注意事项光有表格没有流程图文档的图感不够。常见做法是用Visio画泳道图画好后另存为图片插入docx。注意导入前设置清晰的分辨率避免打印时模糊。如果你没有Visio直接在Word里用SmartArt也行但SmartArt的排版自由度低复杂的分支画起来很别扭。我的习惯是一页纸总览图用Visio画作为骨架细节用表格展开。图和表格之间靠节点编号关联比如图里的E02-03对应表格里的编号E02-03。这样文档结构清晰维护时也只需要改图表两处不会出现图说一套、表说另一套的尴尬。4. 让指导流程真正指导起来时间线、评审与变更路径4.1 一张可复用的NPI时间线参考阶段划分清楚了还要给每个阶段排时间。不同行业差异很大但一个典型的消费电子类产品可以按下面的周数估算阶段参考周期关键里程碑Proto2周设计可行性确认EVT3周DR1评审通过DVT3周DR2评审通过PVT2周RR评审通过、量产批准MP持续首次批量出货这个时间线只是参考。实际项目里物料采购周期、认证周期、模具修模周期都可能把计划打乱。所以在流程文件的附录里要把关键路径标出来哪些活动延误会影响整体进度。最常见的延误点是长交期物料比如定制电池、IC芯片必须提前在Proto阶段就启动采购动作否则整个NPI节奏会被硬生生拉停。4.2 阶段结束前的评审检查表关掉该关的问题再放行评审不能凭感觉每项评审都应有检查清单。我在DVT结束前至少要求关闭以下事项可靠性测试全部完成且无明显失效合规认证已送样未出现安全项问题所有设计变更已完成验证并更新图纸BOM与图纸一致未发现缺料或错料售后维修可行性评估已完成。任一项不满足就不能进入PVT。DR1和DR2的区别要写清楚。DR1侧重功能看设计能不能工作DR2侧重规格和合规看设计是不是符合客户要求、行业标准和法规。很多团队把两个评审合并省了一次会结果DVT阶段发现基础安全测试没过反而浪费更多时间。流程文件里要把评审目的、参与角色、通过标准、输出物四要素写全签字才不是走过场。4.3 工程变更ECR/ECN怎么接入流程NPI过程中改设计是常态但改设计不能靠拉个群吼两声。流程里要明确工程变更请求ECR和工程变更通知ECN的路径工程师提交变更请求说明变更原因、影响范围项目经理组织评估主要评审成本、交期、物料、验证方案批准后执行变更更新文档并通知生产。在指导流程图中变更路径应该画成一条贯穿全流程的旁路任何阶段都可以触发。我在流程文档里专门留了一节变更影响评估表要求申请人必须填写涉及BOM变更还是工艺变更、需要不需要重新做可靠性测试、对量产工装有没有影响、呆滞物料怎么处理。表格里的每一项都对应一个责任人或责任部门。这样变更不再是个别人的意见而是可追溯的工程决定。5. 避坑NPI流程文件从画了到用了的5个高频翻车现场5.1 翻车现场一流程图做得很精美但没人看现象流程图画了几十页上传到共享盘开会没人打开产线还是各干各的。原因文档太重没有一页纸总览读者不知道从哪看起。解决把流程文件拆成三层第一层是一页A3总览图只看阶段和评审点第二层是阶段详情表第三层是每个活动的SOP链接。总览图放在文档最前面让任何人都能在一分钟内定位到自己在哪个阶段、该干什么。5.2 翻车现场二评审签字了试产还是翻车现象DR2评审全部签字通过结果PVT一开始就出现批量不良。原因评审标准太含糊无明显异常基本满足要求这类说法纯属玄学评审人凭感觉打勾。解决把评审标准改成量化描述比如老化测试48小时失效数为零装配力矩在作业指导书范围内不良率低于0.5%。每条标准后面加一列实际结果由数据说话而不是靠印象签字。5.3 翻车现场三阶段结束了还在改BOM现象PVT都结束了BOM还在频繁更新导致采购和生产无所适从。原因流程文件里没有定义BOM冻结节点。解决在DVT结束、进入PVT前设置BOM冻结之后所有BOM修改必须走ECN流程而且要评估库存影响。流程文件里把这个节点画成红色菱形旁边注释冻结后变更需工程、采购、生产三个部门会签。5.4 翻车现场四物料交期卡在PVT项目整体延期现象PVT产线都准备好了结果关键物料还没到整条线停工等待。原因流程文件只覆盖了工程活动没有把长交期物料采购纳入阶段入口条件。解决在每个阶段的输入条件里增加一列物料齐套要求并且在项目启动时列出长交期物料清单标明下单时间点和责任人。PVT排产前两周必须做一次物料齐套率检查低于95%不允许开线。5.5 翻车现场五现场执行和流程文件不一致现象研发说按流程文件做产线说按自己的SOP做两边文件对不上。原因流程文件是独立的没有和实际作业指导书SOP关联。解决给流程文件里每个活动加一个SOP编号字段把SOP文档链接嵌入对应活动描述里。文件发布时同时复核SOP是否齐全缺SOP的活动不允许进入执行阶段。6. 让流程文件活起来版本管理、字段预留与PLM衔接docx最大的隐患是版本混乱。我自己的教训是文件名一定要带版本号和日期比如NPI指导流程图_v1.3_202506.docx文件内部第一页放修订记录表记录每次改版的时间、修改人、修改内容和版本号。发布时把旧版本移到历史版本文件夹共享盘里永远只有一个当前版本避免同事下载到过期文件。字段预留也要提前想。流程文件里的阶段、评审、变更信息未来大概率要对接PLM系统或MES系统。我习惯在docx表格里保留规范的字段名比如stage_code、review_type、ecr_no不要用阶段一评审A这种口语命名。这样将来导入PLM做电子签核时映射关系直接可用不用重新整理。我还有一个习惯每次项目复盘时把实际发生的延期原因、评审遗漏问题、变更次数统计回填到流程文件的问题清单里。连续三个项目之后那份docx就不再是空泛的流程图而是带真实数据支撑的NPI作战手册。新人照着它做至少能避开我们踩过的坑。希望帮到你。本文还有配套的精品资源点击获取