創易分享

壹、前言

面對專案規模的日益增大及複雜化，在傳統工程管理上也面臨管理系統整合的困難度，時程管控系統也不例外，時程工程師所面對的管理型態已從傳統的單一專案到同時要面對多專案（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 大型工程與一般工程時程管控差異比較表

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

一、分階管理的目的
　　資訊管理系統建置的目的主要是要將管理過程中組織產生的資訊完全透明化，藉以提昇企業的能見度（visibility），使管理者得以充分掌握決策的資訊，在正確的時點，進行最佳的決策。而時程管控採取分階管理的目的，主要是在滿足不同管理階層對於進度資訊不同詳細程度的需求，愈高階管理者所關心的進度資訊愈抽象化，有的甚至只想要瞭解到進度資訊愈抽象化，有的甚至只想要瞭解到超前或落後，是否滿足契約完工日期等，但是愈基層的時程管控者所需要的進度詳細資訊程度就必須愈細，要詳細到足夠管控工程的進行，例如何時要進料、工班何時可以進退場等？因此在時程計畫的安排上就必須詳細到能夠反映這些的資訊，不同的管理階層所需求的時程管控資訊既然不同，因此在時程進度表所要展現的時程作業項目也就不會一樣。

　　在國內，最常見的進度分階方式是以綱要、中階、詳細時程等三層的分階管控模式，其中有些的時程階層名詞在不同的業主會有一些不一致，例如在高雄捷運計畫中，綱要時程稱為合約時程，合約時程表主要包含契約所規定重要的里程碑，例如優先通車路段的日期、全線通車營運等日期，其作業的內容與數量不應太多，需提供高階管理者計畫執行狀態直覺式的資訊。而中階時程表在高雄捷運計畫則稱為工作時程表，是高雄捷運公司計畫管控的主要依據，因此作業內容需詳細到足以管控計畫的進行，並作為各項時程管理報告輸出的依據，其內容除需依據合約時程發展外，需納入各區段標、系統標、軌道標的界面里程碑以作為界面整合使用，並需納入高雄捷運公司可以向高雄捷運局請款的付款里程碑，以作為財務單位財務規劃之依據，目前，紅、橘兩線的作業數量共約有2,000多個。

二、分階的模式

　　分階的模式若以時程作業（activities）的管理方式來歸類， 可以分成集中管理模式（consolidation model）與分散管理模式（delegation model）兩類。
　　集中管理模式即將計畫中的所有時程作業存放於同一時程專案中，並且由同一個時程管理團隊負責維護、更新、發佈進度警訊。集中管理模式又可以分成整合式及結合式兩種模式，整合式的管理環境是在計畫成立之時，即建立一套整合性的管理系統，使計畫中每一位時程工程師都可使用Web界面的方式進入共同作業平台進行專案時程的排程規劃。這是資訊工程師在發展管理資訊系統的一種理想的方式，但是每一個工程的特性、業主需求都不一致，要建置一套所有工程單位都適用的整合性管系統相當不容易，並且在計畫動員階段時間經常很緊迫，不允許有充足的時間去發展整合性管理系統，另外並不是所有的專案管理人員都習慣將他們自己的資料建置在別人的系統中，並且受系統存取權限的管理。
　　集中式管理的第二種方式是結合式的管理，這種管理的方法，在專案一開始時並不需要提供一個強大的管理系統或共同作業平台，每一個專案的管理者，依據自己的需求在自己個人的PC上進行時程規劃，而由專案協調者在專案辦公室選擇一個可以將所有個別專案進行合併的軟體，定期的將專案進行合併與進行跨專案分析的功能。這種方式在個別專案的時程工程師較不受到主專案辦公室的限制，提供個別專案較有彈性與自由的時程規劃作法。並且經過合併後，整個計畫的所有專案都會合併成為一個較大型的專案，在能見度方面是與整合式的管理系統一致的，專案的管理者都是可以看到專案中每一個作業執行的情形。

　　分散式管理則是允許計畫中的每一個專案，各自依其需求條件進行時程的規劃、發展及維護，而計畫中的專案管理組織則提供一個資料彙整的方式，能夠將下階時程表的進度彙整到上階來，以進一步進行整體計畫上階時程的更新、分析與報告。這種管理方式，下階的進度作業詳細資料並不會儲存到上階計畫管理組織的時程專案中，因此在計畫的能見度上當然不及集中式管理的方式，但是進一步思考，計畫管理組織中的成員是否有需要能夠即時的看到分標商或分包商詳細的進度資料，如果這些進度作業合併起來，數量經常是上萬個的，而這些未經彙整的進度資料經常是太過於細部，而不是較高階管理所需求的。例如高雄捷運中的土建工程統包標就有15標，每標的作業數量約1,000~4,000個，整個土建的作業數量高達30,000個以上，而機電標有13標，其作業量合計亦將近10,000個，因此要合併26標將近40,000個作業是必須相當耗時費力的，但效益並不明顯。因此在筆者進行高雄捷運時程管控系統的規劃上，經過如表2的比較分析後，對於工作時程與詳細時程的連結部分捨棄集中管理模式，而採分散管理模式。但是在紅橘兩線兩個專案的工作時程表，則保留將來能夠合併成一個完整專案的彈性，採集中管理模式，以進一步能夠產出屬於整體計畫的報告。

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

