我們解開了 Blockchain 智能合約的迷思後。今天,我想探討一個更貼近工程實務的挑戰:Smart Contract 如何處理那些 BIM 模型中沒有直接幾何對應的付款項目? 比如臨時工程 (Temporary Works) 的搭拆費、保險費、各類行政雜項費用等等,這些都是實際項目中不可或缺的支出,但你不可能在 BIM 模型裡「畫」出一個保險單據來。
這確實是智能合約設計的考驗。它的答案在於:Smart Contract 綁定的是「數據 (Data)」,而不僅僅是「3D 幾何 (Geometry)」。BIM 只是其中一個重要的數據源,我們需要將智能合約的觸發條件,擴展到 Common Data Environment (CDE) 中的所有相關數據容器。
BIM 只是其中一個重要的數據源,我們需要將智能合約的觸發條件,擴展到 Common Data Environment (CDE) 中的所有相關數據容器。
對於這些「非模型物件」的付款項,我們可以採用以下策略:
首先,是引入「虛擬物件」與「資訊容器」的概念。在 CDE 或 BIM 數據庫中,為這些非實體項目建立一個「邏輯實體」,它可能沒有 3D 形狀,但擁有唯一的 ID 和豐富的屬性(例如:合約類型、金額、付款條件)。當相關文件(如保險單據、費用申請表)上傳至 CDE 並獲得數位審批後,這個「虛擬物件」的狀態就會更新,進而觸發智能合約支付。這使得所有支付項目都能在統一的數位環境中管理。
當相關文件(如保險單據、費用申請表)上傳至 CDE 並獲得數位審批後,這個「虛擬物件」的狀態就會更新,進而觸發智能合約支付。
其次,許多雜費(Preliminaries)和行政費用是按時間周期支付的。對於這類費用,智能合約可以寫入基於時間的觸發邏輯 (Time-based Triggers)。例如,合約設定每月某日自動支付管理費,只要項目狀態正常運行,無需任何人工審批即可自動執行。
智能合約可以寫入基於時間的觸發邏輯 (Time-based Triggers)。
再者,對於臨時工程,即使沒有專門建模,我們也可以將其掛鉤到主體工程構件或數位進度表。例如,將「釘板費」作為牆身的一個「成本屬性」,當牆身完成並驗收時,智能合約同時支付牆身造價和釘板費。或者,與工程進度管理軟件(如 P6)的數據整合,當「搭建棚架」這一任務在數位進度表中標記為完成時,觸發相關款項的支付。
我們也可以將其掛鉤到主體工程構件或數位進度表。將「釘板費」作為牆身的一個「成本屬性」,當「搭建棚架」這一任務在數位進度表中標記為完成時,觸發相關款項的支付。
最終,這一切都需要一個混合驗證儀表板來呈現。在這個智能支付系統的界面上,會清晰列出所有付款項目,無論是與 BIM 模型關聯的,還是與文件或時間關聯的。任何人工審核確認,都將留下數位簽名並上鏈,確保可追溯性。
所以,智能合約的智慧不在於死板地依賴 3D 幾何,而在於能夠靈活地整合來自 CDE 中不同類型(幾何、非幾何、時間、文件狀態)的數位數據,建立一個更全面、更貼合實際工程需求的支付觸發邏輯。
智能合約的智慧不在於死板地依賴 3D 幾何
你們項目中還有哪些「非模型」但又非常重要的支付項目,是智能合約需要面對的?歡迎留言分享你的挑戰與思考!
