系統需求視角下的工程變更應對策略研究

高巍

(福陸(中國)工程建設有限公司，上海 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所示。前期設計中需要涉及大量方案比選，同時不確定性因素普遍存在，這些客觀特征決定了該階段變更策略應持開放的態度，充分進行各項優化，確保前期系統需求定義的質量。而進入詳細設計和實施階段后，由于投入大幅增加，變更策略應持收斂謹慎的態度，避免循環反復，造成不利影響。

3.2 邏輯維度——從變更來源看變更應對策略

邏輯維度，擬根據變更的來源分類，從系統需求的視角分析并提出應對策略。

第一類是系統需求變化。需求變化往往是由于前期需求定義方案比選不足造成的。從應對角度來說，一方面，需加強需求定義環節的質量；另一方面，應進行分析和預測，對潛在變更風險相關影響鏈進行分析和跟蹤，并制訂風險應對措施。

第二類是系統的不確定性因素。對于不確定性的應對策略，一是盡可能地消除不確定性，二是接受不確定性并采取措施。

利用系統需求分解模型，首先識別不確定性因素所在的系統層面，確定是架構方案的不確定，還是子系統要素的系統需求不確定。其次在鎖定其系統層面后，對其影響鏈進行評估，對變更的可能性及影響性進行分析。

引入供應商參與設計是消除不確定性的一種實施方案，這需要建立長期的合作伙伴關系，同時在計劃階段協調采購與設計的時間節點；模塊化設計策略[9]是針對不同的系統層面采用模塊化方式，使系統具備較強的適應可預計變更的能力。

第三類是失誤因素。從系統需求的角度看，可導致變更的失誤類型包括：需求遺漏、需求獲取偏差、需求內容不全面、需求描述歧義、需求傳遞偏差、需求冗余、需求無法實現、需求無法驗證等[10]。

如何減少失誤的問題，是如何正確全面地定義各系統層面的需求及如何準確地傳遞需求、落實需求的問題。需求工程的引入，是從根本上解決失誤問題的應對策略。

3.3 知識維度——從項目管理知識體系的梳理看應對策略

知識維度借鑒項目管理知識體系(PMBOK)[11]進行梳理。項目管理理論被歸納為十大知識領域，包括整合管理、范圍管理、費用管理、時間管理、質量管理、采購管理、溝通管理、人力資源管理、利益相關方管理和風險管理。

(1)整合管理和風險管理。本文提出的系統需求分解模型以系統需求為主線整合了相關的元素，從集成的視角看變更問題，是整合管理思路的具體實現。風險管理方面的提示包括重視變更預測與影響傳遞、重視早期識別系統需求中的不確定性等[11-14]。

(2)范圍管理、費用管理、時間管理、質量管理。構建清晰的基準線是項目在變更應對時應特別關注的問題。

(3)溝通管理、人力資源管理、利益相關方管理。從系統需求的視角看組織設計、溝通及項目流程設計等，是一種有效的策略思路。

4 工程變更應對策略清單提出

綜上分析，本文提出六大工程變更應對策略，策略匯總見表2。

表2 工程變更應對策略匯總

基于需求分解的工程變更應對策略關系示意圖如圖5所示。可以看出，整個策略以系統需求分解模型為核心逐層展開，是本文對工程變更應對策略的一個系統性梳理。

圖5 基于需求分解的工程變更應對策略關系示意圖

5 結語

本文提出基于系統需求域和系統方案域的系統需求“之”字形分解模型，作為相關分析的基本工具和思路；經過時間、邏輯和知識三個維度的分析，建立了系統、全面的工程變更應對策略清單，可以在工程實踐中很好地指導相關執行策略的制訂與實施。各相關策略具體方法的落實及相關工具的開發，是后續需要進一步研究的內容。