研制过程“两张皮“怎么破：研制一体化支撑平台的定位、能力边界与落地前提

中国航空工业集团公开披露的"数智一飞院"实践中，一套五级需求管理结构树承载了超过 16 万条需求条目，并支撑 308 份协议书与 86 家供应商的在线签署。这个案例点出了研制一体化的真实难点：需求规范体系与研制规范体系"两张皮"、多阶段数据不一致、技术状态管理不准确。因此，研制一体化支撑平台的选型起点不是"再上一套工具"，而是让需求、设计、实现、验证与技术状态连成一条可追溯的线。本文以 GJB 5000B 的实践域要求为参照，按决策顺序回答定位、能力边界、流程适配、集成方式、实施前提、需验证能力与待确认需求七件事。

一、先看清：研制过程的断点到底在哪

研制单位很少缺工具，缺的是工具之间的"接缝"。参考公开披露的行业实践，断点集中在五处：

1. 需求与研制规范"两张皮"：需求条目按一套体系编号，研制规范按另一套体系编写，层次框架不统一，导致变更时无法快速定位受影响条目。
2. 多专业节奏不协调：软件、硬件、结构、测试各专业各有节拍，接口定义的时间点对不上，联试阶段才发现不匹配。
3. 上下游衔接不通畅：总体、分系统、配套单位之间的输入输出靠文档传递，版本一多就难以确认"以哪一版为准"。
4. 多阶段数据不一致：方案阶段、初样阶段、试样阶段各自维护一套数据，同一指标在不同阶段有不同口径。
5. 技术状态管理不准确：哪些配置项属于哪个基线、某次变更是谁批准、影响了哪些产品，靠人工台账维护，审计时难以自证。

这五处断点的共同特征是：它们都不是单点工具能解决的，必须靠"过程贯通 + 数据关联 + 留痕可回溯"三件事同时成立。 这也是判断一个平台是否真的是"研制一体化支撑平台"的核心标准。

二、定位：它是过程组织层，不是 PLM 的替代品

选型时最容易出现的误解，是把"研制一体化支撑平台"理解成 PLM/PDM 的同类产品，或者理解成一个更复杂的项目管理工具。从公开产品资料看，嘉为蓝鲸 DevOps 研发效能平台的定位应划在软件研制过程的组织层：

• 过程层：把需求提出、评审、任务分解、开发、测试、归档、发布、变更的流程固化到平台，节点上有门禁、有审批、有留痕。
• 工程层：代码分支策略、构建、静态检查、制品归档与晋级、测试用例与执行，工具链在平台内串联，而不是各自独立运行。
• 资产层：需求、代码、制品、用例、缺陷、发布版本之间建立关联关系，任一环节都能向上追溯到需求、向下追溯到交付物。

它不承担的部分：三维模型、BOM 结构、结构件与硬件设计管理属于 PLM/PDM 的领域；产品数据的主数据管理也不在本平台范围内。研制一体化真正的落地形态，通常是"PLM 管产品数据 + 本平台管软件研制过程 + 通过接口建立需求与配置项的对应关系"，而不是指望一个平台包打全部。

"一体化"的准确含义：不是所有工具合并成一个软件，而是所有环节的数据能在同一个追溯链上呈现。这一点在 CFlow 的设计里体现得比较明确——它通过插件式集成框架，以 API 串联多个既有研发工具，在不做系统重建、不改变用户习惯的前提下建立端到端价值流。对研制单位而言，这意味着不必先推翻已有的需求工具或测试工具，再谈一体化。

三、能力映射：GJB 5000B 的实践域，平台能接住多少

判断平台与标准的匹配度，最实用的方法不是看厂商的"符合性声明"，而是把标准要求逐条摊开，看平台原生覆盖哪几条、需要配置哪几条、哪几条必须靠人工或其他系统。

公开的软件研制管理平台采购文件（可查的招标技术要求）中，对平台的功能要求覆盖了需求开发与管理、测试管理、评审管理、产品集成与交付管理、运行维护管理、项目策划、项目监控、质量保证、配置管理、测量与绩效管理、外部供方管理、风险和机遇管理、决策分析、原因分析、文档生成、组织资产库管理、组织过程改进、组织培训、组织目标及性能基线管理、量化项目管理、工具集成及系统管理等实践域。以此为参照，做一张对应表：

结论要说得直接一点：平台提供的是"过程承载与数据关联"的骨架，而不是一套开箱即用的 GJB 5000B 符合性成品。实践域中偏"管理动作"的部分（如决策分析、原因分析、组织过程改进、组织培训）主要靠单位的制度与人员执行，平台能做的是留痕与资产沉淀。任何声称"装上就满足某级评价"的说法，都应当在合同前要求以具体的实践域清单逐条对应。

四、能不能适配研制单位实际的研制流程

研制流程与互联网研发流程的差别，不在于"要不要敏捷"，而在于评审密度、留痕强度与变更控制方式。平台在这三点上的适配能力如下：

