2專題報導

S P E C I A L R E P O R T

SUMMARY摘 要

│中│華│技│術│

46 │No.73│ January, 2007

2專題報導

No.73│ January, 2007 │47

大型工程分階時程管控實務探討-

以高雄捷運為例

關鍵詞：時程管控、多專案管理

中華顧問工程司／高雄辦事處／部門專案副理／陳懿佐

中華顧問工程司／高雄辦事處／副理／周允文

　　隨著工程規模的日益龐大以及複雜，不管是在工作的安

排、要徑作業的掌握、資源的調度、工作界面的整合及進度

延遲的預警、矯正與預防，時程管制系統扮演的角色日加

的重要，而時程管制要能在專案組織中被確實的落實，最重

要是時程管制系統必須能夠真正的發揮進度管控、預警的功

能，使管理者能夠感受系統達成的效益並進而支持系統的運

作，而這些功能的達成，是必須在執行計畫前加以妥善的規

劃。

　　本文主要介紹大型工程在進行時程管控系統建置過程

中，對於同時面對多專案（Multi-Project）管理需求時，可以

選擇採用的集中管理與分散管理兩種模式，並且以高雄捷運

為例，介紹時程管控團隊在建置系統中所選擇採用的模式，

及資訊系統建置過程資料連結與儲存等關鍵性的課題。可以

發現經過妥善的前置規劃，高雄捷運時程管制系統並沒有使

用到非常複雜的資訊技術及耗費龐大的軟硬體費用，但亦能

夠提供滿足契約所要求的進度報告，並符合整體計畫進度管

理的需求。

壹、前言

　　面對專案規模的日益增大及複雜化，在傳

統工程管理上也面臨管理系統整合的困難度，

時程管控系統也不例外，時程工程師所面對的

管理型態已從傳統的單一專案到同時要面對多

專案（Multi-project）的管理需求，更多的時程

界面需要整合、更多的資源必須統一的調度，

如何有效的將工地進度執行的資訊傳遞到專案

管理組織中，進行更新、分析、預警與追蹤，

是工程在進行時程管理系統規劃時，所必須嚴

肅思考的問題，因為若實際執行的進度資訊無

法有效的傳遞到工程的時程專案中，則時程管

控系統所發佈的進度狀態、預警資訊將嚴重的

失真，而失去時程管控系統當初所建置的目

的。

　　目前國內大部分的工程，經常是在工程進

度網圖送審後，就將網圖束之高閣，並未於工

程進行中定期將現況反應在網圖中，因此常發

生工程的現行時程（Current Schedule）與網圖的

目標時程（Target Schedule）隨著工程的進行相

形愈遠，而依據預算執行成果（Earned Value）

所發佈的執行進度百分比，其超前或落後並不

能完全反應進度執行是否能滿足如期完工的契

約需求。因此，大多數的工程不只是進度落後

甚至是處在失控的狀態，這雖不能完全歸責於

沒有將完整的時程制度建置起來所造成，但

是，如果有一套良好的時程管控系統，在工程

執行的過程中可以適時的將進度執行情形反映

出來，並針對異常狀況發佈預警，使得工程人

員能在延遲的早期，提出因應的方案，避免延

遲的擴大，這是可以做到的。

　　且目前時程管控軟體的功能已較前十年提

昇很多，時程管控系統可以採用的排程軟體在

功能上都大幅的提升，特別是在多專案管理管

理上，亦提供更有效率的使用者界面，例如P3

的E/C版本也注重到企業（Enterprise）這個層級

的需求，在專案的編碼系統上增加了OBS（組織

分工結構）、EPS（企業專案結構）的編碼，在

資料結構與使用者界面方面也已經完成跳脫P3

3.1版的方式，另外MS Project也提供企業專案管

理的(Enterprise Project Management ,EPM) 解決

方案，可以說因為在電腦軟硬體都大幅進步的

前提下，建置時程管控系統時所必須考量的問

題已經可以把資訊技術的障礙排除，而所必須

思考完全是管理可行性（manageable）及需求的

問題。

表1 大型工程與一般工程時程管控差異比較表

1 2

1

2

大型工程時程管控 一般工程時程管控

專案多寡

多專案 單一專案

時程作業數量

經常超過10,000個以

上

在數百至1,000個

左右

管理組織

參與管理人員眾多，

並且分散各處

管理人員不多，

集中一處

軟硬體特性

常需要效能較佳的硬

體，並多使用Web界

面，排程軟體需結合

較佳的資料庫

個人電腦

規劃重點

資源最佳化

要徑由資源所驅控

著重在企業層級

時程與施工方法

要徑經常不考慮