參、高雄捷運興建計畫時程管控系統介紹
一、分階進度資訊的連結
　　時程管控系統的建置，首先需要考量的就是對於系統使用者的需求，而這些需求具體的表現即是管理報告的要求，而高雄捷運局對於高雄捷運公司時程管理報告的需求，在契約附件中規定有：S曲線工作進度圖、三個月變動時程表、關鍵日期及里程碑現狀報告、時程分析報告、文件提送管制時間表等項目。在考量每月定期產出報告及進度檢討會中對於進度資訊的需求後，決定採用P3結合MS-Access作為每月進度更新及報告產出的軟體，其中P3是作為排程計算用，而MS-Access則作為每月進度計算與儲存各期進度資訊的資料庫，這些軟體使用簡單並且使用者界面容易被接受，更重要的是業主不需要花費很多的成本即能將管理的需求達成。

　　對於P3應用的界面不是本文介紹的重點，本文所關心的重點是如何將承包商的詳細進度表與興建計畫管理顧問發展的工作時程表間作連結，使得詳細時程表的更新資訊能夠回饋到工作時程表中。基本上承包商的詳細時程表是根據工作時程表進一步發展的，因此工作時程表中的作業與詳細時程表中的作業間存在一個一對多的關係，根據這種的關係，我們規範承包商進行系統規劃時，需依據詳細時程製作手冊，先至作業分類碼中定義一組為碼名為「COST」及中文名稱「CPM施工進度彙總」共計10個位元的分類碼（如圖3），以對應高雄捷運公司工作時程表中的作業代碼（ActivityID），各分標承包商只需在P3中鍵入屬於該標權責範圍內之編碼項目，完成作業分類碼編寫後，承包商需將細部時程表中各個作業項目所屬之工作分類碼編入，其中各作業項目中有預算者須完全編入，作業項目中無預算者視歸類狀況編入。完成上述的作業編碼，承包商依據每半月一次的更新頻率更新專案，更新的內容主要為將作業實際完成作業百分比（PCT）及預估剩餘工期（Remain Duration）輸入P3程式中，最後只要在產出報告時，選擇以「CPM施工進度彙總」彙總，即可產出屬於工作時程表中所需要的進度更新資料。

二、進度資料庫的建置

　　由於在P3(3.1版)中對於計畫執行過程各期進度資訊的儲存並沒有提供很好的功能，在進行專案的進度更新後，每一個作業的前期資訊即會被覆寫而導致資訊流失，為了能夠儲存每一個月每一個作業進度的執行情形，並且藉以計算不同彙總結果的進度資訊，例如，依據相同的進度作業內容必須分別以路線區分、土建與系統區分、政府出資與民間投資區分等不同的方式彙總出多樣化的進度資料給不同的需求者，因此資料庫的建置就顯得非常必要了。我們首先利用匯入ODBC資料庫的方式，使P3中目標專案的進度基本資料能夠匯入MS-Access中，並且利用關聯式資料庫的資料關聯圖來定義每一個基本表格的主鍵，將表格間的關係建立起來，並建立彙總計算與查詢的功能。
　　完成資料庫建置以後，在定期的專案進度更新過程，只需將承包商定期提送的進度完成百分比輸入資料庫中，資料庫即可以不同的需求自動彙總出不同型態的進度資訊，並且可以將輸入完成資料庫的作業進度來更新P3中的作業。從這裡可以發現傳統的P3版本在許多資料的儲存與管理方面都是不甚理想，並且要使用其內部的資料過程也不是十分的便利，為滿足除排程功能以外的管理需求，資料庫的建立是有其必要性的。
肆、結論與建議
　　雖然高雄捷運興建計畫管理顧問在時程規劃階段提供承包商自動彙總進度資訊的功能，但是在實際執行過程中發現還是有許多承包商，仍不採用排程軟體中進度彙總的方式，而是以經驗估計的方式填報進度給計畫時程管理團隊，但是因為每一個專案要傳送到計畫管理團隊的進度更新資料必須經過所屬專案負責人或授權人的簽認，因此在興建計畫管理顧問部分是可以相信他們資料的真實性，並且透過時程的稽核方式來確保承包商的細部時程專案有妥善的維護與管理，這也是採取分散管理式的優點之一，每一個團隊都需要對他們自己所負責工程的時程專案進行維護，而不是主專案管理組織中的時程工程師來負責維護計畫中所有的時程專案作業。
　　在建置與管理時程管控系統中，有幾點結論與建議如下：
一、並不一定是非常龐大的資訊系統，才能發揮時程管控的目的，在選擇排程系統時，必須考量大部分時程工程師的習慣，尤其大型工程參與者經常是有許多國外的公司參與，選擇適當的排程工具將非常有助於各種時程會議的溝通。
二、時程作業的定期更新維護，非常不容易貫徹與落實，因此對於多專案的時程管控，必須明確規範出每一個專案的管理組織所必須負責的權責，並定期追蹤。
三、目前的時程管理軟體已經有明顯的進步，文中所提到的管控方式，主要提供時程管控者做為參考，市面上的排程軟體對於多專案的管理，已經克服傳統P 3的很多使用者界面與資料庫共享運用的不便。但是在管理模式的規劃上，仍是要審慎的進行。
四、高雄捷運的時程管控系統，完全是由時程工程師所發展建置，我們的經驗是由系統使用者建置系統，是最能符合需求的，系統雖然沒有豪華炫麗的使用者界面，但是裡面每一個功能，都是必須的，並且時程工程師可以隨時掌握修改與擴充系統的彈性。
參考文獻
1.G. Edward Gibson ; Yu-Ren Wang ; YChung-SukCho; 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.張行道，「工期延遲預警系統之建立」，中華顧問工程司8 9年度研究計畫，高雄辦事處(2000)。
6.林宏政、林原養、陳懿佐、吳道生，「跨組織工程管理資訊系統技術之研究」，中華顧問工程司90年度研究計畫，高雄辦事處(2001)。