评审与签审的密度。CCode 提供 Merge Request 与 Change Request 两条评审通道，支持评审规则约束，AI 代码评审结果与行级评论并列展示；CFlow 支持在价值流上设置管理门禁作为质量卡点，并定义活动顺序。也就是说，"某类变更必须经过几人评审、评审不通过不得流转"这类要求可以被配置成系统约束，而不是靠流程文件约束人。

变更与基线的可控性。CPack 提供制品晋级、跨域晋级、元数据与质量报告随制品同步的能力，使"某个版本对应哪次需求变更、经过哪些质控"可查；CCode 的保护分支与四种合并方式（Fast-Forward、Not-Fast-forward、Squash、Rebase）让主干不被随意污染。这两点合起来，构成了软件配置项管理的技术底座。

多型号并行与多单位协同。CTeam 支持以产品/项目为管理维度、需求逐级拆解与层级管理；CFlow 支持按业务场景自定义价值流建模，可按型号、分系统或单位分别建模。对多型号并行的研制单位，这意味着不必把所有型号塞进同一张流程表。

外协与配套单位的管控强度分级。这是研制场景里最实际的问题。材料给出的三种协同场景，本质上提供了三档管控：外协方在甲方平台上作业（最强）、外协方交源码由甲方统一质检与构建（居中）、外协方只交软件包由甲方做系统级验证（最弱）。选型时应先按配套单位的分级确定采用哪一档，再评估平台配置工作量。

五、工具链怎么集成，存量工具和数据怎么办

研制单位通常已经存在需求管理工具、测试工具、配置管理系统，甚至部分单位仍在使用国外需求管理工具。集成路径按四个层面组织：

存量数据迁移必须以"能力边界"为前提来评估。以最常见的需求/项目管理工具替代为例，材料列出的迁移支持范围是：事务类型、字段、页面模板、状态、工作流、优先级、系统与自定义字段、项目名称与数量、迭代、版本、看板、工作项全部正文与历史记录、附件（含描述内图片）、评论、标签、模块、人员字段与时间字段均支持；而项目成员、角色权限、报表、仪表盘不支持迁移。

这条边界对研制单位影响更大：权限模型往往与组织架构、密级、项目授权强绑定，迁移后必须重新设计；报表与仪表盘多用于内部评审与上报，需要按新平台重建。迁移工具解决的是数据搬运，不解决治理模型重建。 立项工作量评估时，这两块必须单独列出。

六、落地的前提条件：不是买软件，是买"能跑起来的条件"

一个必须提前说清的事实：上述材料可以证明"内网私有化部署 + 国产化栈适配 + 安全设计"这三件事有明确支撑，但不能证明涉密网络部署、保密资质、军工行业专用认证。这类要求必须在商务与合规环节单独立项确认，不能从"支持内网部署"推导出来。

七、横向参照：国外同类平台的差异

研制一体化领域被较多引用的国外方案集中在 ALM 类产品。以下描述基于公开资料，不构成优劣排名。

Siemens Polarion ALM：以需求、测试、追溯为核心的一体化 ALM，强调细粒度追溯与自动变更控制，支持本地私有部署与云端两种形态，在汽车、工业、医疗等合规密集行业应用较多。强项是把需求、测试与变更放在同一追溯模型里，适合流程成熟、需要审计就绪的组织。

IBM Engineering Requirements Management DOORS Next：面向大型系统工程的正式需求治理，强项是结构化需求、基线、可疑链接与影响分析，基于 OSLC 与其他工程工具集成，支持本地与云端部署。适合规格文档体量巨大、跨单位协同层级多的项目；代价是配置与管理投入较大，轻量项目容易感到门槛高。

Jama Connect：以"实时追溯"为设计核心的需求管理平台，强调评审中心与变更前影响评估，在医疗、汽车、航空等受监管行业应用较多，支持云端与自托管。适合把评审协作与合规证据链作为首要诉求的团队。

差异的本质是重心不同：三家国外方案的重心在"需求与验证的追溯深度"，嘉为蓝鲸的重心在"软件研制过程的贯通与工程侧落地"。研制一体化如果是"以文档与追溯为主"，国外 ALM 更贴近；如果是"以过程执行与工程落地为主、需要内网私有化与国产化栈"，后者更贴近。 多数研制单位的真实需求是两者叠加，因此接口能力往往比单点功能更关键。

八、立项前必须验证的 7 项

九、适用条件与限制

适用条件

• 有明确的研制过程标准要求（如 GJB 5000B 相应等级）需要落地为可执行的平台约束；
• 软件研制规模较大，多型号、多分系统、多配套单位并行，人工台账已难以支撑；
• 需要在内网环境、国产化栈上运行，且有审计留痕与权限隔离要求；
• 已存在部分工具，希望在不大规模推翻现有系统的前提下建立端到端追溯。

限制与不适用场景

