系统需求视角下的工程变更应对策略研究

2024-01-12高巍

项目管理技术 2023年12期

高巍

(福陆(中国)工程建设有限公司，上海 201103)

0 引言

工程项目在实施过程中都会遇到变更情况，变更对项目的影响在很大程度上取决于其发生的时间。过晚的变更往往会对项目的实施产生一系列不利的影响，如重复工作、进度延迟、预算增加等。如何从源头上有效控制变更，如何应对过迟变更发生，都是工程管理人员需要深入思考的问题。

在工程实践中，通常采用阶段性审查的方法，将项目实施过程分解为若干阶段[1]，确定各阶段关注的方案与事项，并进行阶段性综合审核，是应对过晚变更的重要措施。然而，在实际实施中，过晚变更的发生仍非常普遍，对项目的影响不容忽视。已有相关研究往往是经验教训的积累或侧重于实施阶段的相关管理[2-4]，对整体策略基于知识与逻辑体系的系统性梳理尚不多见。

本文将工程项目作为研究对象，对拟建系统在设计建造过程中的变更控制问题进行探讨，并提出应对策略与解决方案，为后续相关方法工具的研究开发打下理论基础。

1 工程变更来源分析

要从源头上分析工程变更，需要对其来源进行梳理。变更的本质是拟建系统某个层面的需求发生了变化。需求来自各个参与方，因此，首先考虑按照项目主要参与方的维度对变更来源进行分类。一般情况下，工程项目中核心参与方包括：投资方、用户方、管理方、设计方、施工方、供应方、监管方。投资和用户方是用户需求的提出方，其需求的变化将会导致变更。设计方负责提出系统各个层面的解决方案，方案的变化将会导致变更。施工方负责提供工程安装实施，安装方案或已有成果的改变将会导致变更。供应商提供子系统的工程解决方案，其设计或产品如与前期假设不符，将会导致变更。监管方的法规、条例等代表公共利益需求，其变化或解释与预期不一致，都会引起变更。

将上述因素进行归纳，变更的来源可以分为以下三个方面：

(1)需求变化。如业主方、使用方提出的功能需求调整等导致相关需求定义的变化。

(2)失误补救。设计、施工、采购等各方在实施过程中均会存在不完善甚至失误的地方，如条件传递失误、工序协调冲突、采购规格偏差等。另外，设计优化如发生在过晚的时间阶段，本质上也是一种失误。

(3)不确定性。如设备供应商设计的不确定性，规范法规中的灰色地带等。

Eckert等[5]将变更来源分为两大类：一类是突发型变更(Emergent Change)；另一类是发起型变更(Initiated Change)。后者相当于失误补救型，而前者对应需求变化型。本文将不确定性造成的变更单独分为一类，这是介于两者之间的一种变更，并非由被动失误造成，也不是由主动需求变化引起，而是由各种无法规避的不确定性造成。变更来源的本质分析见表1。

表1 变更来源的本质分析

由表1可知，需求、过程、系统这些关键词代表了变更来源的核心要素。从系统需求的视角研究设计过程中的工程变更问题，是本文研究的一个切入点。

2 基于系统需求分解模型的工程设计过程分析

2.1 系统需求域与系统方案域分解交互分析

工程设计过程的本质是提出系统需求，并找出满足需求的方案，这个过程在问题域和求解域之间不断以“之”字形传递且不断分解。在工程背景下，问题域对应系统需求域，求解域对应系统方案域。

系统的本质特征之一是层次性[6]，相应的，系统需求与系统方案也具有层次性。系统需求域的最高层面，是投资方根据市场需求提出的整体性系统需求，这是总源头；系统方案域的最高层面，是整体性可行方案和系统；对这些系统的组合分析的过程，就是本系统层面的设计过程，该设计过程的成果，就是本层系统的方案。

就系统的某一层面而言，在方案域中寻找方案的过程，是寻求相关系统要素的组合以满足该层系统需求的过程。该过程是一种综合过程，是把已知的元素汇集成新的组合创造的过程。

在本层系统方案的基础上，进入下一层的系统需求分解的过程，对相关组合元素的需求分别进行研究，继而在系统方案域分别形成相关系统方案。这就是需求在系统需求域和系统方案域之间“之”字形传递分解的过程。这个过程随着系统分层而逐层展开，是一个循环迭代的过程，如图1所示。

图1 问题域与求解域之间的“之”字形映射过程

2.2 系统需求分解模型的提出

系统需求如何得到满足，需要从系统功能的定义着手分析。功能是系统诸要素在一定的结构下形成的效应或作用，是由系统要素及其关系所决定的，通过系统的整体行为表现出来[7]。系统要素及其相互关系，是系统的组成方式，可称之为架构。架构可以包括三个方面[8]：一是功能要素的组织方式；二是功能要素至物理要素的映射；三是物理要素之间的交互的规定。由此可知，架构的概念包括功能要素与系统要素的映射关系、各自的组成方式，以及系统要素之间的交互方式。

