我們正在招募 Forward-Deployed Engineer查看職缺

EPC 統包

報價靠料表,不靠概估。

Operon 讀取整份投標文件:P&ID、PFD、管線清冊,以及業主留下的既有竣工圖,整理成一份結構化清冊,由估算工程師逐項核對位號。報價以此為準;進入細部設計後,等角圖陸續發出也一併納入,最後成為交付業主的竣工資料。

查看解決方案

數日

完成投標階段料表

97%+

元件辨識準確率

10,000+

已處理 P&ID 張數

<6 週

得標後部署時間

挑戰

統包專案上,團隊每天面對的問題

01

算量趕不上投標時程

投標窗口是固定的,圖說張數不是。估算人員要把每張 P&ID 上的閥件、管線元件與儀錶逐一清點,時間往往超過報價期限;散裝管材只能依歷史經驗值以係數推估,缺口再用預備款補上。這筆預備款不是讓標價失去競爭力,就是在得標後吃掉毛利。

02

版次之間的變更落差

從 IFD、IFR、IFC 到竣工圖,整套圖說會改版數十次,版次之間的差異靠人眼在 PDF 疊圖上找。漏掉的差異是自己吸收的重工;太晚發現的業主變更,則成了缺乏版次證據、難以計價的變更追加。

03

靠業主的舊檔案估價

既有廠區的業主交來的是數十年的掃描檔、已作廢的版次,以及一份不可靠的位號清冊。改建範圍只能依現場勘查抽樣估價;在總價承攬的合約下,抽樣沒看到的部分,不是投標時先排除,就是施工階段自行吸收。

04

保留款卡在移交文件

最終驗收與後段保留款,卡在移交文件包:竣工圖、管線清冊、位號清冊、各項證明文件。這些通常由已在撤場的團隊在收尾階段整理,交出去是幾千份 PDF,位號與圖說之間沒有可追溯的關聯,業主審查一拖就是好幾個月。

同一套圖說,統包商要看四次。估算部門在投標時清點一次。採購為了發出請購、抓散裝材料採購量,再清點一次。變更團隊在業主移動一個管嘴時,又重新核對一次。交付團隊在收尾階段,把它整理成移交文件。每一次都重新建立上一次已經建立過的結構,然後丟掉——四份試算表,同一個管線編號有四種說法。

Operon 只讀一次,然後留著。工程上的每一張 P&ID、每一份管線清冊,以及細部設計後陸續發出的等角圖,都會變成一張結構化的圖譜:設備、管線、迴路、儀錶,跨圖串接,再由工程師逐項簽認位號。投標料表、版次之間的差異、變更紀錄、竣工清冊,不再是四件各自為政的工作,而是同一份資料上的四種查詢;如果工程是在業主運轉中的廠區內施工,這份紀錄也正是對方變更管理(MOC)文件需要的佐證。差別就在這裡:算量工具在得標當天就擱在一邊,情境資料層則撐著整個專案走到結案。

我們的解決方案

Operon 在統包專案上做什麼

02

每一版次與前版逐一比對

圖說版次管理:IFD 到竣工

一份清冊涵蓋 IFD、IFR、IFC 到竣工圖,每一版都與前一版比對,偵測到的變更以結構化差異呈現,並標記回圖上的實際位置。變更團隊看過差異後,直接把圖說佐證帶進設計變更通知或變更追加;若工程位在運轉中的廠區,同一份紀錄也是業主 MOC 文件需要的內容。

了解更多
03

不限年代掃描檔、TIFF、舊版 CAD

既有廠區圖資數位化

把業主的舊掃描檔、褪色的等角圖與過時 CAD 檔,整理成結構化的資產清冊。投標階段拿得到檔案就在投標時做,拿不到就在開工後補。改建數量從位號清單算出來,不是靠現場抽樣;檔案之間對不起來的地方,也在變成現場爭議之前先記錄下來。

了解更多
04

每個位號可回溯到來源圖說

竣工與移交文件包

交給業主的是可查詢的資料:核對過的管線清冊、位號清冊與圖說索引,每一筆都能從位號追回來源圖說。移交文件包裡的工程清冊,不再是一疊要業主自己挖的 PDF,審查直接對著結構化資料進行。

了解更多
05

API 優先同一份已核對的圖譜

在專案圖譜上開發

同一份圖譜開放 REST、GraphQL 與 SDK,工程資訊部門或系統整合夥伴可以在上面開發自己的應用。結案時實例隨專案一併移轉,業主接手的是一套持續運作的系統,不是一份落地就開始過時的交付物。

了解更多

開始使用

下一個標案,用結構化資料來投

我們的駐場工程師可以在第一週內讓您上線運行。看到成果,而非投影片。

返回首頁