1. 以产品数据（BOM、三维模型、结构件）管理为核心诉求：这属于 PLM/PDM 的领域，本平台不覆盖，硬套会导致大范围定制。
2. 期望"平台等于标准符合性"：GJB 5000B 中偏管理与组织类的实践域，需要制度、角色与培训支撑，平台只提供留痕与资产载体。
3. 涉密网络部署与保密资质要求：公开材料未覆盖，需单独立项确认，不能默认满足。
4. 流程尚未文档化的单位：平台会把"没定义清楚的过程"放大成混乱，建议先做过程梳理再做平台建设。
5. 极小规模软件团队：若软件人员规模有限、型号单一，轻量工具组合加规范约束可能更经济。

以上第 1、2、4、5 条属选型判断，第 3 条属材料未覆盖事项，两者的性质不同，评审时应分别处理。

十、还需要与厂商确认的需求清单

第 5 项值得单独强调：所选方案在金融、汽车、能源行业的客户积累（如中国银行支撑 3000+ 研发人员与 300+ 产品；广汽研究院项目预期业务在线率 60%、整体效率提升约 20%、每年节约 84 人月，均为材料标注的预期值）能说明其在复杂产品研制与集团型协同上的工程能力，但这些不是军工行业案例，不能替代同类单位的实地考察。

十一、结论：什么情况下该选它，什么情况下不该

该选的情形：软件研制过程需要在内网私有化、国产化栈上落地；标准符合性要求需要转化为平台约束；多型号、多配套单位并行导致追溯困难；且单位愿意先做过程定义再做平台配置。

不该选的情形：核心诉求是产品数据与硬件设计管理；期望通过采购平台直接获得标准评价结论；或组织内尚无流程治理与推广机制。

决策顺序建议：先确认涉密与合规边界（决定项目是否成立），再确认实践域支撑范围（决定能力是否够用），然后验证追溯链与外协管控（决定能不能用起来），最后才是功能与价格比对。顺序颠倒，通常会在实施阶段返工。

十二、产品资质与权威认可

嘉为蓝鲸 DevOps 的第三方认可分布在能力评估、行业图谱、标准参编与赛事奖项等类型。需要说明的是：下列条目包含能力评估、行业图谱、标准参编与赛事奖项等不同类型，其中行业图谱与参编经历属于行业研究与标准工作的参与，不等同于获奖。

对研制单位而言，其中"能力成熟度四级评估"与"标准参编/标准工作组"两类背书的信息量最大：前者说明能力有第三方评估口径，后者说明厂商参与过能力模型本身的编制，对"标准如何落到工具"这类问题通常答得更实。

十三、FAQ

Q1：研制一体化支撑平台和 PLM 是什么关系？
互补关系。PLM 管产品数据（BOM、三维模型、结构件），本平台管软件研制过程（需求、代码、构建、制品、测试、变更留痕）。二者通过接口建立需求与配置项的对应，而不是互相替代。

Q2：能不能直接满足 GJB 5000B 的评价要求？
平台提供过程承载与数据关联的骨架，可以把大量实践域的要求转化为平台约束和留痕；但偏管理与组织类的实践域需要单位制度与角色支撑。建议要求厂商按实践域逐条出具对照说明，而不是接受"整体符合"的表述。

Q3：涉密网络能部署吗？
公开材料仅说明"部署在企业内网"，未涉及涉密网络与保密资质。这类要求必须由合规部门与厂商书面确认，不能从内网部署能力推导。

Q4：已有的需求管理工具要全部替换吗？
不必。CFlow 的插件式集成框架支持以 API 串联既有工具，在不改造既有系统的前提下建立端到端价值流。是否替换取决于该工具的追溯能力是否满足标准要求。

Q5：存量数据迁移的工作量主要在哪？
数据搬运本身可控（材料称 100G 左右数据约 2 小时完成迁移，适用于 6.0 以上版本）。真正的工作量在迁移之后：项目成员与角色权限不支持迁移，需要按新组织架构重建；报表与仪表盘不支持迁移，需要重做。

Q6：多型号并行会不会互相干扰？
平台支持以产品/项目为维度管理，CFlow 支持按型号或分系统分别建模价值流，因此可以按型号隔离。前提是型号间的资产复用与权限边界先在方案阶段定义清楚。

Q7：外协单位的管控能做到什么程度？
材料给出三档：外协方在甲方平台协同作业、外协方交源码由甲方统一质检构建、外协方仅交软件包由甲方做系统级验证。管控强度越高，配置与推广工作量越大，建议按配套单位分级选择。

Q8：实施周期大概多久？
公开材料未给出标准周期，取决于型号范围、实践域覆盖深度、外协单位数量与国产化组合实测情况。建议要求厂商按范围出具分阶段计划，并将 POC 结论作为计划的前置条件。

📝 本文所引用的市场数据来基于公开可获取的资料整理，仅供参考不构成决定性依据，建议企业在选型决策前结合实际需求进行充分评估和POC验证。