一个复杂大型工程应按照系统工程进行工程管理和项目管理，伴随着产品寿命周期的发展，开展一系列技术活动或称“技术过程”。其中，对于一些贯穿始终的技术要求的管理和工程技术活动管理发展成为“技术管理活动”。
典型的系统工程技术过程包括：系统要求的形成_系统功能的分析与分解→功能实现的设计→从低装配级到高装配级的制造与集成→伴随集成的验证与确认→产品的交付等。典型的系统工程技术管理活动包括技术规划、要求管理、接口管理、技术风险管理、技术状态管理、技术数据管理、技术评估管理以及决策管理。其中，技术状态管理是对产品各项功能、性能、接口、约束、物理等特性指标与要求（技术状态）的管理。
通常，系统的技术状态是随着寿命周期发展的，从系统方案的选择到系统要求的确定与分配、功能和性能的设计、产品的制造与集成以及到对各项要求的符合性验证，技术状态是逐步细化的，直到可以按照技术状态文件的规定生产出符合系统规范要求的产品。
技术状态管理在工程项目的系统工程和项目管理中应用，通常反映在法规、文件、标准、手册、指南中。由于产品特点不同，技术状态管理要求通常反映在国内外民用、军用和航天的标准中。民用标准如GB/T 19017-2008/IS0 10007:2003《质量管理体系技术状态管理指南》和EIA-649-B-2011《技术状态管理标准》；军用标准如MIL-HDBK-61A《技术状态管理指南》和GJB 3206A-2010《技术状态管理》；航天标准如ECSS-M-ST-40C Rev.1《技术状态和信息管理》、NASA-STD-0005《NASA技术状态管理标准》和QJ 3118-1999《航天产品技术状态管理》。
本文将采用通俗语言简述技术状态管理的概念和内容，重点说明：①技术状态管理的对象是系统级产品和技术状态项目；②随着产品寿命周期的发展，应制定一系列技术状态文件，这些文件经过评审与批准后成为产品技术基线；③技术状态基线主要包括功能基线、分配基线和产品基线；④功能基线和产品基线从初稿到终稿的发展需要经历较长的时间和过程；⑤制定和执行技术状态基线以及考核产品是否达到技术状态基线的要求是技术状态管理的核心。
1 技术状态管理的概念
1.1 技术状态及其管理
技术状态是指产品的功能特性和物理特性。处于不同阶段的技术状态应在相应的技术状态文件中进行规定，经过批准的文件成为技术状态基线，最终产品应达到基线的规定。
技术状态管理的对象是系统和技术状态项目(CI)。CI是指关键的分系统级或以下装配级产品，通常选择关键、复杂或需进行关键技术攻关（技术不成熟）的分系统、设备、单机、组件等硬件/软件产品作为CI。CI应尽可能地少。
技术状态管理是在产品寿命周期内，为制定和保持/维持产品的功能特性、物理特性的管理活动，也可以说技术状态管理是对技术状态基线的管理活动。技术状态管理主要包括以下活动：技术状态管理策划；技术状态标识；技术状态控制（又称更改控制）；技术状态记实；技术状态审核。
1.2 技术状态基线以及演化
技术状态基线也称技术基线，是随着产品寿命周期（或研制阶段）的发展制定的一系列技术状态文件，并经过评审和批准后成为产品技术基线。技术基线以文件的形式存在，表述随产品寿命周期的推进而形成逐步递进关系的不同技术状态。前一个技术基线制定批准之后，将作为之后一个阶段研制生产活动的基准，以及技术状态改变判定的基准。从宏观的“工程项目基线”角度来说，技术基线是为了产品寿命周期内性能部分活动而建立的，它是整个工程项目基线的一部分。
技术基线按阶段划分至少应形成三条基线，即功能基线、分配基线和产品基线。在工程实践中，也可以根据产品复杂程度和研制过程技术成熟度等实际情况设置更多的技术状态控制点，即技术基线。如：系统概念（或任务目标概念）基线、研制基线（又称为分配基线）、设计基线、建造基线、制造基线或生产基线（产品基线）、使用基线等。通常，在什么阶段，制定什么基线，是根据产品研制特点确定的，但是技术基线至少包含功能基线、分配基线和产品基线。技术基线自建立时起，不断进化、细化和成熟，并维持到产品寿命周期结束为止。
1.3 基线种类和建立时间
1.3.1 功能基线
功能基线是指“系统级产品”的功能特性及其验证的文件，该文件通常称为《系统规范》。在一些标准中规定，独立研制的重大的CI基线也被列为功能基线。简单地说，功能基线的核心是描述产品的功能，是产品设计的依据。通常制定《系统规范》并作为功能基线，这是以功能为导向的文件。功能基线还应包括任务能力和验收准则。
功能基线需要经历不断成熟的过程。对于创新工程，功能基线的建立需要经过相当长的时间。通常，功能基线从探索、初稿到终稿，从简单粗放到精细严谨。作者认为，《系统研制总要求》或《系统研制任务书》相当于初稿，《系统规范》相当于终稿。功能基线终稿应通过系统要求评审(SRR)和/或系统功能评审(SFR)后正式确认。
1.3.2 分配基线
分配基线是指“关键分系统和/或以下装配级产品”的功能特性及其验证的文件，分配基线文件通常称为：××CI规范。如：××分系统规范、××设备规范、××单机规范、××组件规范。简单地说，分配基线的核心是描述产品如何实现其功能的设计文件，是产品制造的依据。低装配级产品的分配基线是从上一级产品功能基线分配而来，即：将系统功能基线的各项功能指标、性能指标和验证要求分配给分系统级产品，并成为分系统级产品的分配基线。相同的道理，将分系统级产品分配基线作为功能基线再分配给组件级产品成为组件级产品的分配基线。还可以继续向下分配，直到不必再分配为止。由于基线向下分配，产品要求中将产生一些导出要求，而导出要求依赖于设计方案，因此，有时也称为设计要求。导出要求包括系统内部要素之间的内部接口约束条件。
分配基线应通过初步设计评审(PDR)后正式确认。
1.3.3 产品基线
产品基线是指“关键分系统和/或以下级产品”的所有功能特性和物理特性、联合作战（或使用）要求，需要进行验收试验的功能特性和物理特性，“关键分系统和/或以下级产品”进行的部署/安装、支持、训练和退役等测试。分配基线文件通常称为图样、相关产品的详细规范、材料规范、工艺规范、软件规范（初始稿），以及相应功能、性能等要求的验证计划，形成制造、组装和制造文件。简单地说，产品基线的核心是描述产品如何生产制造出来的文件，是实现产品制造的文件。产品基线的演化需要经历相当长的时间，按照用途需要经历以下3个成熟度的产品基线：①初始产品基线，用于生产样件、工程模型、首件产品等；②经过验证的初始产品基线，用于小批量生产；③最终产品基线，用于大批量生产。
3个产品基线的建立时间如下：①产品基线通过关键设计评审(CDR)时被确认为是初始产品基线（未被验证的）；②产品基线通过功能技术状态审核(FCA)、生产准备评审(PRR)和系统验证评审(SRR)时被确认为是经过验证的初始产品基线；③产品基线通过物理技术状态审核(PCA)时被确认为是最终产品基线。
在实际工程中，卫星只经历初始产品基线。因此，卫星的初始产品基线去掉“初始”称为卫星的产品基线。
1.4 功能技术状态审核(FCA)和物理技术状态审核(PCA)
系统要求评审(SRR)、系统功能评审(SFR)、初步设计评审(PDR)、关键设计评审(CDR)、生产准备评审(PRR)、系统验证评审(SRR)是型号研制中需经历的评审。功能技术状态审核(FCA)和物理技术状态审核(PCA)是专门为技术状态设置的评审。其他评审是可以用于确定基线状态的评审，在此不进一步介绍。
功能技术状态审核是为了验证系统与CI是否已达到了功能技术状态文件和分配技术状态文件中规定的功能特性所进行的正式检查，是对产品设计的功能和性能是否达到功能与分配基线文件要求所进行的检查。功能技术状态审核应在工程设计与制造研制阶段结束前完成。对于大型复杂的系统和CI，每一个增量（增量是指分期或分步研制产品的每一期或每一步产品）均应进行功能技术状态审核。
物理技术状态审核是为了验证产品技术状态是否符合产品技术状态文件规定而对产品进行的正式检查，是对交付CI的设计与设计文件一致性的检查，是对CI大量制造工艺的确认，也是对进行再设计的CI是否符合性能规范进行的检查。物理技术状态审核应经过小批量使用之后，在大批量生产之前完成。当原始生产线停产几年之后复产时．以及当为新用户设计生产制造同样复杂的或更难制造的CI时，需要进行物理技术状态审核。当研制方或使用方控制详细生产设计时，需要进行再审核（复核）。
1.5 不同基线、不同装配级产品、不同评审之间的关系图
技术状态基线、评审与产品装配级之间的关系如图1所示。
图1 技术状态基线、评审与装配级的关系图
图1解读如下：①功能基线在左上方顶层作为要求提出，评审点是系统要求评审和系统功能评审；②分配基线在左侧从上向下，评审点是初步设计评审；③初始产品基线在右侧从下向上，评审点是关键设计评审；④经过验证的初始产品基线在右侧上方，评审点是功能技术状态评审和系统验证评审。此外，最终产品基线在右侧图外的位置。
2 技术状态基线文件
技术状态基线的存在形式是技术状态文件也称技术基线文件。也就是说，功能基线、分配基线和产品基线是以功能基线文件、分配基线文件和产品基线文件的形式存在的。这三种技术基线文件在产品寿命周期不同阶段进行编制、批准和保持，且在内容上逐级细化。
2.1 功能基线文件
功能基线文件中所描述的要求应是系统级产品应达到的要求，文件中不描述如何达到这些要求。功能基线文件数量不多，在现有文件中，有的文件属于功能基线初稿、有的文件属于过程稿、有的属于终稿。
系统的功能基线文件通常从以下文件中选取：①研制总要求；②系统研制任务书；③总体技术方案；④系统级接口要求、接口控制文件；⑤系统级环境要求；⑥系统要求（或一组技术要求规范）；⑦系统规范。
其中，“系统要求”有时分别给出以下的“技术要求规范”；系统任务要求、功能要求、接口要求、环境要求、使用要求、（综合）后勤保障要求、物理要求、产品保证的相关要求、技术状态要求、设计要求、验证要求。
2.2 分配基线文件
分配基线文件中所描述的要求应是上一级系统/CI分配给本级CI的要求以及本级CI生成的要求，这些要求是应达到的要求，文件中不描述如何达到这些要求。每一个CI均应编制分配基线文件，因此分配基线文件数量较多。
分配基线文件通常从以下文件中选取：①研制任务书：②功能要求；③接口要求；④环境要求；⑤性能规范；⑥研制规范；⑦设计规范；⑧建造规范：⑨软件要求规范；⑩详细规范。
2.3 产品基线文件
产品基线文件中所描述的要求应包含CI的所有要求，应尽量详细地描述要求，并以描述性能的方式描述要求。应从保证CI符合适用性、安全性、互换性等角度描述这些要求。最重要的是要描述如何实现这些要求。因此，产品基线文件的数量庞大。
产品基线文件主要包括：①产品详细规范、产品技术条件；②软件规范；③材料规范、材料技术条件：④工艺规范、工艺技术条件、工艺规程；⑤工程图（包括零件图、装配图、安装图、电原理图等）。
3 技术状态管理
3.1 技术状态管理的目的
技术状态管理的目的是：①保证在文件中规定明确的产品技术基线要求，并使设计、生产、试验和使用的产品符合这些要求；②当某个技术状态项目的技术基线需要更改时，应不影响其它相关产品，如果确实影响了其它相关产品时，受到影响技术状态项目的技术基线应相应调整更改，保证更改时不产生不良后果，使最终产品的技术状态符合技术状态文件的规定，或者是保持协调一致，确保更改得到控制。因此，技术状态管理的核心是技术状态的建立和维护。而技术状态管理的目的是确定产品寿命周期中各个阶段中的技术状态基线，以保证产品研制过程中的每一步均符合相应的技术状态基线。当某个装配级的产品技术状态基线发生改变时，应加以控制，使其不影响其他产品的技术状态。当更改影响到其他产品时，应对受影响的产品进行相应和协调的更改控制，使改变后的产品符合最终的产品技术要求。
3.2 技术状态管理的过程
a)输入。每个产品寿命周期阶段（研制阶段）需要输入：技术状态管理计划；技术状态信息（任务需求、系统要求与分解、各种约束条件、系统设计、系统建造、系统试验、系统使用、系统维护等）；需要进行技术状态管理的系统和CI；提出的技术基线更改请求。
b)过程活动。每个产品寿命周期阶段（研制阶段）进行的技术状态管理包括5个步骤：技术状态策划：技术状态标识；技术状态控制；技术状态纪实：技术状态验证与审核。
c)输出。每个产品寿命周期阶段（研制阶段）输出如下：建立技术基线；评审并批准技术基线：经批准的基线更改：技术状态现状报告；技术状态审核报告。
3.3 技术状态管理的步骤
步骤一：技术状态管理策划。技术状态管理计划必须回答以下问题：承研方和用户（或政府）需要控制哪些基线，需要哪些数据，何时进行控制。
步骤二：技术状态标识。技术状态标识的活动是：确定CI；编制系统和CI的技术状态文件；评审并批准这些文件并成为技术状态基线。
步骤三：技术状态控制（更改控制）。更改控制是技术基线建立后，对提出的更改建议（含工程更改、偏离和超差）进行的论证、评定、协调、审批、实施和验证的活动。应该强调的是：在完成系统级关键设计评审后，应保证初始产品基线的更改控制在1级技术状态更改之内（美军标中规定）。
步骤四：技术状态纪实。技术状态纪实是在产品寿命周期内，对产品的技术状态信息、建议的更改状况和已批准更改的实施情况进行的正式记录和报告。
步骤五：技术状态审核和验证。技术状态审核是为确定系统和CI与技术状态文件的一致程度所进行的正式检查。检查通常以填表的形式进行，如：回答应该做的试验做了没有，结果是否有效，应该编写的《规范》编写了没有，试验程序是否经过评审并得到批准，各项审查是否已经进行，等等。技术状态审核分为功能技术状态审核(FCA)和物理技术状态审核(PCA)。
在技术状态管理实践中，特别需要关心以下问题：①确定哪些产品为技术状态管理的对象；如除系统外．还需要确定哪些风险高的以及关键技术攻关分系统、单机，设备或组件作为管理对象；②确定建立哪些技术基线，何时开始何时结束．编写哪些技术基线文件，经过什么评审后技术基线文件成为后续工程执行的技术基线：③确定技术基线文件清单、编写单位和完成时间；④确定编写基线文件的模板。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：技术状态管理研究
相关文章
