作为一个制造业企业的IT人员，在推进数字化转型过程中经常会遇到一些阻碍，例如在推进PLM系统建设的过程中，研发人员往往认为这是"又一套需要研发配合的系统"，这种对待项目消极的认知本身就是不利于项目推进的。
在离散制造企业的数字化转型进程中，PLM系统绝非IT部门凭空新增的一套数字化工具，而是破解研发生态长期痛点、打通数据流转堵点、释放研发创新效能的核心载体。
站在制造企业IT部门的视角，PLM的需求挖掘不能停留在“技术实现功能”的传统逻辑里，必须以研发业务的真实痛点为起点，站在“与研发共同重构研发管理模式”的立场上，打破研发团队“怕加活、怕重复录入、怕数据权责不清”的顾虑，最终实现用系统代替人工承担重复工作的核心目标。
那如何进行一场调研，如何把研发部门的需求落实下来呢，不妨从以下几个方面入手:
一、需求挖掘的前置认知：打破研发的核心顾虑
在启动需求调研之前，IT部门首先要直面研发团队普遍存在的两个天然顾虑：
其一是不是又要让研发增加一套系统？
其二是不是以后所有资料都要我们自己录入、维护？如果不能先从认知层面消解这两个疑问，后续所有需求调研都只会得到“被动配合”的反馈，无法触达业务的真实诉求。
IT部门需要在项目启动之初就向研发团队明确传递核心信号：PLM项目的本质不是让研发配合IT做系统，而是双方携手重新设计研发产品数据的管理方式。项目的核心原则绝非“把研发现在的Excel直接搬到PLM里面”，而是通过系统能力最大程度减少研发重复录入、重复查找、重复发放、重复确认和重复变更的无效工作。同时要明确定位：研发、工艺、质量团队是PLM项目的业务Owner，负责定义业务规则和需求标准，IT和供应商团队的核心职责是把这些业务规则落地为系统能力，而非反向给研发强加系统操作要求。
当前企业研发链路中已经暴露的诸多顽疾，恰恰是PLM立项的核心合理性基础：客户技术要求Excel分散存储在不同工程师的个人电脑中、产品标准和工艺参数等资料散落在各个共享文件夹无法统一检索、OA发布新版本后旧版本难以全面回收、跨工厂车间长期存在产品版本不一致的风险、客户要求到内部标准再到工艺参数完全依靠人工传递、产品变更涉及多份文件时影响范围完全靠人工梳理很难全覆盖。这些长期存在的痛点，不是IT要给研发新增的麻烦，而是PLM系统要帮研发彻底解决的历史遗留问题。
二、需求调研的核心框架：从业务场景中挖掘真实诉求
需求挖掘绝不能用“你们需要什么功能”这类空泛的问题引导研发反馈，IT部门要深入到研发现场，从“你们现在是怎么工作的”切入，沿着产品全生命周期的真实流转路径拆解需求，最终输出核心调研成果。
第一维度：沿着产品全生命周期梳理基础数据需求
IT部门首先要请研发核心人员以一款典型产品为例，完整还原从客户需求进入到最终量产发布的全流程，比如梳理出“客户需求→客户技术规范→产品定义→研发设计→配方设计→工艺参数→试制→检测验证→产品标准→控制计划→量产→客户确认→正式发布→后续变更”的完整链路。
针对流程中的每一个节点，逐一确认5个核心问题：这个节点产生什么数据？数据由谁产生？当前存储在哪里？谁负责审批确认？后续哪些环节会使用这份数据。
这个环节要跳出“PLM管理的是文件”的传统误区，核心目标是梳理清楚产品数据之间的关联关系，落地“以产品为核心建立数据容器，关联标准、BOM、控制计划等所有相关数据”的核心架构，从根源上解决数据分散、找不到对应关系的问题。
第二维度：锚定研发效率痛点，量化价值需求
IT部门要精准捕捉研发团队在资料管理中耗费大量精力的无效工作：反复找资料、回溯历史版本、核对客户要求、整理零散Excel、编制标准和参数表、处理变更流程、发布和回收文件、回复生产现场和质量部门的问题、响应客户审核要求、整理各类审核资料。针对这些场景要进一步量化数据：比如客户要求发生变化时通常需要人工修改多少份资料，有没有近期发生的真实变更案例可以参考；研发最容易出现版本错误的环节集中在客户规范版本、产品标准版本、工艺参数、配方等哪些对象上；因为找不到最新资料需要反复确认的场景，单次要耗费多少时间，一个月大概会发生多少次。这些量化数据将成为后续PLM项目落地后计算收益的核心依据，也是向业务部门证明系统价值最直观的支撑。
第三维度：从现有工具的使用现状，梳理数据分类和权责需求
调研不要停留在“你们现在有没有用Excel”的浅层次问题上，IT部门要请研发人员现场打开真实在用的设计图纸的CAD、客户技术要求Excel、产品标准、工艺参数表、配方、检验规范、变更记录、最终发布文件，逐一确认每一类文件的建立人、修改人、审核人、批准人、发布人、使用人、需要同步知情的人群、旧版本的处理规则、变更后的通知机制、当前保障现场拿到最新版本的方法，把现有业务中模糊的权责边界全部梳理清晰，最终形成完整的数据责任矩阵，明确哪些数据由研发产生、谁维护、谁审核、谁使用。
在此基础上还要完成数据的分类管理需求定义，避免把所有内容都强行做成结构化数据：例如可以将产品型号、产品编码、客户、产品标准、规格、参数、配方、检测项目、控制计划定义为A类必须结构化的数据；客户技术规范、试验报告、验证报告、客户确认资料定义为B类“结构化标签+附件”的管理模式；客户会议纪要、一般技术交流资料、历史参考资料定义为C类仅需基础文档管理的资料，用最低的维护成本实现最高的管理效率。
第四维度：直面研发对“增负”的顾虑，挖掘自动化需求
针对研发团队普遍担心的“上线PLM反而增加工作量”的问题，IT部门要把它作为专题公开讨论，让研发团队充分说出顾虑：是不是又要重复录入一遍已经维护在Excel里的数据？是不是OA已经发布过的文件还要在PLM里再维护一次？每次变更是不是要多填一张表？历史产品数据是不是要全部手动重新录入？工厂存量资料是不是要批量重新上传？系统操作会不会太复杂影响日常工作？系统和MES等现有系统会不会出现数据不通的问题。这些诉求不是研发团队在反对PLM，恰恰是PLM系统设计必须优先解决的核心问题。
整个需求挖掘过程中最核心的部分，是梳理清楚所有可以实现“一次维护，多处使用”的场景：比如研发仅需维护一次客户技术要求，系统就能自动关联对应产品标准、自动映射到工艺参数、自动同步到控制计划、自动带出检验规范，最终直接供给MES、质量系统和工厂现场使用，让研发直观感知到PLM不是增加工作，而是从根源上减少重复工作。
第五维度：以真实变更案例为样本，深挖变更管理核心需求
IT部门要选取最近发生的一次真实产品变更案例，比如“产品厚度从12μm调整到11μm”，完整还原研发的全流程处理动作，逐一记录变更涉及的所有对象：客户规范、产品标准、配方、工艺参数、控制计划、检验规范、MES参数、工厂现场文件，分别确认每类对象是否需要调整、由谁负责处理、当前的处理方式是什么。基于这个完整的链路，验证自动影响范围识别功能的真实价值，明确ECR/ECO变更管理模块的核心需求：PLM系统需要在变更发起时就自动罗列出本次变更影响的所有产品、标准、配方、参数、控制计划和检验规范，彻底解决人工梳理容易漏项的问题。
三、需求落地的关键边界：打通系统协同，明确一期范围
PLM建设最容易出现的问题就是边界模糊，导致研发需要在多个系统重复维护同一份数据，反而增加工作量。IT部门作为多系统协同的总协调方，必须明确各系统的分工边界：PLM作为统一的产品数据源，负责承载客户技术要求、产品标准、配方、工艺参数、控制计划、检验规范的主数据维护；OA系统承接所有审批流程的落地；MES系统负责生产现场执行参数的下发和运行；质量系统承载检验结果的存储和质量控制；数据中台基于PLM输出的标准数据完成经营分析，从机制上杜绝同一份数据在多个系统重复维护的问题。
在所有需求梳理完成后，IT部门要联合研发团队明确PLM一期的MVP业务范围，把必须一期落地的核心场景和可以后续迭代的功能区分开，优先围绕痛点最集中、收益最明确的场景做建设，避免贪大求全导致项目周期过长，研发团队迟迟感知不到系统价值。
四、需求调研的收尾验证：锚定项目成功的最终标准
为了确保所有挖掘的需求都真正贴合业务核心诉求，IT部门最后必须向研发团队确认5个关键问题：如果PLM上线后只能帮你解决一个问题，你最希望解决什么？你最担心PLM给研发增加什么工作？哪些现在研发重复做的工作，系统应该自动帮你完成？哪些数据只需要维护一次，后续希望系统自动带出？如果半年后PLM项目成功落地，你认为研发团队的工作会发生什么变化。
最终IT部门要把所有调研成果沉淀为6份可落地的交付物：《研发PLM现状业务流程图》《研发产品数据对象清单》《研发产品数据RACI责任矩阵》《研发PLM痛点与需求清单》《研发工作量减少/自动化机会清单》《PLM一期MVP业务范围建议》，让PLM系统从诞生之初就完全扎根于研发业务的真实需求，最终实现“用数据提效，而不是用系统增负”的核心建设目标，为企业的研发管理数字化转型打下坚实的基础。
如果您在PLM需求挖掘方面有困惑，可以联系简睿捷，简睿捷可以协助您解决需求调研的问题。
简睿捷是长三角制造企业数字化转型优选服务商，提供PLM、MES、设备数据采集等产品与数字化转型服务，为企业提供从项目调研、方案设计、上线实施到后期运维全流程陪伴，一站式提供制造企业 PLM 落地服务。
南京简睿捷软件开发有限公司凭借本土工业软件实施经验、一体化 PLM/MES/MDC 产品矩阵、全流程落地咨询服务，能够针对性化解各类实施风险，帮助制造企业少走弯路，真正实现研发数据标准化、跨部门协同高效化，发挥 PLM 产品全生命周期管理的数字化价值。
需求中心
AI助手
联系我们
返回顶部