茆杰 王立曉 陳鑫
(1.南京地鐵建設有限責任公司,江蘇 南京 210019;2.南京林業大學土木工程學院,江蘇 南京 210037;3.南京華潤燃氣有限公司,江蘇 南京 211111)
地鐵項目建設周期長、合同數量多、管理工作量大。隨著現代信息技術的發展,工程項目合同管理走向電子化、信息化,無錫、寧波、南京等多地的地鐵企業開展了地鐵建設信息化管理系統實踐,利用信息化手段提高合同管理效率[1-2]。然而,地鐵項目承包商在地鐵建設信息化管理改革中難以快速適應新模式,主要原因在于原有工程資料的收集和整理無法適應業主合同信息管理系統的需求,而承包商的項目合同信息管理應基于業主合同管理信息系統的需求。當前,個別學者對合同信息檔案進行了探討,如陳靜遠[3]通過文獻與案例分析得出目前合同管理信息化存在的問題,包括未能及時實現數據共享及傳遞、需求分析不到位等;楊秀文[4]為加強建筑企業對設備的信息管理,構建了以KKS編碼為核心的臺賬體系,以ERP系統功能為紐帶,以KKS編碼為核心,基于KKS編碼在ERP系統實現設備的動靜態臺賬的融合,但該臺賬信息沒有考慮信息在傳遞共享方面也應滿足業主的需求。為了提高合同管理信息化系統的應用水平,本文從承包商的角度對合同信息系統的需求進行分析,以承包商合同管理原始資料為基礎,進行面向系統需求的承包商合同管理臺賬設計,并以此為承包商資料準備的索引,以滿足系統應用的資料信息需求。
信息分類是信息編碼的基礎和前提。信息分類的基本方法有線分類法、面分類法、混合分類法[5]三種。線分類法指將被分類的物體按一定的級別進行分級,從而形成一種分層遞進的樹狀結構,具有信息量大、層次分明、能直觀反映各種類目間的邏輯關系的特點。由于承包商合同管理資料有明顯的管理要素區別,且存在較為清晰的管理邏輯,本文采用線分類法對資料進行一級分類,逐級進行類目細化。
基于統一信息組織的編碼結構模型如圖1所示。該模型的編碼結構由對象類別碼、對象分類碼,以及流水碼、狀態碼組成[6]。對象類別碼用于標識職能域和編碼對象域,對象分類碼描述信息對象的分類特征,當類別碼和分類碼仍不能將信息對象描述清楚、不能與另一信息對象區分開時,則以流水碼、狀態碼標識。

圖1 基于統一信息組織的編碼結構模型
不同的合同類型在系統進行支付申請時要求承包商上傳的信息有所差異。以南京地鐵建設公司為例,對土建施工類、設備類、材料采購類三類合同清單信息進行分析。
2.1.1 土建施工類清單信息
土建類合同需要承包商提供分部分項及單價措施清單信息、總價措施清單信息、規費清單信息,結構模板見表1~表3。

表1 分部分項及單價措施清單結構模板

表2 總價措施清單結構模板

表3 規費清單結構模板
2.1.2 設備類合同清單信息
設備類合同包括設備集成/供貨類貨物清單信息、設備集成/供貨類伴隨服務清單信息,結構模板見表4~表5。

表4 設備集成/供貨類貨物清單結構模板

表5 設備集成/供貨類伴隨服務清單結構模板
2.1.3 材料采購類合同清單
材料采購類合同清單結構模板見表6。

表6 材料采購費用清單表結構模板
以土建施工類清單信息為例,分析上述清單的數據來源,可分為以下4種:
(1)描述性數據。上述清單模板中的“序號”“項目編碼”“項目名稱”“項目特征描述”“計量單位”都是在合同簽訂時形成的清單描述性數據。
(2)合同數據。“綜合單價(元)”“主材設備是否甲供”“計價方式”都是在合同簽訂時形成的清單基礎信息。
(3)政策數據。“稅率”是根據國家規定形成的信息,無需承包商進行重復填寫,系統會自動根據合同約定的信息形成。
(4)承包商申報數據。承包商在合同支付申請時,分部分項及單價措施清單中,“工程量”信息是需要承包商進行數量錄入的,該項信息是承包商在系統內進行合同支付申請時與系統進行交互的關鍵信息??們r措施清單、規費清單則是以分部分項及單價措施清單信息為基礎形成的附屬清單,其中“工程量”信息則是依據分部分項及單價措施清單中的“工程量”按規定進行相應計算得出的。因此,需要以“工程量”信息為重點信息進行資料準備。
承包商進行系統信息錄入時,需要提供工程量信息及相應資料。系統對承包商提出工程量信息需求,其實質是需要承包商向系統提供本合同支付周期內已完工程數量信息。而已完工程信息則由兩類信息組成。對承包商工程量信息全過程進行分解,形成工程量信息分解結構,如圖2所示。