資源限制

著重在專案層級

資源特性

資源使用效益最大化、跨專案分享使用

資源需求最小

化、單一專案使

用

2專題報導

48 │No.73│ January, 2007

2專題報導

No.73│ January, 2007 │49

貳、分階管控模式系統探討

一、分階管理的目的

　　資訊管理系統建置的目的主要是要將管理

過程中組織產生的資訊完全透明化，藉以提昇

企業的能見度（visibility），使管理者得以充分

掌握決策的資訊，在正確的時點，進行最佳的

決策。而時程管控採取分階管理的目的，主要

是在滿足不同管理階層對於進度資訊不同詳細

程度的需求，愈高階管理者所關心的進度資訊

愈抽象化，有的甚至只想要瞭解到進度超前或

落後，是否滿足契約完工日期等，但是愈基層

的時程管控者所需要的進度詳細資訊程度就必

須愈細，要詳細到足夠管控工程的進行，例如

何時要進料、工班何時可以進退場等？因此在

時程計畫的安排上就必須詳細到能夠反映這些

的資訊，不同的管理階層所需求的時程管控資

訊既然不同，因此在時程進度表所要展現的時

程作業項目也就不會一樣。

　　在國內，最常見的進度分階方式是以綱

要、中階、詳細時程等三層的分階管控模式

（如圖1所示），其中有些的時程階層名詞在

不同的業主會有一些不一致，例如在高雄捷運

計畫中，綱要時程稱為合約時程，合約時程表

主要包含契約所規定重要的里程碑，例如優先

通車路段的日期、全線通車營運等日期，其作

業的內容與數量不應太多，需提供高階管理者

計畫執行狀態直覺式的資訊。而中階時程表在

高雄捷運計畫則稱為工作時程表，是高雄捷運

公司計畫管控的主要依據，因此作業內容需詳

細到足以管控計畫的進行，並作為各項時程管

理報告輸出的依據，其內容除需依據合約時程

發展外，需納入各區段標、系統標、軌道標的

界面里程碑以作為界面整合使用，並需納入高

雄捷運公司可以向高雄捷運局請款的付款里程

碑，以作為財務單位財務規劃之依據，目前，

紅、橘兩線的作業數量共約有2,000多個。

　　

　　詳細時程表在高雄捷運興建計畫中則是屬

於區段標承包商、系統供應商、軌道標承包商

所必須發展的時程表，根據高雄捷運公司的要

求，詳細時程表的單一作業時間是不能超過三

個月，雖然以這麼大的時間尺度來規劃，每一

個區段標完成排程後的作業都是將近數千個左

右。

二、分階的模式

　　分階的模式若以時程作業（activities）

的 管 理 方 式 來 歸 類 ， 可 以 分 成 集 中 管 理 模

式（consolidation model）與分散管理模式

（delegation model）兩類。

　　集中管理模式即將計畫中的所有時程作業

存放於同一時程專案中，並且由同一個時程管

理團隊負責維護、更新、發佈進度警訊。集中

管理模式又可以分成整合式及結合式兩種模

式，整合式的管理環境是在計畫成立之時，即

建立一套整合性的管理系統，使計畫中每一位

時程工程師都可使用Web界面的方式進入共同作

業平台進行專案時程的排程規劃。這是資訊工

程師在發展管理資訊系統的一種理想的方式，

但是每一個工程的特性、業主需求都不一致，

要建置一套所有工程單位都適用的整合性管理

系統相當不容易，並且在計畫動員階段時間經

常很緊迫，不允許有充足的時間去發展整合性

管理系統，另外並不是所有的專案管理人員都

習慣將他們自己的資料建置在別人的系統中，

並且受系統存取權限的管理。

　　集中式管理的第二種方式是結合式的管

理，這種管理的方法，在專案一開始時並不需

要提供一個強大的管理系統或共同作業平台，

每一個專案的管理者，依據自己的需求在自己

個人的PC上進行時程規劃，而由專案協調者在

專案辦公室選擇一個可以將所有個別專案進行

合併的軟體，定期的將專案進行合併與進行跨

專案分析的功能。這種方式在個別專案的時程

工程師較不受到主專案辦公室的限制，提供個

別專案較有彈性與自由的時程規劃作法。並且

經過合併後，整個計畫的所有專案都會合併成

為一個較大型的專案，在能見度方面是與整合

式的管理系統一致的，專案的管理者都是可以

看到專案中每一個作業執行的情形。

　　分散式管理則是允許計畫中的每一個專

案，各自依其需求條件進行時程的規劃、發展

及維護，而計畫中的專案管理組織則提供一個

資料彙整的方式，能夠將下階時程表的進度彙

