技术状态管理


技术状态管理

文章插图
技术状态管理是指在产品寿命周期内 , 为确立和维持产品的功能特性、物理特性与产品需求、技术状态文件规定保持一致的管理活动 , 主要内容包括技术状态标识、技术状态控制、技术状态记实和技术状态审核 。
本文先从几个概念的理解入手 , 再从技术状态管理的四个方面说明对技术状态管理的理解与感悟 。
一、几个概念的理解
1.1 技术状态项 技术状态项是指能满足最终使用功能 , 并被指定作为单个实体进行技术状态管理的硬件、软件或其集合体 。
1)确定时机:较高层次的技术状态项可在方案阶段初期或之前选择 , 较低层次的技术状态项可在工程研制阶段初期或之前选择 。
2)确定顺序:先进行产品工作结构分解 , 确定产品分解结构后再确定技术状态项 , 技术状态项应与工作分解结构单元对应 。
3)确定原则:并非所有的工作分解结构单元都要作为技术状态项 , 被选择作为技术状态项的产品一般是: a)武器装备、分系统级产品或跨单位、跨部门研制的产品; b)在风险、安全、完成作战任务等方面具有关键特性和重要特性的产品; c)新研制的产品; d)接口复杂且重要的产品; e)单独采购的重要产品; f)使用和保障方面需要着重考虑的产品 。
1.2 技术文件、技术状态文件和技术状态基线 技术状态文件是规定技术状态项的功能特性和物理特性 , 或从这些内容发展而来的关于技术状态项验证、使用、保障和报废要求的技术文件 。通常是直接作为产品研制、生产或使用保障依据的技术文件 , 主要包括规范、图样及其他需要的技术文件 。计算报告、试验报告等技术文件虽是产品定型所需技术文件 , 但一般不作为技术状态文件 。并非所有的技术文件都是技术状态文件 , 这句话可以从两个方面理解: 1)对于规定其他非技术状态项特性的文件非技术状态文件 。
2)对于技术状态项相关的文件 , 但没有规定其功能特性和物理特性的文件非技术状态文件 , 如计算报告等 。技术状态基线是在产品寿命周期内的某一特定时刻 , 被正式确认并作为今后研制生产、使用保障活动基准 , 以及技术状态改变判定基准的技术状态文件 。一般包括功能基线、分配基线和产品基线 。
作为技术状态基线 , 应同时满足三个条件: 1)被正式确认 。什么叫正式确认呢?依据GJB3206 , 通过按GJB3273标准执行的技术审查才叫正式确认;在日常操作中 , 由客户组织或参加 , 多方认可或正式批复的方式都可以认为是正式确认 。
2)作为今后研制生产、使用保障活动基准 。通常指研制总要求(研制基准)、技术规格书(生产基准)、使用维护说明书(使用保障活动基准)以及相关的合同、规范或要求 。(从这个角度看 , 技术设计报告、六性设计报告等都不属于技术状态基线 。)
3)技术状态改变判定基准 。通常说的是在研制、生产、使用过程中作为技术状态改变的基准 , 主要也是指研制总要求、技术规格书、使用维护说明书以及相关的合同、规范或要求 。
怎么确定技术状态基线呢?这里提供两种思路 , 都有道理 , 但没有明确规定哪种是对的 , 但考虑到技术状态管理是为了管理技术状态 , 所以名称的问题就无关紧要了 。1)站在武器系统总体的角度来确定技术状态基线 , GJB3206就是这种思路 , 技术状态管理基线表如下: 表1 武器系统总体的技术状态基线表 运用这个思路 , 那作为分承包商如何确定技术状态基线呢?GJB3206给出的思路是在这三个基线的基础上 , 在进行细分 , 如任务基线、研制基线、性能基线、制造基线等等 , 可以在概念不冲突的情况下实现技术状态可控 。
2)站在分承包商的角度来确定技术状态基线 , 具体基线如下: a)功能基线:研制合同、研制任务书; b)分配基线:方案设计报告、“六性”计划、标准化大纲、技术规范等; c)产品基线:同表1 。比较两个角度的不同 , 相对于总承包商 , 分承包商因为接触不到方案论证报告和研制总要求 , 只能把研制合同和研制任务书作为功能基线 , 并从分配基线中拿出来 , 仅此而已 。
1.3 功能特性、物理特性、功能技术状态审核、物理技术状态审核 把这两组概念拿出来的原因是因为在GJB3206中 , 类似的概念名称却有着完全不同的含义 , 废话少说 , 直接上定义了 。功能特性是指产品的性能指标和设计约束条件 , 如战术技术指标、使用保障特性等;物理特性是指产品的形体特征 , 如组成、尺寸、表面状态、形状、配合、公差、质量等 , 又称实体特性 。所以 , 两者的区别是 , 一个指的是性能指标相关特性 , 一个指的是实体特征相关的特性 , 泾渭分明 , 比较清楚 。按惯常的思维 , 那功能技术状态审核应该是对技术状态项的功能特性的审核 , 物理技术状态审核应该是对技术状态项的物理特性的审核 , 事实呢 , 不是这样的 , 看定义 。功能技术状态审核是为了验证技术状态项的功能特性达到功能基线、分配基线规定的要求所进行的技术状态审核 , 可与设计定型工作结合进行 , 审核的内容一般包括(以下内容重点是针对设计过程的 , 重点看是否满足功能基线和分配基线):
1)审核承制方的试验程序和试验结果是否符合技术状态文件的规定;
2)审核正式的试验计划和试验规范的执行情况 , 检查试验结果的完整性和准确性;
3)审核试验报告 , 确认这些报告是否准确、全面地说明了技术状态项的各项试验;
4)审核接口要求的试验报告;
5)对那些不能完全通过试验证实的要求 , 应审查其分析或仿真的充分性和完整性 , 确认分析或仿真的结果是否足以保证技术状态项满足其技术状态文件的要求;
6)审核所有已确认的技术状态更改是否已纳入技术状态文件并已经实施;
7)审核未达到质量要求的技术状态项是否进行了原因分析 , 并采取了相应的纠正措施;
8)审查偏离许可、让步清单;
9)对软件和硬件集合成一体的技术状态项 , 除进行上述审核外 , 还可进行必要的补充审核 。
物理技术状态审核是为建立或验证产品基线 , 对技术状态项试制试产样品的完工状态 , 所依据的技术状态文件而进行的技术状态审核 , 物理技术状态审核应在功能技术状态审核完成之后进行 , 可与生产定型工作结合进行 , 审核的内容一般包括(以下内容重点是针对生产过程的 , 重点是为了验证产品基线): 1)审核各技术状态项有代表性数量的产品图样和相关工艺规程(或工艺卡、下同) , 以确认工艺规程的准确性、完整性和统一性 , 包括反映在产品图样和技术状态项上的更改;
2)审核技术状态项所有记录 , 确认按正式生产工艺制造的技术状态项的技术状态准确地反映了所发放的技术状态文件;
3)审核技术状态项首件的试验数据和程序是否符合技术状态文件的规定:审核组可确定需重新进行的试验;未通过验收试验的技术状态项应由承制方进行返修或重新试验 , 必要时 , 重新进行审核;
4)确认技术状态项的偏离、不合格是在批准的偏离许可、让步范围内;
5)审核技术状态项的使用保障资料 , 以确认使用保障资料的完备性和正确性;
6)确认分承制方在制造地点所做的检验和试验资料;
7)审核功能技术状态审核遗留的问题是否已经解决;
8)对软件和硬件集合成一体的技术状态项 , 除进行上述审核外 , 还可进行必要的补充审核 。简单总结一下 , 功能特性和物理特性是从产品的特性角度分类的 , 而功能技术状态审核和物理技术状态审核与前面两个概念没有必然的联系 , 分别针对设计和生产过程 , 前者验证功能基线和分配基线 , 后者验证产品基线 。
二、技术状态标识 从字面意思看 , 技术状态标识就是对技术状态项进行标识 , 对吗?不对 , 从GJB3206看 , 技术状态标识的工作任务包括:
1)选择技术状态项; 2)确定各技术状态项在不同阶段所需的技术状态文件; 3)标识技术状态项和技术状态文件; 4)建立技术状态基线; 5)发放经正式确认的技术状态文件并保持其原件 。
这里需要说明的内容有三个:① 确定技术状态项在不同阶段所需的技术状态文件 。因为技术状态项不包括产品所有的组成单元 , 所以 , 此处的技术状态文件包括两种:一是单独规定技术状态项的技术状态文件;二是包含技术状态项的技术状态文件 。
② 标识技术状态项和技术状态文件 。如何标识呢?技术状态项的产品型号和编号 , 因为具有唯一性可作为技术状态项的标识;技术状态文件也都有文件编号 , 同样具有唯一性可作为技术状态文件的标识 。
③ 发放经正式确认的技术状态文件并保持其原件 。这个要求比较严格 , 应该制定技术状态文件发放的程序 , 经过批准后才能发放 , 并记录发放的信息 。在技术状态基线建立后 , 应控制并保持所有现行已批准的技术状态文件的原件(部分单位技术状态文件的底稿和正稿的管理方式应该是来源于此处要求) 。
三、技术状态控制 大家对技术状态控制内容相对比较熟悉 , 具体内容包括三个方面:
1)制定控制技术状态更改、偏离许可和让步接收的管理程序与方法;
2)控制技术状态更改、偏离许可和让步;
3)确保已批准的技术状态更改申请 , 及偏离许可、让步申请得到准确实施 。
技术状态控制的内容可分为两个部分来说明 , 一是技术状态更改 , 二是偏离许可和让步接收 , 具体内容如下 。
3.1 技术状态更改 大家对技术状态更改的内容非常熟悉 , 关于其分类、程序等内容就不再一一赘述 , 需要说明的有两点: 1)技术状态更改应遵循的五条原则:“论证充分、试验验证、各方认可、审批完备、落实到位” , 这也是来源于航天的经验总结 , 深刻而精辟 。2)I类、II类、III类技术状态更改的差异:I类技术状态更改和II类技术状态更改需要先编制技术状态更改申请 , 经审批后在编制技术状态更改通知(技术状态更改通知的形式一般有更改单或修改单、技术通报等) , 且I类技术状态更改和设计定型后的II类技术状态更改申请应经客户审批;而III类技术状态更改可直接编制技术状态更改通知 , 且III类技术状态更改和设计定型前的 II类技术状态更改申请可由承制方自行审批 , 并通知客户即可 。
3.2 偏离许可和让步接收 在技术状态项制造前 , 如果承制方认为有必要临时偏离已批准的技术状态文件 , 可提出偏离许可申请 。在技术状态项制造期间或检验验收过程中 , 如果承制方认为不合格品可返修或原样使用 , 可提出让步申请 。偏离、不合格的级别一般分为严重级和轻度级 。严重级之外的属于轻度级 , 对下列一项或多项产品影响的偏离、不合格均属严重级: 1)性能; 2)功能接口或物理接口; 3)互换性; 4)形状、质量、质心; 5)可靠性、维修性、测试性、保障性、安全性; 6)环境适应性和电磁兼容性等特性; 7)人员健康与安全; 8)服役使用或维修; 9)造成严重后果的其他方面 。产品设计定型前的偏离许可、让步申请一般由承制方自行审批 。产品设计定型后的偏离许可、让步申请应经客户审批 。
四、技术状态记实 技术状态记实是在产品寿命周期内 , 为说明产品的技术状态所进行的记录、报告活动 , 具体任务包括:
1)记录并报告各技术状态项的标识号、现行已批准的技术状态文件及其标识号;
2)记录并报告每一项技术状态更改从提出到实施的全过程情况;
3)记录并报告技术状态项的所有偏离许可和让步的状况;
4)记录并报告技术状态审核的结果 , 包括不符合的状况和最终处理情况;
5)记录并维持已交付产品的版本信息及产品升级的信息;
6)定期备份技术状态记实数据 , 维护数据的安全性 。应从产品的方案阶段其开展技术状态记实活动 , 根据技术状态记实的任务 , 主要工作分为记录和报告两个方面 , 记录指的是在产品生命周期内记录相关的技术状态活动 , 容易理解 , 那报告的要求包括什么呢?从两个方面看:
1)在产品研制生产阶段 , 向客户报告 , 报告内容如下: a)技术状态项及其技术状态基线文件清单; b)当前技术状态说明报告; c)技术状态更改、偏离许可和让步状况报告; d)技术状态更改实施和验证报告; e)其他客户要求的报告 。
2)向供方报告 , 其报告方式是从上面内容中挑选适用的文件发送给供方 。
五、技术状态审核 技术状态审核是为确定技术状态项与其技术状态文件的一致程度而进行的正式检查 , 包括功能技术状态审核和物理技术状态审核 , 在第一章中已经说得比较清楚了 , 这里不再赘述 。
六、结语 技术状态管理是武器装备研制系统工程的重要组成部分 , 是实施研制、生产质量保证的重要手段 , 只有在型号产品全寿命周期内严格控制技术状态 , 才能可靠地保证武器装备质量满足最终的使用要求 。
构型管理和技术状态管理的区别 , 
1、构型管理是当前飞机制造领域普遍采用的概念 , 多用于民机领域 。
2、技术状态管理是我国在军备方面一直采用的概念 , 是军方约定俗成的称呼 。构型管理的概念最早起源于美国的军事工业 , 指的是一套科学的系统管理方法,是建立和维护产品技术完整性的重要学科 , 在中国被译为技术状态管理、构型管理与配置管理 , 不同行业叫法不同 。
【技术状态管理】在实施技术状态管理中涉及到两个基本的管理要素 , 一是技术状态项目 , 二是基线 。技术状态项目是技术状态管理的基本单元 。基线是指已批准的并形成文件的技术描述 。技术状态管理中 , 一般要考虑三个基线——功能基线、分配基线和产品基线 。技术状态管理主要是针对技术状态项目的基线实施的管理 。