地下室鋼構的設計 - 臨時支撐 VS 施工順序與時程
臨時支撐最好被合宜的設計, 以及考量對其他工作的影響, 和對進度的
起因是, 地下室鋼構/鋼柱, 設計上會有一段時間與鋼樑無連結 - 必須依靠臨時支撐.
但臨時支撐有不能影響到該SRC柱的RC施工
#臨時設施 #施工方法
2021年12月31日 星期五
2021年12月27日 星期一
地樑與樓板的結構連結變更
工地有兩棟的結構設計是同一結構技師設計
不過, 其中後施工的一棟, 地樑與樓板的結構連結變更, 將地樑頂部增築了鋼筋
由於變更的訊息太晚發布, 引致需要緊急增購鋼筋及加工
#設計變更 #進度管理
2021年12月1日 星期三
2021年11月16日 星期二
鋼筋加工需要排隊等待產線超出預期的時間
鋼筋加工需要排隊等待產線超出預期的時間
從加工圖交付給鋼筋加工廠, 需要 45天至60天
目前從10月底交付的加工圖, 交貨時間在11月底 – 大約 30多天
不過, 多數時間都是在等待產線, 實際加工推測大約在14天
因此, IFC圖面確定時間, 深刻影響到鋼筋進場時程, 確實需要嚴密掌控確認時間
#預製加工 #進度管理
欠缺臨時設施設置的指引
在3個月前就發現工地的臨時施設置規畫不足
這段時間發現, 實際上公司欠缺相應的指引, 所以在早期工程階段, 只能概略說明, 然後放入下部結構工程的合約工作範圍內
事實顯示, 下部結構包商, 同樣欠缺合適的臨時設施規劃能力, 僅能勉強支應下部結構施工所需, 甚至還欠缺合適的設施
臨時設施的工作, 早期規劃好, 工程展開時, 才能時間與心力專注在主體工程的推動, 所以有指引才好儘早規劃好
#臨時設施
2021年10月27日 星期三
2021年10月26日 星期二
工地入場的要求 VS 缺少工人的問題
(2021/10/26)
起於工地對工人入場的要求, 引起工人短缺的問題浮現
關鍵在於"勞保"
以及"身分證"
(2021/10/28)
因應工人保險問題, 公司高層在權衡公司風險及法律可行方式後, 與營造廠取得共識
#EHS
2021年10月22日 星期五
開挖的抽水/降水工作 VS 進度延遲
欠缺深刻評估地質及地下水狀況及潛在風險,
引致在開挖到最後階段時出現因地下水導致的工程延誤,
不僅浪費了時間, 也增加額外的工作及成本
#設計 #風險管理 #進度管理
2021年10月10日 星期日
開挖面的地下水位下降未能如預期, 嚴重影響開挖工作的進行
開挖面的地下水位下降未能如預期, 嚴重影響開挖工作的進行
這是典型的**「地下風險（Ground Risk）」**失控案例。
在國際大型專案中，地下水問題被視為影響進度（Schedule）與成本（Cost）的最不確定因素。
以下是從 Preconstruction（施工前準備） 階段可以採取的高效解決方案：
1. 從「靜態鑽探」轉向「動態模型」
傳統上僅依賴少數鑽探孔（Boreholes），這往往無法反映真實的地下水文動態。
實施抽水試驗 (Pumping Test)： 在正式開挖前，不能只看水位計，需要抽水降低地下水位時, 可以進行抽水試驗，計算地層的透水係數 (Permeability) 與影響半徑。「獲取真實數據」以建模的基礎。
地下水流數值模擬 (Hydrogeological Modeling)： 使用如 MODFLOW 等軟體進行模擬。這能幫助工程師預測開挖過程中的水位變化，而不是等到開挖後才發現「降不下來」。
2. 優化設計
地下水處理應被視為開挖作業的「前導工序（Pre-requisite）」。
A. 重新設計「抽水系統」的冗餘度 (Redundancy)
產能匹配： 根據抽水試驗數據，設計 1.5 倍至 2 倍的抽水產能。包含增加觀測井（Observation Wells）的頻率，建立即時回饋系統。
備用電源與泵浦： 確保抽水系統不會因電力故障中斷。這屬於減少停機變異性 (Downtime Variability)。
B. 隔離策略 (Isolation Strategy)
如果降水效率不佳或不易，應在 Precon 階段評估加強「止水帷幕」。
優化連續壁 (Diaphragm Wall) 深度： 確保連續壁嵌入不透水層（如黏土層），從源頭切斷地下水流，而非一味地嘗試排乾開挖面地下水。
地盤改良 (Grouting)： 在局部透水性強的區域預先注漿，這比事後補救更節省時間。
3. 建立「緩衝」與「觸發」
對不確定性的管理（Buffering），在 Precon 階段應設定以下機制：
水位觸發協議 (Trigger Levels)： 定義三個水位警戒線（預警、行動、停工）。一旦觀測井數據未達到預期降水曲線，立即觸發「B 計畫」（如增加深井或點井數量），而非等待開挖受阻才反應。
工作包解耦 (Decoupling Work Packages)： 在計畫排程中，將「降水穩定」與「大底開挖」視為兩個獨立的決策門檻（Decision Gate）。如果降水未達標，不允許啟動開挖，避免機具與人員進場造成的「窩工成本」。
4. 責任與合約界面 (Interface Management)
在國際專案（如 FIDIC 黃皮書或銀皮書）中，地下條件的風險分擔至關重要。
地質基準報告 (Geotechnical Baseline Report, GBR)： 在 Precon 階段，業主應提供 GBR，明確界定「預期」的地下水情況。
- 效益： 若實際出水量超出 GBR 範圍，則啟動補償機制；若在範圍內則由承商負責。這能減少誰該出錢處理「多餘地下水」的爭執時間。
2021年10月8日 星期五
工作發包時被遺留的次要工作 missing minor works of contracting
工作發包時被遺留的細項工作
1. 不符合日後裝修面或防水層要求的模板表面
2. 箱型鋼柱的柱內灌漿
3. 1FL的SRC柱
4. 風險及保證的責任未在發包事項中
#包商管理 #採購發包
2021年10月5日 星期二
2021年10月4日 星期一
地下室防水工程 與 結構工程 的介面
地下室防水工程 與 結構工程 的介面
關鍵在於完成地下室外牆防水及回填, 對於(上部)結構工程施工動線的影響, 包括吊車吊掛位置.
#施工管理 #進度管理 #地下工程
2021年10月1日 星期五
2021年9月30日 星期四
如何訂定發包工作時的承攬商合約進度?
發包工作時的承攬商合約進度, 未與里程碑相符
引致要求工作必須趕上里程碑時, 包商要求趕工費用
Level 1 與客戶的合約進度 Contract schedule
Level 2 交付進度 Delivery Schedule
Level 3 執行進度 Mid-range schedule (includ weekly)
發包時, 應該以Level 2 schedule
#進度管理 #包商管理
2021年9月22日 星期三
發包的工作範圍(含包商的責任)未提供給執行的監工, 會有什麼影響?
發包的工作範圍, 未提供給執行的監工, 引致監工未能有效地確保所有工作按預期的被執行
而包商的責任, 未釐清的情況下, 可能將風險留在自己一方而不自知, 當風險情況實際發生時, 或將導致時間或費用的成本增加(或說損失)
#包商管理
2021年9月16日 星期四
2021年9月15日 星期三
2021年9月1日 星期三
基樁或地質改良的決定方式?
工地有 3棟主要建築物(廠房)
其中有兩棟建築物是兩層樓, 有JSP
另一棟是三層樓, 沒有 JSP
很多CSA同事在問原因?
目前僅知道, 是由不同的建築師和結構技師設計的
#基樁 #地質改良 #決策
2021年8月27日 星期五
工作範圍中的EHS要求會導致工作的單價增加嗎?
EHS要求會導致工作的單價增加嗎?
這是一個大的議題
理論上, EHS要求應該是可以為公司創造價值, 卻經常被視為成本過高的主要原因
因此, EHS要求必須在採購發包時, 對承攬商說清楚
#Safety #Cost
+ 2026-01-02 後續/更新
在短期與報價面上，單價確實會增加；但在長期與總成本面上，它是降低風險成本的必要投資。
我們必須區分「價格 (Price)」與「成本 (Cost)」的差異。
問題核心痛點
報價透明度不足：若 EHS 要求不明確，分包商會將其視為「隱形成本」，導致估價時隨意加價或事後索賠。
低價搶標陷阱：如果不將 EHS 規格標準化，劣幣（不重視工安的廠商）會驅逐良幣，導致專案面臨極大的停工與職災風險。
管理位能落差：業主期望的是國際級 EHS 標準，但分包商報價時參考的是傳統工地的簡陋作法。
具體解決方案與分析
1. 採購階段的「EHS 獨立標單」(Itemized EHS Bidding)
策略：不要將 EHS 要求籠統地寫在施工規範中，應將其**「量化」**並列入標單（BOQ）的獨立項次。例如：特定安全防護網、全職安全督導人員、高架作業紅外線感測器等。
效果：當所有投標者都在同一個 EHS 基準上競爭時，單價的增加是透明且公平的。這避免了分包商因「不確定性」而亂報溢價。
2. 區分「硬性門檻」與「獎勵機制」 (Penalty vs. Incentive)
短期策略：在發包時明定「基本合規單價」，這部分單價會略高於市場行情，以支應其安全設備開支。
長期建議：導入 Safety Performance-Based Contracting。若分包商能達成零職災且稽核高分，結算時給予「安全獎金」。
價值化：這能將 EHS 從「被動支出」轉化為分包商的「主動獲利」。
3. 評估「總擁有成本」(Total Cost of Ownership, TCO)
顧問視角：如果你因為 EHS 要求導致單價增加了 5%，但避開了一次可能導致停工 30 天、賠償上千萬並取消標案資格的職災事故，這 5% 其實是極低廉的保險費。
數據支持：統計顯示，工程職災的間接損失（停工、商譽、調查、保費調升）通常是直接損失（醫療、賠償）的 4 到 10 倍。
4. 提供「共通性安全支援」(Common Safety Services)
做法：由總承包商或業主統一提供高成本的 EHS 設施（如：共用鷹架、大型吊掛安全監控、數位門禁系統），分包商僅需負擔其個人防護具與教育訓練。
效果：這能降低分包商的單價負擔，同時確保 EHS 的執行品質由總包方統一控管。
EHS 要求與單價關係分析表
| 項目 | 是否導致單價增加？ | 增加的原因 | 創造的隱含價值 |
| 安全設備 (PPE/架子) | 是 | 實體資材投入 | 降低職災傷亡率 |
| 安全管理人員 | 是 | 人事成本編列 | 減少行政違規與停工罰單 |
| 教育訓練與工具箱會議 | 是 | 工時損耗 | 提升施工精準度、降低 Rework |
| 數位 EHS 監控 (BIM/AI) | 初始增加 | 設備租賃與系統建置 | 數據化管理，提升整體進度效率 |
風險提醒與法律警示
法規警示：根據台灣《職業安全衛生法》與《職業安全衛生管理辦法》，雇主對於承攬商應負「告知」與「指導監督」之責。若在採購時未明確規範 EHS，一旦發生事故，業主/總包商難逃連帶賠償責任及刑事過失。
合約風險：若 EHS 要求在發包後才追加，分包商有權要求契約變更（Variation Order）。因此，在招標文件中加入明確的「EHS 施工計畫要求書」是保護公司的首要步驟。
2021年8月6日 星期五
如果, 里程碑 Milestones 已經錯失或確定已經會錯失?
里程碑的定義必須清楚, 才能合適地排出深一層的工作事項及時程
對於已經錯失或確定已經會錯失的里程碑, 沒有進一步的因應措施說明
以上, 均導致團隊在執行工作時, 不容易感受到時間緊迫性
Level 1 與客戶的合約進度 Contract schedule
Level 2 交付進度 Delivery Schedule
Level 3 執行進度 Mid-range schedule (includ weekly)
發包時, 應該以Level 2 schedule
#進度管理
2021年7月1日 星期四
附屬系統與SCADA
案例: 附屬系統與SCADA
在附屬系統即將進行安裝後的查驗, SCADA的圖面整合更新了, 新增了"雜散點位"的清單:
包括了, 水池/塔, 油槽/箱的液位, 抽水加壓泵/馬達的運轉停止, 通風排氣風扇/百葉的開啟關閉, ...等
不過有些系統/設備自身的控制盤內, 並沒有可提供訊號到SCADA的裝置/接點 - 在採購時就沒有列出規格需要, 就沒有這些接點.
同時, 在管路的配置上, 也沒有留設足夠管徑的管路, 可以容納需要新增的電線.
因此, 不僅設備控制盤內的裝置需要更換, 管路費用, 也衍生了裝修的破壞及修復費用, 還可能因此耽誤了專案的交付時程.
「需求漂移」（Scope Creep）與「系統整合落差」（Integration Gap）往往是導致專案延宕、預算超支甚至失敗的「雙重殺手」。
這兩者並非獨立存在，而是具有強烈的負向連鎖反應。
以下為您進行全面的深度分析，並提供對應的整合性解決方案。
一、 雙重因素的交互影響
當這兩個因素結合時，會形成一個惡性循環：
需求漂移擴大整合難度：
在專案中後期若隨意增加功能，往往未考慮既有架構的相容性，導致原本已定義好的接口（API）或資訊流必須重改，產生新的整合落差。
整合落差誘發需求變更：
當系統進入整合測試階段，發現各模組無法串接（落差顯現），開發者為了「修補」這些落差，不得不增加額外的邏輯或中間層，這在實質上造成了非預期的需求蔓延。
影響矩陣分析
| 維度 | 需求漂移 (Scope Creep) | 系統整合落差 (Integration Gap) | 結合後的後果 |
| 成因 | 目標不明確、利害關係人干預、缺乏變更控制。 | 規格定義不全、技術債、通訊協定不一致。 | 專案失控： 既不知道要做什麼，也做不出來。 |
| 對成本影響 | 線性增長（人力、時間）。 | 指數增長（重構、除錯成本）。 | 預算黑洞： 不斷投入資源卻看不到成品。 |
| 對品質影響 | 功能過載導致系統穩定度下降。 | 資料丟失、邏輯錯誤、效能瓶頸。 | 架構崩潰： 系統變成難以維護的「義大利麵條」。 |
二、 四維防禦策略的解決方案
要解決這兩項問題，不能僅靠「管好需求」或「寫好代碼」，
必須採取一套跨職能的整合方案。
1. 建立「以合約為中心」的規格管理 (Contract-First Approach)
針對整合落差，應在開發前就定義好「溝通契約」。
API 優先開發： 在撰寫功能代碼前，雙方先確認並凍結 API 文檔（如 Swagger/OpenAPI）。
嚴格的變更控制委員會 (CCB)： 任何對 API 的修改都視為「重大需求變更」，必須評估其對所有下游系統的連鎖影響。
2. 實施「漸進式交付」與「早期集成」
避免傳統瀑布式的最後一刻才整合（Big Bang Integration）。
持續整合/持續部署 (CI/CD)： 每天進行自動化整合測試，確保新的需求變更不會破壞既有的整合點。
MVP (最小可行性產品) 定義： 嚴格鎖定首階段需求，禁止在核心框架未穩定前加入邊緣功能，從源頭遏止需求漂移。
3. 強化技術架構的彈性 (Architectural Decoupling)
微服務或模組化設計： 透過解耦/脫鉤，讓單一模組的需求漂移被限制在局部，不至於引發全局性的整合落差。
適配器模式 (Adapter Pattern)： 針對異質系統整合，建立標準轉接層，降低因需求變動導致的系統對接成本。
4. 建立透明的視覺化追蹤機制
需求追蹤矩陣 (RTM)： 將每一個需求與對應的整合測試案例綁定。若需求變動，系統能自動警示哪些整合點需要更新。
三、 防範於未然的核對清單
可以根據以下步驟，在專案啟動或中途進行校準：
1. 需求凍結點定義： 是否已明確定義哪些階段後不再接受「無償」的功能增加？
2. 接口規格書 (IDD) 簽署： 各模組負責人是否對資料格式、傳輸協定達成書面共識？
3. 預留緩衝 (Buffer) 評估： 針對「隱性整合成本」，是否在時程中預留了至少 20% 的整合除錯時間？
4. 模擬器開發： 在下游系統未完成前，是否已開發 Mock Server（模擬伺服器）進行早期壓力測試？
訂閱：
文章 (Atom)