整到上階來，以進一步進行整體計畫上階時程

的更新、分析與報告。這種管理方式，下階的

進度作業詳細資料並不會儲存到上階計畫管理

組織的時程專案中，因此在計畫的能見度上當

然不及集中式管理的方式，但是進一步思考，

計畫管理組織中的成員是否有需要能夠即時的

看到分標商或分包商詳細的進度資料，如果這

些進度作業合併起來，數量經常是上萬個的，

而這些未經彙整的進度資料經常是太過於細

部，而不是較高階管理所需求的。例如高雄捷

運中的土建工程統包標就有15標，每標的作業

數量約1,000~4,000個，整個土建的作業數量高

達30,000個以上，而機電標有13標，其作業數

量合計亦將近10,000個，因此要合併26標將近

40,000個作業是必須相當耗時費力的，但效益

並不明顯。因此在筆者進行高雄捷運時程管控

系統的規劃上，經過如表2的比較分析後，對於

工作時程與詳細時程的連結部分捨棄集中管理

模式，而採分散管理模式。但是在紅橘兩線兩

個專案的工作時程表，則保留將來能夠合併成

一個完整專案的彈性，採集中管理模式，以進

一步能夠產出屬於整體計畫的報告，其架構如

圖2所示。

集中管理模式（Consolidation model）

分散管理模式（Delegation

model） 整合式（Integrated） 合併式

系統特性

計畫提供專案整合性規劃平台

專 案 各 自規 劃 後 ，計 畫 提 供整 合 性 軟體

專案各自規劃、維護，計畫提供資料彙整方法

優點

在時程專案規劃階段即提供整合方法

專案的規劃受計畫限制性較小

專案經理可以依據權限自行規劃

主專案的管理者並不需要參與子專案作業的管理

缺點

資訊系統的軟硬體費用龐大

資料維護不易

整合性軟體成本高、資料維護不易

對於計畫的能見度不及集中式

圖1 三階時程管控示意圖

表2 時程管理系統模式比較表

綱要時程

中階時程

詳細時程

2專題報導

50 │No.73│ January, 2007

2專題報導

No.73│ January, 2007 │51

參、高雄捷運興建計畫時程管控系 統介紹

一、分階進度資訊的連結

　　時程管控系統的建置，首先需要考量的就

是對於系統使用者的需求，而這些需求具體的

表現即是管理報告的要求，而高雄捷運局對於

高雄捷運公司時程管理報告的需求，在契約附

件中規定有：S曲線工作進度圖、三個月變動時

程表、關鍵日期及里程碑現狀報告、時程分析

報告、文件提送管制時間表等項目。在考量每

月定期產出報告及進度檢討會中對於進度資訊

的需求後，決定採用P3結合MS-Access作為每月

進度更新及報告產出的軟體，其中P3是作為排

程計算用，而MS-Access則作為每月進度計算與

儲存各期進度資訊的資料庫，這些軟體使用簡

單並且使用者界面容易被接受，更重要的是業

主不需要花費很多的成本即能將管理的需求達

成。

　　對於P3應用的界面不是本文介紹的重點，

本文所關心的重點是如何將承包商的詳細進度

表與興建計畫管理顧問發展的工作時程表間作

連結，使得詳細時程表的更新資訊能夠回饋到

工作時程表中。基本上承包商的詳細時程表是

根據工作時程表進一步發展的，因此工作時程

表中的作業與詳細時程表中的作業間存在一個

一對多的關係，根據這種的關係，我們規範承

包商進行系統規劃時，需依據詳細時程製作

手冊，先至作業分類碼中定義一組為碼名為

「COST」及中文名稱「CPM施工進度彙總」共

計10個位元的分類碼（如圖3），以對應高雄

捷運公司工作時程表中的作業代碼（Activity

ID），各分標承包商只需在P3中鍵入屬於該標

權責範圍內之編碼項目，完成作業分類碼編寫

後，承包商需將細部時程表中各個作業項目所

屬之工作分類碼編入，其中各作業項目中有預

算者須完全編入，作業項目中無預算者視歸類

狀況編入。完成上述的作業編碼，承包商依據

每半月一次的更新頻率更新專案，更新的內容

主要為將作業實際完成作業百分比（PCT）及

COST

圖4 時程資料關聯圖建立

圖5 預定進度查詢畫面

圖2 高雄捷運時程資料彙總與報告架構

圖3 定義作業分類碼

2專題報導

52 │No.73│ January, 2007

2專題報導

No.73│ January, 2007 │53

預估剩餘工期（Remain Duration）輸入P3程式

中，最後只要在產出報告時，選擇以「CPM施