结合系统要素之间交互的本质特征，可以将系统的组成架构分为流程架构和空间架构两个方面，流程架构表示系统要素之间的物质、能量(冷、热、电、力等)，以及信息的流动和传递关系；空间架构则表示系统要素之间的空间关系(如远近、高低、占用、分隔等)。因此，方案确定意味着架构的确定，架构确定意味着本层系统的组成要素、交互关系(流程架构)及空间关系(空间架构)的确定。这个确定本层系统方案的过程，就构成系统需求“之”字形分解传递过程的水平部分，如图2所示。

图2 系统需求域与系统方案域的分解传递与验证

而本层系统组成要素的属性参数确定需分解至下一个系统层面来解决，即需求分解。在系统需求域，针对系统要素的功能需求进行分析，确定该层面系统要素的系统需求，确定系统属性参数。这样，也就完成了“之”字形映射过程的倾斜段，如图2所示。将要进行的是又一个“之”字形映射的周期，相关系统需求和系统要素继续得以分解。

从图2可以看出，系统设计的过程，实质上就是系统需求域和系统方案域“之”字形分解传递迭代的过程。

系统设计中尚有一个分析与验证的过程。第i+1层系统的需求定义能否满足其上层(第i层)系统架构的要求，第i层系统架构能否满足该层系统需求定义的要求。这个验证过程是沿着“之”字形路径相反的方向进行的，如图2所示。在设计阶段，这种验证主要采用虚拟、纸面的验证方法，以各学科的知识库、理论库及模拟工具为工具。

上述“之”字形映射分解及反向验证的过程，是本文从系统需求与系统方案映射分解的角度对工程设计过程进行的抽象，称之为系统需求分解模型。系统需求域与系统方案域的分层结构如图3所示。

图3 系统需求域与系统方案域的分层结构

2.3 系统需求分解模型解决的问题

工程设计阶段性审核的目的之一，是对下一阶段项目实施的基准线进行审核和确认。基准线的核心部分，是该系统层面的架构(流程架构和空间架构)，以及该层系统要素的系统需求。需求分解模型的提出，提供了一个清晰的视角和依据，帮助解决基准线的审查与判定等问题。

针对工程变更应对策略，系统需求分解模型提供了较为严谨的逻辑线索，沿着这条主线可以将与工程变更相关的各方面关联起来，为系统地分析和梳理提供了有力的理论工具。

3 工程变更应对策略分析

基于系统需求分解模型，本文拟从三个维度(时间维度、逻辑维度和知识维度)对变更应对策略进行分析。

3.1 时间维度——从项目的生命周期看应对策略

项目的生命周期是拟建系统从规划到实现的各个阶段的总和；不同阶段的系统需求不同，相应的变更特征和影响不同，其应对策略也不同。

建设类工程项目的生命周期大致可以分为概念设计、方案设计、初步设计、详细设计、施工建造、系统测试调试移交、使用维护等阶段。

在概念设计阶段，工程设计的侧重点对应整体系统需求的架构设计；在方案设计阶段，需求在整体层面基础上进行分解，对应层面的系统架构得以设计，阶段成果为工艺流程设计、工程方案设计等；在初步设计阶段，在前期阶段系统方案的基础上继续进行相关子系统的需求分析及架构设计，直至子系统组成要素的系统方案得以确认，阶段成果为工艺详细设计、工程设计统一规定、工程初步设计文件等；在详细设计阶段，关注更下一层系统(如组件层面)的需求，相关阶段成果为施工图、项目规范说明文件等。

各阶段对应相应的阶段性审查及决策要点，也可以从系统需求的角度进行分析梳理。方案设计结束，审查要点是整体系统架构的可行性、合理性、完整性。这个阶段的投入相对较少，往往是进行投资决策的较佳时间点。

随着初步设计(也称“前端设计”)的进行，系统设计进入子系统层面，子系统组成要素的系统需求得以提出。该阶段定义了子系统层面的系统架构及子系统要素层面的系统需求，是整个项目的设计基础。在此基础上，项目的范围基准才能有条件形成。因此，这个阶段的决策重点是确立项目的范围和费用基准(预算)。

进入详细设计阶段，部分实体投入开始发生(如长周期设备的采购)，系统设计进入组件层面的架构设计及组件组成要素的参数设计。这一阶段的决策重点是基准线的变化确认(变更审核)。

进入实施建造试运行阶段，实体投入开始大幅增加，系统从空间架构至系统架构逐层得到实现和验证，直至整体系统的需求得到验证确认。

项目生命周期的系统需求层次与阶段性决策内容如图4所示。前期设计中需要涉及大量方案比选，同时不确定性因素普遍存在，这些客观特征决定了该阶段变更策略应持开放的态度，充分进行各项优化，确保前期系统需求定义的质量。而进入详细设计和实施阶段后，由于投入大幅增加，变更策略应持收敛谨慎的态度，避免循环反复，造成不利影响。