圖2 工程量信息分解結構
同時,承包商進行系統合同支付時需要進行管理考核。如南京地鐵7號線施工總承包項目承包商在合同中與南京地鐵建設公司約定,需要提供項目管理考核信息,包括質量、安全與進度的考核,以判斷承包商是否完成合同約定的本期質量、安全、進度目標。考核信息分解結構如圖3所示。

圖3 考核信息分解結構
通過實地調研了解到,施工總承包項目在進行系統合同支付報審時會對相關資料進行全面收集,包括通過收集各工區完成工程量確認單,以獲取工區現場完成工程量信息;通過收集工區按照計量規則算出工程清單金額形成的系列資料,如工程計量表、工程計量匯總表等,以獲取工區合同支付的清單項目金額信息;通過收集總承包項目部各部門具體考核獎懲記錄資料,以獲取考核信息。在此基礎上,承包商會收集關于質量、安全、進度管理的相關信息,但存在以下不足:①承包商在收集管理資料時以管理結論性、總結性資料為主,而管理過程中相應的記錄資料不完整;②過程性資料不齊全,導致資料之間相互孤立,無法對資料信息的真實性與準確性進行復核;③各項資料分散于各職能部門或工區,沒有進行匯總整合,導致資料準備過程時間成本較高、效率較低,現有的臺賬并沒有起到指導承包商進行有序收集資料的作用。因此,本文運用基于統一信息組織的編碼結構模型,進行基于系統信息需求的承包商資料編碼與合同管理臺賬設計。
根據信息組織的編碼結構模型,建立承包商資料信息編碼體系,原則如下:
(1)根據職能域與編碼對象域形成主軸編碼模塊。職能域的形成以資料的一級分類為基礎,進行質量、進度、安全管理的劃分,資料依據PDCA管理循環各環節進行二級分類。編碼對象域的劃分是根據管理模式下企業業務管理形成的具體信息內容,劃分需要含義明確并符合企業信息的實際承載形式。如圖1編碼結構模型所示,后續不同“特征”段則是信息的粒度由粗變細的劃分過程,而最終確定信息的是需要相應的標識劃分,“狀態”則反映并記錄事物所處的管理階段特征。
(2)根據信息特征形成特征分類編碼模塊。一方面,承包商有大量的材料具有時間特征,以年、季、月、周、日為時間節點形成相應的資料;另一方面,需要明確其涉及的分部分項工程的位置。
(3)對資料最終形成一對一標識編碼模塊。對每項資料從時間線、管理內容與工程劃分三個角度進行梳理,整合得到的有序資料矩陣集合即為合同管理臺賬,其矩陣邏輯構成如圖4所示。

圖4 合同管理臺賬矩陣構成圖
3.3.1 管理要素編碼模塊
一級層級編碼依據承包商在系統應用中所需提供的資料進行編碼,分為質量(Z)、安全(A)、進度(J)管理;二級層級編碼依據管理環節進行編碼,分別為計劃(P)、執行(D)、檢查(C)、處理(A);三級層級編碼為管理環節中涉及資料的細化分類;四級層級編碼是對編碼對象域涉及的管理信息資料進行編碼。其中,三、四級編碼依據對承包商管理資料進行分類整理的結果,以兩位數字進行順序編碼。最終,管理要素編碼模塊形成的編碼段編號形式如圖5所示。

圖5 管理要素編碼模塊
3.3.2 時間特征編碼模塊
根據資料時間節點進行編碼。首先,用1位數字編碼形成年份,以項目開工年份為第1年進行編碼。其次,用4位數字編碼資料的季度、月度與日度時間節點,其中,季度為第1位數字,范圍為1~4;月度為第2位數字,在季度編碼下,以數字1~3表示,即13為第1季度第3個月份,即3月;后兩位為具體日期,最終形成4位數字的時間編碼。其中,以周為時間單位的資料,其時間編號以本周第一天的日期表示,若資料的時間節點顆粒度不需要精確到日期,則后續時間編號用“00”表示,例如:合同簽訂時間為2020年,則2022年4月10日編碼為32110。時間要素編碼模塊如圖6所示。