工進度彙總」彙總，即可產出屬於工作時程表

中所需要的進度更新資料。

二、進度資料庫的建置

　　由於在P3(3.1版)中對於計畫執行過程各期

進度資訊的儲存並沒有提供很好的功能，在進

行專案的進度更新後，每一個作業的前期資訊

即會被覆寫而導致資訊流失，為了能夠儲存每

一個月每一個作業進度的執行情形，並且藉以

計算不同彙總結果的進度資訊，例如，依據相

同的進度作業內容必須分別以路線區分、土建

與系統區分、政府出資與民間投資區分等不同

的方式彙總出多樣化的進度資料給不同的需求

者，因此資料庫的建置就顯得非常必要了。我

們首先利用匯入ODBC資料庫的方式，使P3中目

標專案的進度基本資料能夠匯入MS-Access中，

並且利用關聯式資料庫的資料關聯圖來定義每

一個基本表格的主鍵，將表格間的關係建立起

來（如圖4所示），並建立彙總計算與查詢的功

能（如圖5所示）。

　　完成資料庫建置以後，在定期的專案進度

更新過程，只需將承包商定期提送的進度完成

百分比輸入資料庫中，資料庫即可以不同的需

求自動彙總出不同型態的進度資訊，並且可以

將輸入完成資料庫的作業進度來更新P3中的作

業。從這裡可以發現傳統的P3版本在許多資料

的儲存與管理方面都是不甚理想，並且要使用

其內部的資料過程也不是十分的便利，為滿足

除排程功能以外的管理需求，資料庫的建立是

有其必要性的。

肆、結論與建議

　　雖然高雄捷運興建計畫管理顧問在時程規

劃階段提供承包商自動彙總進度資訊的功能，

但是在實際執行過程中發現還是有許多承包

商，仍不採用排程軟體中進度彙總的方式，而

是以經驗估計的方式填報進度給計畫時程管理

團隊，但是因為每一個專案要傳送到計畫管理

團隊的進度更新資料必須經過所屬專案負責人

或授權人的簽認，因此在興建計畫管理顧問部

分是可以相信他們資料的真實性，並且透過時

程的稽核方式來確保承包商的細部時程專案有

妥善的維護與管理，這也是採取分散管理式的

優點之一，每一個團隊都需要對他們自己所負

責工程的時程專案進行維護，而不是主專案管

理組織中的時程工程師來負責維護計畫中所有

的時程專案作業。

　　在建置與管理時程管控系統中，有幾點結

論與建議如下：

一、並不一定是非常龐大的資訊系統，才能發

揮時程管控的目的，在選擇排程系統時，必須

考量大部分時程工程師的習慣，尤其大型工程

參與者經常是有許多國外的公司參與，選擇適

當的排程工具將非常有助於各種時程會議的溝

通。

二、時程作業的定期更新維護，非常不容易貫

徹與落實，因此對於多專案的時程管控，必須

明確規範出每一個專案的管理組織所必須負責

的權責，並定期追蹤。

三、目前的時程管理軟體已經有明顯的進步，

文中所提到的管控方式，主要提供時程管控者

做為參考，市面上的排程軟體對於多專案的管

理，已經克服傳統P3的很多使用者界面與資

料庫共享運用的不便。但是在管理模式的規劃

上，仍是要審慎的進行。

四、高雄捷運的時程管控系統，完全是由時程

工程師所發展建置，我們的經驗是由系統使用

者建置系統，是最能符合需求的，系統雖然沒

有豪華炫麗的使用者界面，但是裡面每一個功

能，都是必須的，並且時程工程師可以隨時掌

握修改與擴充系統的彈性。

參考文獻

1.G. Edward Gibson ; Yu-Ren Wang ; YChung-Suk

Cho; and Michael P. Pappas “What is Preproject

Planning, anyway?” Journal of Management in

Engineering ASCE/January (2006).

2.陳懿佐，「工程完成價值之時程預警架構介

紹」，現代營建280期(2003)。

3.「高雄都會區大眾捷運系統紅橘線路網建設案

興建營運合約」附件C3甲方對計畫執行期間提

送文件之規定，高雄市政府、高雄捷運股份有

限公司(2001)。

4.「詳細時程製作手冊」中華顧問工程司、高雄

捷運股份有限公司(2002)。

5.張行道，「工期延遲預警系統之建立」，中

華顧問工程司89年度研究計畫，高雄辦事處

(2000)。

6.林宏政、林原養、陳懿佐、吳道生，「跨組織

工程管理資訊系統技術之研究」，中華顧問工

程司90年度研究計畫，高雄辦事處(2001)。