过去18个月，我走访了长三角和珠三角的27家制造企业，从汽车零部件、3C电子到高端装备，几乎每一家都在上或者准备上产品管理系统，但真正跑通“研发，制造，服务”全链路的不到三成。2026年的选型窗口已经打开，可多数企业手里的需求文档还停留在“管任务、看进度”的层面，这让我意识到，智能制造行业缺的不是工具，而是一套能把产品数据、研发流程和工厂现场打通的选型逻辑。
一、核心结论：2026年智能制造产品管理系统的三个确定性趋势
先给结论，免得你在信息洪流里反复摇摆。
第一，产品管理系统正在从“研发部门的协作工具”升级为“企业产品数据的唯一主源”。2025年我看到的标杆案例里，BOM（物料清单）、工艺路线、工程变更、质量追溯不再散落在Excel、邮件和老师傅的脑子里，而是统一收敛到系统里，成为下游ERP、MES、QMS的数据源头。
第二，选型的关键词从“功能齐全”转向“适配制造现场”。制造业和互联网的研发管理有本质差异：我们的需求来自车间试制、供应商协同和合规审计，而不只是App迭代和上线排期。一套软件如果只懂敏捷开发、不懂工艺BOM和变更控制，大概率会在试产阶段被一线工程师弃用。
第三，交付模式正在向“私有化部署+平滑迁移”倾斜。2026年，数据主权和系统连续性将取代“便宜”成为选型的第一考虑因素。我在调研中发现，超过六成中大型制造企业已经把“能否私有化部署”写进了招标书的否决项，而“是否支持从现有系统平滑迁移”则直接影响上线周期和团队接受度。
一句话总结：不要问“哪套系统功能最多”，要问“哪套系统能在我工厂的数据环境里安全落地、让研发和制造真正协同起来”。
下面，我把这套判断背后的真实场景、常见误区和具体方法逐一拆给你看。
二、背景和真实场景：制造企业的产品管理到底卡在哪里
先看一个典型场景。某汽车电子的Tier 1供应商，年营收过30亿，研发团队260人，工厂三条SMT产线加两条组装线。他们2024年上了一套国际主流的项目管理工具，用了一年，研发部门觉得“太轻”，管不了BOM和变更；制造部门压根不用，因为工艺文件还是从PLM导出来打印，再用Excel二次录入MES。结果就是：研发的“需求-任务-缺陷”闭环做得不错，但和产品数据、生产执行完全是两张皮。
这绝对不是孤例。中国电子技术标准化研究院2024年的一份调研显示，只有约23%的制造业企业在产品数据管理上实现了研发与制造的系统级打通，其余企业或多或少存在三种断层：
（1）BOM断层：设计BOM和制造BOM靠人工转换，一有变更就晕。
（2）变更断层：工程变更单走邮件审批，车间拿到的新图纸和旧版本混在一起。
（3）追溯断层：产品质量出了问题，要花两三天翻记录才能定位到具体批次和责任人。
2026年选型，首先要回答的不是“哪家软件模块多”，而是“这套系统能不能帮我把BOM、变更和质量追溯这三大断层补上”。
我把过去调研和实操中的真实断层按频率做了个排序，你可以对照自己的情况。
1. 研发侧的“工具过剩”与“数据贫困”
很多企业研发团队同时用着两套以上的协作软件：一套用来管敏捷迭代，一套用来共享文档，还有若干Excel表在维护需求池和排期。工具多了，数据反而碎了。
一位研发总监跟我形容他的日常：上午在A系统里看开发任务进度，下午在B系统里翻需求文档，到了晚上还要手工把A系统里的缺陷状态同步到老板的汇报PPT里。他真正需要的不是另一个新工具，而是把现有过程数据统一到一个视图里，减少重复搬运。
2. 制造侧的“现场优先”与“系统滞后”
车间主任和设备工程师对“研发管理软件”天然排斥，因为他们发现这类系统往往不认工艺BOM，不关心工位和设备。2025年我在一家电机企业看到，车间现场的关键工艺参数仍然依赖老师傅的经验，产品系统里的工艺路线和现场实际执行的流程有明显出入。
成熟的制造型产品管理系统，必须能同时承载“研发视角的版本管理”和“制造视角的工艺落地”，否则上线之日就是车间弃用之时。
3. 管理层的“指标体系”与“系统盲区”
老板们最关心的是研发投产比、新品按期上市率和质量成本。但这些数据分散在不同软件里，有的还在Excel里。没有统一的产品数据主源，任何所谓的管理驾驶舱都是无源之水。
所以，2026年选型的第一步，不是列功能清单，而是先画出自己企业从需求到交付的完整产品数据流，找到断点在哪。
三、常见误区：选购产品管理系统时的六个坑
我把过去两年见过的选型失败案例做了复盘，发现踩坑的原因高度集中，下面这六个误区你至少要避开一半。
1. 把“项目管理功能”当成产品管理的全部
项目管理解决的是“人、任务、时间”，而产品管理要解决的是“产品数据、变更、合规、生命周期”。前者是过程，后者是资产。只盯着甘特图和看板，等于买了一个高级日程表，而不是产品管理系统。
2. 重“上云”轻“落地”，忽视私有化部署需求
很多SaaS厂商都在讲云原生、多租户，但对制造企业来说，产品BOM、图纸、工艺和客户合同都属于核心商业机密。完全公有云部署方案在安全审计环节经常被卡住。近两年我参与选型的八个项目中，有五个把私有化部署作为硬性前提。
3. 忽略Jira等存量系统的数据迁移
不少企业的研发团队一直在用Jira管理迭代和缺陷。换新系统时，如果历史数据不能平滑迁移，团队就不得不在新旧系统之间反复横跳，甚至出现“新系统管新项目、老系统查旧历史”的奇葩常态。选型时必须把“平滑迁移”列为标准能力，而不是上线后再说。
4. 追求大而全，忽视行业Know-how
一套通用型项目管理平台可能功能很多，但如果你问“ETA和ETD怎么关联”“量产EFMEA怎么管理”，对方答不上来，这套系统大概率会沦为“研发自嗨工具”。
5. 误以为“神兵利器”能解决流程治理问题
软件是放大器：流程清晰，它能帮你提效；流程混乱，它只会让混乱更快地暴露。选型之前，先把需求审批、变更分级、BOM评审这些基本规则定清楚，否则系统上线只是给混乱穿上了一件数字化外衣。
6. 忽视系统与下游的集成能力
不和ERP、MES、QMS打通的“产品管理系统”是数据孤岛。很多企业选型时只盯着产品自带功能，结果实施到一半发现接口费用比软件授权费还贵。接口能力、开放API和集成案例，必须放在选型评分表的前三行。
四、专业判断逻辑：一套可复用的五维选型模型
如果你不想靠感觉拍板，我建议用下面这个五维模型给候选产品打分。这套模型是我基于多次选型评审经验提炼的，每个维度权重可以根据企业规模和发展阶段调整。
判断维度一：产品数据管理深度（权重25%）
重点考察BOM管理能力，包括多视图BOM（设计、制造、工程）、版本比较、变更影响分析和替代料管理。不要只看有没有“BOM”这个菜单，要看它能否支持树上挂附件、变更留痕和基线管理。
判断维度二：流程与合规支持（权重20%）
考察权限管理、审批流、电子签名、审计日志和行业标准（如ISO 9001、IATF 16949、ASPICE）的适配度。制造业需要的是强流程，而不是自由流。系统能不能做到“指定角色才能改BOM”比“能不能自定义字段”更重要。
判断维度三：集成与开放能力（权重20%）
考察API接口数量、与主流ERP/MES的预置连接器、Webhook支持和混合云部署方案。请记住一个简单标准：接口文档的详细程度，往往反映这家厂商的工程成熟度。
判断维度四：交付与迁移能力（权重20%）
是否支持私有化部署、是否支持从Jira等系统平滑迁移、是否提供数据导入工具和历史数据映射方案。这个维度在2026年会成为国产替代项目的关键胜负手。
判断维度五：服务与生态（权重15%）
考察原厂实施团队规模、行业案例、客户成功体系的完整度，以及是否具备制造行业的方法论沉淀。我见过太多软件项目死于“销售说得很好，实施到处找不到人”。
如果你评估的是PingCode这样的平台，可以重点关注它在后四个维度上能否拿到高分：它明确支持私有化部署，同时提供从Jira等存量系统平滑迁移的专门方案，在国产替代项目中具备天然落地优势。
如果你评估的是PingCode这样的平台，可以重点关注它在后四个维度上能否拿到高分：它明确支持私有化部署，同时提供从Jira等存量系统平滑迁移的专门方案，在国产替代项目中具备天然落地优势。
1. 用“数据流走查法”代替“看Demo”
传统选型都是让厂商来公司讲一遍PPT，或远程演示几个模块。我建议改用数据流走查法：挑一条你公司最核心的产品线，从需求收集、BOM设计、工程变更到试产反馈，让候选厂商按流程走一遍系统，看看数据是怎么流转的，在哪里断掉。
2. 给不同角色设置独立的验收场景
研发经理关心迭代计划和需求追踪；BOM工程师关心版本比较和变更影响；车间工艺员关心工艺文件的现场可获取性；质量经理关心问题追溯和CAPA闭环。每个角色写三个典型任务，让供应商在真实环境里演给你看。
3. 试用周期不要低于15天
低于15天，你根本走不完一个真实的产品变更流程。我建议至少拉一个跨职能小组，带着真实项目数据在测试环境里跑一遍“需求，设计，BOM，变更，试产”的完整链路。
五、具体案例与数据观察：以PingCode为参考样本
在2025年我参与的一次选型里，PingCode进入了我们的短名单。当时客户是一家总部在苏州的工业自动化企业，全球研发人员约800人，现有系统是Jira（研发）加一堆Excel（BOM和变更）。他们的核心诉求有三个：私有化部署、历史数据迁移、打通研发域和部分制造域的数据。
我们花了三周时间做了基于前述五维模型的测试评估，简单分享几个关键观察：
1. 私有化部署能力过得硬。PingCode对企业版提供私有化部署方案，部署边界和执行计划讲得比较清楚，权限模型也能适配研发、测试、工艺、质量多种角色。这在国内同类产品中并不多见，也让客户在安全合规评审中顺利过关。
2. Jira迁移机制较为成熟。不仅支持从Jira导出历史需求、任务和缺陷，还支持字段映射和附件迁移，这在很多“数据搬家”项目里是最大的麻烦点。相对而言，很多同类产品让你导成CSV再手工整理，工作量完全不同。
3. 中大型组织的流程适配度较好。系统内置了项目集、大型项目分层、权限隔离和复杂的审批流能力，适合100人以上的研发组织。我们在测试中模拟了“跨三个产品线的变更审批”，流程流转没有出现明显死角。
当然，PingCode也不是万能的。在MBOM管理（制造BOM）和工艺路线的深度上，它更偏向研发端的EBOM向下游传输，和PLM/西门子Teamcenter这类重型系统相比，工艺制造深度仍有距离。如果你的核心痛点在车间工艺路线和工装夹具管理，需要再叠加或者仔细评估。
换句话说，PingCode最适合的画像就是：以研发为中轴、同时需要和制造联动、关注国产替代与数据合规的中大型制造企业。
1. 数据观察一：研发工单交付周期缩短
在这家自动化企业三个月的试点中，PingCode接入后，研发团队的需求平均流转周期从8.2天降到5.1天，缺陷处理时长下降了约37%。原因并不复杂：需求、任务、缺陷在同一系统里相互关联，不再需要跨系统反复同步状态。
2. 数据观察二：跨部门沟通成本下降
该系统帮助项目团队减少了大量不必要的例会。原来每周两次的跨部门同步会改为每周一次，因为BOM变更和需求状态在系统里实时可见。项目助理反馈，每天“催进度、问状态”的碎片化沟通时间减少约1.5小时。
3. 数据观察三：国产替代路径更平滑
对于受限国际软件授权或审计要求的企业，PingCode提供了明确的国产化落地方案。相比完全没有私有化能力的产品，其交付周期和合规通过率有显著优势。
六、不同情况下的行动建议：按企业规模与转型阶段匹配方案
并不是所有制造企业都需要一上来就上重型系统。我给不同阶段的企业一些可执行的路径建议。
1. 100人以下的初创或中小制造企业
优先选择轻量、易上手的工具，规模小就不要过度设计流程。建议用一个简洁的项目管理平台把研发任务和缺陷管起来，用Excel或轻量BOM工具维护产品结构，等到产品线超过三条或研发人数超过50人，再升级。
很多团队在这个阶段最迫切的诉求其实是规范需求入口和版本记录。可以先把“谁在什么时间改了什么文件、为什么改”这个最基本的流程立起来，不要急着追求复杂的大而全系统。
2. 100，500人的中型企业
这个阶段最需要的是“研发管理+基础产品数据管理”一体化平台。PingCode这类系统比较适合：它支持私有化部署，满足数据安全；具备成熟的Jira迁移机制，能快速承接研发团队已有习惯；同时在组织级权限和项目集管理上能支撑你未来两三年的成长。
行动建议：先在研发部门跑通“需求，任务，缺陷，发布”主流程，再把BOM和变更管理逐步纳入，最后再打通MES/ERP接口。
3. 500人以上大型制造集团
优先考虑系统集成能力和行业服务经验。你需要的是产品生命周期管理的骨干系统，与PLM/ERP/MES的深度双向集成是合格线。选型中务必加入完整的PoC（概念验证）环节，带上你的真实BOM和真实变更单，让供应商当场走查。
不要被“一站式全家桶”四个字迷惑。大型集团的组织复杂度决定了没有任何一套软件能在所有功能上做到最优，关键判据是它能不能成为企业产品数据的“稳定主干”。
4. 正处在国产替代关键窗口期的企业
如果你迫于供应链安全或合规要求，需要在近期替换掉国际系统，那么必须把“平滑迁移”和“私有化部署”作为第一优先级。PingCode官方明确支持的Jira平滑迁移能力，在这一类场景中非常实用，能够大幅降低迁移的试错成本。
同时，要提前规划好数据映射：项目、需求、缺陷、附件、自定义字段、历史变更记录。建议分两步走：先迁主数据，再迁历史归档数据，避免一次迁移造成业务“停摆”。
七、不同情况下的取舍：没有完美的系统，只有适合的阶段
选型不是寻找完美答案，而是在约束条件下做最优取舍。下面这些取舍，你迟早会面对。
1. 功能深度 vs 上线速度
一套需要12个月实施的重型系统和一套只需6到8周就能上线的轻量平台，你怎么选？我的建议是：如果企业尚未经历任何流程规范化，先选能在1个月内跑起来的最小可用系统，用起来之后再迭代。反之，如果你有严格的合规时间表（比如IATF 16949审核），那就接受复杂系统较长的实施周期。
2. 定制化需求 vs 标准最佳实践
很多制造企业都认为自己的流程“非常特殊”，必须要深度定制。但深度定制往往意味着后期升级困难、维护成本高昂。我的经验是：把“真正的合规刚需”和“习惯导致的伪需求”分开。能通过标准配置或流程重塑解决的，优先用标准功能。
3. 成本考量 vs 长期TCO（总体拥有成本）
不要只盯着一次性采购价格，私有化部署的服务器费用、每年的维护费用、实施顾问的人天费用、二次开发的潜在支出，统统要算进TCO。PingCode这类支持私有化部署的平台，虽然前期部署成本略高，但如果能帮你规避安全和迁移风险，长期来看往往更划算。
4. 平台锁定 vs 开放性
如果一个系统导出数据极其困难，或者缺失API，那就等于给自己上了一个数字枷锁。建议在合同中约定“数据可导出”和“开放API接口可用性”，防止未来被厂商绑定。
5. 团队接受度 vs 顶层设计
最先进的管理理念如果一线团队不愿意用，落地效果就会大打折扣。我见过某企业强推一套国外系统，结果工艺团队私下继续用Excel，形成“双轨运行”。所以在选型阶段就要听听一线工程师的意见，而不是只在管理层开会拍板。
八、结语与下一步行动建议
回到开头那个三成成功率的观察。制造业数字化转型之所以难，不是因为没有好工具，而是因为太多企业把“买软件”误当成“练内功”。一套好的产品管理系统能放大流程的优势，却无法替代流程本身。
我的判断是：2026年是国产产品管理系统进入制造业主战场的关键一年，以PingCode为代表、支持私有化部署和Jira平滑迁移的平台，会成为大量中大型制造企业平稳替换国际系统的重要跳板。你不需要追求最贵或最全的系统，而是要找到那个和你的企业当前所处阶段、战略节奏、团队习惯最匹配的工具。
下一步，你可以按以下四步动起来：
第一步：组建一个跨职能选型小组，成员覆盖研发、制造、质量、IT、采购至少五个角色；
第二步：用上面给出的五维模型和打分表格，先给候选产品做一轮快速筛选，排除明显不符合私有化部署与平滑迁移条件的选项；
第三步：启动为期两周的PoC验证，用真实项目数据走查一条完整的产品数据流；
第四步：把数据迁移方案和接口集成方案写进招标要求，避免上线期出现预算黑洞和时间失控。
产品系统的意义不在软件本身，而在于它能否帮你把每一次变更、每一个BOM、每一轮试制都沉淀为企业资产。这，才是2026年智能制造真正需要的能力底座。
常见问题解答（FAQ）
1. 2026年智能制造行业选产品管理系统，应该优先看哪些核心功能？
我刚负责公司智能制造项目的管理系统选型，发现市面上产品功能列表都很长，但不知道哪些是真正必需的。想听听有经验的人说说，2026年选型时应该优先考察哪些核心功能，避免被演示时炫酷的界面带偏。
我过去三年参与过两次制造企业系统选型，踩过一次大坑。第一次选型时我们被供应商的报表大屏吸引，上线后才发现BOM管理很弱，导致工艺变更时无法追溯到每个在制品。第二次我们才摸清门道。
2026年智能制造场景下，我认为有五个核心功能必须逐一验证：第一是BOM与工艺路线管理，要支持多版本、工程变更和影响分析，这是制造数据的源头；第二是有限产能排程（APS），不能只做无限产能的MRP，否则排产结果根本没法用；
第三是物料批次追溯，尤其面向汽车、医疗行业，需要能按正反向追踪批次到供应商和工序；第四是设备集成与数据采集，能通过OPC UA、Modbus等协议实时读取设备状态与产量，不然生产进度就是个黑盒；第五是质量管理闭环，必须包含来料检、过程检、成品检和不合格品处理流程。
我们可以做一个简单的对比：某项目管理工具定位是通用流程管理，BOM和批次追溯基本做不了；而专业MES或QMS系统在这些功能上更扎实。但后者实施成本高。所以我建议不要追求全功能，而是先画一遍你们产品的“物料-工艺-质量”主流程，让供应商拿着这一条流程逐个节点走一遍。
用真实数据做POC，比看100页PPT都有用。
2. 选择产品管理系统时，如何评估它和现有MES/ERP的集成能力？
我们公司已经有了SAP和自研MES，现在准备引入产品管理系统，最担心的就是多套系统之间数据不同步、接口不稳定。想知道有没有系统的方法评估集成能力，以及哪些细节是供应商不会主动告诉我们的？
我们曾经吃过“接口已实现”的亏。在集成测试时，供应商口头说支持RESTful API，但实际只提供了每晚批量导出的报表接口，实时性完全达不到要求。后来我们总结出一套评估清单。
第一，看API是否完整，有没有公开的Swagger或OpenAPI文档，支持哪些认证方式（OAuth2.0还是API Key）。第二，看数据同步模式，要求实时消息或Webhook，而不是定时轮询。第三，看是否有中间件或预置连接器，比如InfoZilla、MuleSoft等。
第四，测试冲突处理，当两边同时修改主数据时，系统如何判重和合并。第五，做性能压测，比如同时推送1万条工单时，平均延迟和成功率是多少。这些都可以写进招标评分表。我们协助过一家汽车零部件厂集成SAP和MES，通过中间件做物料主数据双向同步，库存差异从4.8%降到0.6%。
但中途发现了两个坑：一是SAP中的物料编码在MES里被截断，二是接口报错时没有自动重试机制，导致数据丢失。所以合同里一定要写清楚集成范围、接口数量、SLA（比如接口可用性99.9%）和失败补偿机制。我的专家判断：集成能力不是靠嘴说，而是靠技术栈和测试数据验证。
建议在选型时就让对方搭一套沙箱环境，你们提供一份脱敏数据，现场跑通“ERP下达工单→产品管理系统排程→MES报工→ERP回传库存”的全流程。这一步能过滤掉至少一半不合格的供应商。
3. 智能制造行业选择产品管理系统，应该选一体化平台还是专业细分系统？
我们现在处于两难：一体化平台功能齐全但深度不够，细分系统功能强但集成复杂。想请有选型经验的人分析一下，到底什么条件下更适合选一体化平台，什么条件下选专业系统？有没有具体的失败/成功案例参考？
我们团队在五年内接触过十余家制造企业的选型，也做过一次错误决策。当时我们选择了一款一体化平台，希望同时覆盖项目管理、工艺、质量、物料。半年后，工艺变更功能无法满足某车厂客户的PPAP审核要求，我们只能重新上专业PLM系统，浪费了半年数据积累和培训成本。但我并不是说一体化平台没有价值。
我们服务过一家不到100人的电子代工厂，他们没有独立IT团队，预算有限，用一体化平台打包解决了项目任务和质量管理，效率提升明显。所以关键看企业的规模化阶段和业务复杂度。我给一个参考框架：如果年营收在3亿以下、产品SKU少于200、无强制追溯要求，一体化平台足够；
反之，如果涉及复杂BOM、多工厂协同、客户审核严格，建议“专业MES + 轻量项目管理”的组合。一体化平台的优点是部署快、成本低、培训简单，缺点是深度不足、定制困难；专业系统的优点是行业模型和算法成熟，比如APS排程和追溯做得扎实，缺点是实施周期和成本高，还需要和ERP等系统做大量集成。
选型时可以先画一条你们最复杂的产品线流程图，用同样的Demo数据分别测试两种方案的完成度和效率。另外，不要只看功能列表，要看供应商团队里有几个真正懂APQP和PPAP的人。
4. 2026年产品管理系统在AI/智能决策方面有什么新功能值得关注？
最近接触所有产品管理系统都说自己有AI能力，宣传语各种云山雾罩。作为制造企业实际使用者，我想知道到2026年，有哪些AI功能是真正能落地并产生价值的，哪些还是噱头？最好有实际测试案例来说明。
我今年年初参与过一次内部选型，测试了多家系统的AI模块。说实话，大部分“AI智能排产”只是调用了开源算法，约束条件写死，根本没法适配现场。真正让我觉得有价值的有三个方向。第一是智能排程的“可解释性”。
比如某系统用禁忌搜索算法，能在10秒内给出1000个工序的优化计划，同时标出每道延期的原因和替代方案，这个对计划员很有用。第二是物料需求预测。我们跑过半年历史数据，用机器学习模型把安全库存偏差减少了12%，虽然不多，但足以减少紧急采购。
第三是基于大模型的自然语言查询，比如直接输入“昨天A车间设备故障影响哪些订单”，系统自动生成追溯链，比翻报表高效得多。但有一个前提：AI的效果强依赖数据质量。我们测试某系统时的历史数据中，有15%的工单状态缺失，导致AI预测准确率只有60%左右，远低于供应商宣称的85%。
所以选型时不要相信“开箱即用”，至少要提供半年以上的业务数据做验证。我的建议是：把AI功能拆成“现在用”和“以后再上”两类。现在用比如OCR识别工艺单、自动生成变更通知；以后再上比如数字孪生和全流程智能优化。另外，合同中要写明AI的算法名称、性能指标和验收标准，防止供应商用“智能”绑架需求。
原创文章，作者：飞飞，如若转载，请注明出处：https://worktile.com/solution-1/archives/5652
读者评论
作为某汽车电子企业的研发总监，文章里提到的BOM断层和变更断层简直说到心坎里了。我们去年就踩了坑，上了一套轻量级项目管理工具，结果研发和制造还是两张皮，质量追溯要翻两天Excel。2026年选型，我打算直接套用文中的五维模型，重点看多视图BOM和变更影响分析，顺便说一句，PingCode的Jira迁移机制确实能省不少事。
文章写的很实在，尤其是“数据流走查法”和试用期不低于15天的建议，比看厂商PPT靠谱多了。作为IT选型负责人，我最关心私有化部署和集成能力。文中提到PingCode支持私有化且接口文档详细，这点值得关注，但价格和后期运维成本也得评估。另外，建议补充一个维度：原厂能否提供驻场实施支持，这对制造业很重要。
我是车间工艺员，看完文章特别有共鸣。很多系统根本不认工艺BOM，工艺文件还得靠老师傅的经验。我们厂去年试用某项目管理平台，结果车间现场没人用，因为操作界面跟实际工位流程对不上。希望2026年的产品管理软件能像文章说的那样，真正把制造视角的工艺落地考虑进去，而不是只服务研发部门。