圖6 時間要素編碼模塊
3.3.3 工程特征編碼模塊
以南京地鐵7號線項目為例,將其編碼分為10級。
一級編碼確定資料所在的工區位置,兩位大寫字母構成具體工區編碼。第一位大寫字母表示項目專業分類,分為土建類(T)、軌道類(G)、安裝類(A);第二位大寫字母為具體工區編碼,依據施工組織設計其工區的相應號碼,以A開始順序進行編碼。
第三、五、六、七級編碼為資料所在單位工程、分部工程、子分部工程和分項工程,都以1位大寫字母進行編碼,以A開始順序編碼。其中,第三級編碼增加數字表示單位工程序號。第四級編碼為資料所在子單位工程,因其數目在10以內,用1位數字進行編碼即可。
第八、九級編碼為資料所在工程位置的檢驗批與工序特征,分別以兩位數字進行編碼,編碼至九級能夠對工程特征明確至工序細度。若編碼細度達不到九級,則不需要的層級用0表示。若出現大寫字母不夠使用的情況,則繼續以1位數字作為編碼。
第十級編碼為資料的識別碼,以1位數字進行編碼。當出現同一天統一工程劃分下的同一個管理要素資料出現不同的兩份時,進行唯一性識別。該級編碼只在小概率情況發生,出現時從1開始進行排序編碼,以“(1)”“(2)”表示;若未出現上述情況,則將該級編碼隱藏。該初始編碼默認為1。例如:土建一區一號車站的車站主體地基基礎及支護結構中土方工程的土方開挖資料,其資料編碼為TA1A1AAA0000。工程特征劃分編碼模塊如圖7所示。

圖7 工程特征劃分編碼模塊
本文所構建的面向南京地鐵合同管理信息系統的承包商合同管理臺賬可以看作資料的數據庫。該臺賬的數據結構是以時間特征編碼模塊作為臺賬數據庫的“字段”,以管理要素編碼模塊作為數據庫的“記錄”,“字段”與“記錄”的交叉區域進行工程特征編碼模塊信息錄入,形成資料具體完整的合同管理臺賬編碼,該過程形成的資料編碼清單即為合同管理臺賬,其簡易版合同管理臺賬見表7。

表7 合同管理臺賬(簡易版)
承包商為滿足系統信息需求,運用合同管理臺賬進行信息流加工整合。在進行系統合同支付報審前,需要通過合同管理臺賬對各工區所上報總承包項目部的已完工程信息進行檢查,確保已完工程信息通過審核,并且還需確保各工區工程量計算結果與已完工程量相符,承包商工程量信息流結構如圖8所示。

圖8 承包商工程量信息流結構
(1)以本期合同支付時間段編碼及編碼ZC102(質量檢驗記錄)為條件進行矩陣檢索,篩選出本期時間范圍內所有的檢驗批質量驗收記錄,并匯總生成本期質量驗收信息包。
(2)以本期質量驗收信息包中涉及的檢驗批編碼及ZD000(質量執行資料)為條件進行矩陣檢索,篩選出信息包中檢驗批對應的質量執行資料并匯總形成質量執行信息包,可分為施工記錄、施工試驗檢測、工程測量管理三個子信息包。
(3)以質量驗收信息包為基礎,對應質量執行信息包,對質量檢查信息進行自檢。
1)利用臺賬中資料工程特征模塊編碼帶有的工程施工邏輯順序性質,以及時間特征模塊編碼帶有的時間順序,對質量驗收信息包中各檢驗批進行施工邏輯順序與時間順序的校驗。要求同單位工程下分部分項工程中的同一檢驗批編碼需要順序,并且對應時間編碼也需要與檢驗批編碼對應順序,即編碼在前的檢驗批需比編碼在后的檢驗批完成時間更早。若出現驗收邏輯順序與規定要求不一致的情況,則需要及時追溯施工質量執行信息包中相應施工記錄,找出錯誤源頭。
2)對質量驗收信息包與質量執行信息包進行對應資料的匹配性檢查,要求質量驗收信息包中包含各項檢驗批信息并完全對應質量執行信息包內依據資料。該過程可通過工程特征模塊編碼進行快速對應檢查,通過檢索同單位工程下分部分項工程中的同一檢驗批編碼資料完成。
(4)在完成質量檢查信息自檢,確保本期合同支付的質量驗收信息包與質量執行信息包的完整性與對應性后,即形成了能夠支撐已完工程信息的依據資料,總承包項目部可進行已完工程報審。
(5)通過已完工程報審后,形成已完工程確認單,各工區工程經濟部對其具體已完工程信息進行對應的工程量計算,形成各工區本期支付工程量信息??偝邪椖坎坑媱澓贤繉ζ浔酒谥Ц豆こ塘啃畔⑦M行檢查并匯總,與已完工程確認單一同上傳至合同管理信息系統。
本文首先依據系統設定的各項合同清單對承包商所需提供的信息進行分析,得出工程量信息是系統信息需求的主線,進一步通過分析承包商資料準備現狀的不足,明確承包商應準備的資料,對資料進行有序全面的分類?;谠摲诸悾\用統一信息組織的編碼結構模型對特征要素眾多且雜亂的資料信息從資料產生時間、資料管理要素與資料所屬工程劃分角度進行合同管理資料的明確編碼,構建承包商合同管理臺賬編碼體系,形成全面的合同管理臺賬,通過臺賬幫助承包商進行資料準備及資料前后對應檢查核對,以滿足系統的要求,提高合同管理信息化應用水平。由于不同信息化系統對承包商提出的要求不同,在后續研究中可對其他系統進行研究。