運用資料流程圖建構先期規劃需求整合流程模式

國

立

交

通

大

學

土木工程學系

碩士論文

運用資料流程圖建構先期規劃需求整合流程模式

Applying data flow diagram to derive the owner’s needs of

construction projects

研 究 生：李青樺

運用資料流程圖建構先期規劃需求整合流程模式

Applying data flow diagram to derive the owner’s needs of

construction projects

研 究 生：李青樺 Student：Ching-Hua Lee

指導教授：王維志 Advisor：Wei-Chih Wang

國 立 交 通 大 學

土木工程學系

碩 士 論 文

A Thesis

Submitted to Department of Civil Engineering College of Engineering

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

In

Civil Engineering June 2008

Hsinchu, Taiwan, Republic of China

運用資料流程圖建構先期規劃需求整合流程模式

研 究 生：李青樺 指導教授：王維志 博士

國立交通大學土木工程學系（研究所）碩士班

摘要

公共工程於先期規劃階段的需求整合作業對後續工程進行順利與否有著極重要的 影響。在此階段，工程主辦機關（業主）需要整合各種需求據以概估工程經費，進而擬 定徵選建築師之招標文件。實務上各工程主辦機關多為非工程專責機關或有專業人力不 足的情形，常使業主無法明確的整合出需求，以致將錯誤及不足的需求訊息傳遞給建築 師，進而衍生出後續設計階段需經過冗長且複雜的需求探討作業，後果往往導致工程成 本浪費與期程的延宕。 本研究模式係建構在「各機關辦理公有建築物手冊」內容中，敘述先期規劃作業辦 法及規定的基礎上，配合專家訪談瞭解先期規劃整合作業內容之主要整合重點，再予以 探討實務案例於執行先期規劃需求整合作業的操作經驗後，利用資料流程圖（DFD）模 式化方法將先期規劃需求整合作業操作過程予以系統化的呈現出來，模式之功能除了引 導使用者進行需求整合作業外，更提供一個具體化的作業流程，以使使用者知道該得到 哪些作業資料或資訊，且進行哪些作業步驟以完成需求整合作業，以提高需求整合作業 之效率及整合內容之確實。 關鍵詞：先期規劃書、需求整合流程、資料流程圖（DFD）

Applying data flow diagram to derive the owner’s needs of

construction projects

Student：Ching-Hua Lee Advisor：Wei-Chih Wang

Department of Civil Engineering

National Chiao Tung University

Abstract

Public construction in owner’s needs of construction projects of advanced planning phase has a respectable influence for subsequent development. In this phase, the construction competent authority (the owner) may integrate all needs to estimate expenditure generally, and then frame the auditioning architect documents. In the practice, the owners are not major in construction or lack of professionals, and the owners would not able to integrate needs particularly so that convey the erroneous and insufficient needs information to architect, moreover, derive lengthy and perplexed needs conference operations in the post-design phase that results in consequence of consumed construction cost and delayed progress.

The model of this study is based on the regulations and rules of advanced planning in

The Operations Companion of Establishment Transacting Public Construction and collates

the interviews of professional to realize the integration emphasis about owner’s needs of construction projects, and then, after probes into the practical examples about experiences of the projects, applies data flow diagram (DFD) to derive the projects systematically. The functions of model not only guide users to integrate needs but provide a concrete operation process, which informs users about what information and which operations steps they needs; so that may upgrade the efficiency of owner’s needs of construction projects and implement the integration distinctly.

誌謝

本論文之所以能夠順利完成，首先要感謝的是指導教授 王維志博士悉心指導。在 研究所生涯兩年期間，王老師無論在研究的啟發、課業的解惑及做人處事的態度都給予 極大的啟發及幫助，於此致上最誠摯之敬意與謝意。另承蒙黃世昌教授及楊智斌教授適 時的指導，以確立研究的方向，亦在此致上最深的謝意。此外，感謝口詴委員楊智斌教 授、楊亦東教授及范素玲教授在論文口詴期間給予的指導及建議，使論文的內容更加嚴 謹、充實。 在論文撰寫的過程中，承蒙博士班汪俊男學長、林俊昌學長、劉正章學長、鄭淵源 學長提供了寶貴的實務經驗與專業見解，使得本研究得以從客觀且貼近實務現況的角度 予以完成論文撰寫，於此併以致上由衷的感謝。 在兩年的求學期間，感謝營管組碩士班的諸位學長姐的建議與照顧；亦感謝聖堯、 浩仰、芳如、昊志、竣鴻、士祥、彥宏、敦威、怡然、士豪、怡如、世偉、佳琪、維屏、 君瑋、帝幕等同窗好友們陪伴我渡過這有點驚濤駭浪卻又多采多姿的研究所生活，於此 除了感謝再感謝之外也只能互道珍重再見，期許大家畢業後都能有很好的發展。 在大學求學期間，承蒙鄭道明教授的提攜與教導，使得猶如迷途羔羊的我得以重新 找尋到通往光明的道路。亦感謝陪我渡過研究所考詴前那段難熬時光的大學好友秉軒、 傑源、東星、玉瑛、世權、建穎、國能、韋岑。 最後，感謝生我育我及養我的母親大人，由於您不厭其煩的尊尊教誨及無私的付 出，才能使我於求學的過程中在無後顧之憂的情況下完成研究所學業；感謝大妹偉如、 小妹虹薇與我一同分享成長過程中的喜樂；亦感謝與我一同分享生活中的酸甜苦辣且一 路支持我的詵婷，由於你們的支持與期盼化作我向前行的力量，使我能夠無畏的面對且 戰勝求學過程中的種種挑戰，於此謹將本論文成果呈獻給你們，並獻上我最誠摯的感謝。

目錄

摘要 _____________________________________________________________________ I Abstract __________________________________________________________________ II 誌謝 ____________________________________________________________________ III 目錄 ____________________________________________________________________ IV 圖目錄 _________________________________________________________________ VII 表目錄 __________________________________________________________________ IX 第 1 章 緒論 ___________________________________________________________ 1 1.1 研究動機 _______________________________________________________________ 1 1.2 研究問題 _______________________________________________________________ 2 1.3 研究目的 _______________________________________________________________ 3 1.4 研究範圍及探討階段 _____________________________________________________ 4 1.5 關鍵名詞定義 ___________________________________________________________ 5 1.6 研究方法與流程 _________________________________________________________ 5 第 2 章 文獻回顧 _______________________________________________________ 8 2.1 前言 ___________________________________________________________________ 8 2.2 規劃設計理論 ___________________________________________________________ 8 2.2.1 建築規劃與設計 ______________________________________________________________ 8 2.2.2 設計溝通與媒介 ______________________________________________________________ 9 2.2.3 價值觀衝突 _________________________________________________________________ 11 2.3 業主需求管理之重要性與過往研究_________________________________________ 11 2.4 競圖制度探討 __________________________________________________________ 13 2.4.1 競圖制度的歷程 _____________________________________________________________ 13 2.4.2 競圖過程問題 _______________________________________________________________ 16 2.5 流程相關文獻探討 ______________________________________________________ 18 2.5.1 流程（Process）定義 _________________________________________________________ 18 2.5.2 資訊流程 ___________________________________________________________________ 20 2.5.3 流程模式化方法 _____________________________________________________________ 21 2.5.4 模式化方法比較分析 _________________________________________________________ 32 2.6 小結 __________________________________________________________________ 35

第 3 章 資料流程圖（DFD）模式化方法 __________________________________ 36 3.1 前言 __________________________________________________________________ 36 3.2 資料流程圖的架構 ______________________________________________________ 36 3.2.1 過程（The Process） _________________________________________________________ 36 3.2.2 資料流（The Flow） _________________________________________________________ 37 3.2.3 資料儲存所（The Store） _____________________________________________________ 38 3.2.4 外界實體（The Terminator） __________________________________________________ 38 3.3 由上至下的資料流程圖（Top-down DFD） _________________________________ 39 3.3.1 高層次資料流程圖（High-Level Diagram） ______________________________________ 39 3.3.2 低層次資料流程圖（Low-Level Diagram） _______________________________________ 40 3.4 小結 __________________________________________________________________ 41 第 4 章 現況調查與案例探討 ____________________________________________ 42 4.1 前言 __________________________________________________________________ 42 4.2 現行公共工程先期規劃整合作業流程_______________________________________ 43 4.2.1 新興個別建築工程計畫有關作業及審議流程 _____________________________________ 43 4.2.2 先期規劃整合方式及內容 _____________________________________________________ 45 4.3 研究案例分析 __________________________________________________________ 50 4.3.1 案例 A _____________________________________________________________________ 50 4.3.2 案例 B _____________________________________________________________________ 60 4.3.3 案例 C _____________________________________________________________________ 68 4.4 小結 __________________________________________________________________ 70 第 5 章 先期規劃需求整合流程模式建構與應用 ____________________________ 73 5.1 前言 __________________________________________________________________ 73 5.2 先期規劃需求整合作業內容之定義_________________________________________ 73 5.3 先期規劃需求整合流程模式_______________________________________________ 73 5.3.1 模式假設 ___________________________________________________________________ 74 5.3.2 模式建構（先期規劃需求整合流程模式環境背景圖） _____________________________ 75 5.3.3 模式建構（先期規劃需求整合流程模式 Layer1） _________________________________ 81 5.4 模式作業細部資料流程與說明（Layer2） __________________________________ 93 5.4.1 空間量體評估（P1.1）資料流程圖 _____________________________________________ 96 5.4.2 工程經費概估（P1.2）資料流程圖 ____________________________________________ 105 5.4.3 設計準則整合（P1.3）資料流程圖 ____________________________________________ 113

5.5.1 案例資料選擇說明 __________________________________________________________ 125 5.5.2 先期規劃需求整合流程模式應用情境（Use Case）－案例 A _______________________ 129 5.5.3 先期規劃需求整合流程模式應用情境（Use Case）－案例 B _______________________ 133 5.5.4 先期規劃需求整合流程模式應用情境（Use Case）－案例 C _______________________ 136 5.6 小結 _________________________________________________________________ 140 第 6 章 結論與建議 ___________________________________________________ 141 6.1 結論與建議 ___________________________________________________________ 141 6.2 未來研究方向 _________________________________________________________ 141 參考文獻 _______________________________________________________________ 143

圖目錄

圖 1-1 設計準則整合作業流程 ... 2 圖 1-2 研究階段... 5 圖 1-3 研究流程圖 ... 7 圖 2-1 建築規劃與設計之關係概念圖 ... 9 圖 2-2 設計思維的黑箱與明箱 ...10 圖 2-3 業主和建築師關心的事 ...11 圖 2-4 傳統競圖流程 ...14 圖 2-5 採購法委託技術服務作業流程 ...15 圖 2-6 生產作業文件流程圖 ...23 圖 2-7 DFD 四元素圖說 ...24 圖 2-8 IDEF0 基本語法的 ICOM 圖及應用...27 圖 2-9 IDEF3 的流動流程圖 ...28 圖 2-10 IDEF3 的物件狀態轉移動圖 ...29 圖 2-11 簡單的派翠網範例 ...30 圖 2-12 同時處理的派翠網範例 ...31 圖 3-1 資料流程圖圖說 ...36 圖 3-2 Process 範例 ...37 圖 3-3 Flows 範例 ...37 圖 3-4 Store 範例 ...38 圖 3-5 Terminators 範例 ...39 圖 4-1 公共工程規劃階段作業與審議程序關係圖...42 圖 4-2 新興公共工程各階段計畫及經費估算作業流程 ...43 圖 4-3 委託專案管理申辦作業流程 ...46 圖 4-4 案例 A 新建工程工作組織架構圖 ...51 圖 4-5 案例 A 專案組織需求問題決策模式圖 ...53 圖 4-6 案例 A 規劃階段需求作業整合操作模式 ...54 圖 4-7 案例 A 設計準則整合作業流程 ...59 圖 4-8 案例 B 新建工程工作組織架構圖 ...61 圖 4-9 案例 B 專案組織需求問題決策模式圖 ...64 圖 4-10 案例 B 規劃階段需求作業整合操作模式 ...64 圖 5-1 先期規劃需求整合流程圖 ...75 圖 5-2 先期規劃需求整合流程模式環境背景圖 ...76 圖 5-3 建廠小組會議（P1）作業內容分解架構圖 Layer1 ...81 圖 5-4 先期規劃需求整合流程模式 Layer1 ...82 圖 5-5 建廠小組會議作業內容分解架構圖 Layer2 ...95

圖 5-7 工程經費概估（P1.2）資料流程圖 Layer2 ... 106

圖 5-8 設計準則整合（P1.3）資料流程圖 Layer2 ... 114

圖 5-9 案例 A 工程經費概估資料流程圖 Layer2... 132

圖 5-10 案例 B 空間量體評估資料流程圖 Layer2 ... 135

表目錄

表 2-1 流程的定義 ...19 表 2-2 Flowchart 優缺點整理 ...22 表 2-3 DFD 優缺點說明整理 ...24 表 2-4 IDEF0 優缺點說明整理 ...25 表 2-5 IDEF3 優缺點說明整理 ...26 表 2-6 派翠網優缺點說明整理 ...30 表 2-7 模式化方法在四個觀點上的支援能力比較...32 表 4-1 專案管理廠商服務作業內容 ...47 表 4-2 一般辦公室空間面積計算表 ...48 表 4-3 先期規劃建築工程單位面積直接工程成本概估表 ...49 表 4-4 案例 A 規劃委員會會議內容摘要表 ...54 表 4-5 案例 A 建廠小組工作會議內容摘要表 ...55 表 4-6 案例 A 機能空間類別及空間需求評估說明 ...56 表 4-7 案例 A 興建委員會會議內容摘要表 ...60 表 4-8 案例 B 先期規劃討論會議內容摘要表 ...65 表 4-9 案例 B 機能空間類別及空間需求評估說明 ...66 表 4-10 案例 B 先期規劃討論會議內容摘要表 ...68 表 4-11 三案例先期規劃需求整合文件架構比較表 ...71 表 5-1 建廠小組會議（P1）資料傳遞關係表 ...77 表 5-2 空間量體評估（P1.1）資料傳遞關係表 ...83 表 5-3 空間需求評估報表架構 ...84 表 5-4 工程經費概估（P1.2）資料傳遞關係表 ...86 表 5-5 工程經費概估報表架構 ...87 表 5-6 設計準則整合（P1.3）資料傳遞關係表 ...89 表 5-7 特殊空間評估（P1.1.1）資料傳遞關係表 ...98 表 5-8 特殊空間需求評估報表架構 ...99 表 5-9 特殊空間需求調查表架構 ... 100 表 5-10 一般空間評估（P1.1.2）資料傳遞關係表 ... 101 表 5-11 空間量體整合（P1.1.3）資料傳遞關係表 ... 103 表 5-12 特殊空間經費概估（P1.2.1）資料傳遞關係表... 107 表 5-13 一般空間經費概估（P1.2.2）資料傳遞關係表... 109 表 5-14 工程經費概估整合（P1.2.3）資料傳遞關係表... 111 表 5-15 研擬設計準則架構（P1.3.1）資料傳遞關係表... 115 表 5-16 一般需求整合（P1.3.2）資料傳遞關係表 ... 118 表 5-17 特殊需求整合（P1.3.3）資料傳遞關係表 ... 119

第1章 緒論

1.1 研究動機

無論營建的標的為何，工程業主於規劃階段對於需求表達的方式及整合詳細程度， 對後續工程進行順利與否有著最重要的影響。然而實務上工程業主多為非工程專責機關 或有著專業人力不足的情形，此一情形常導致業主無法確實的將其需求整合出來，以致 錯估工程經費和傳遞錯誤及不足的需求訊息給建築師，進而衍生出後續設計階段需經過 冗長且複雜的需求探討作業，其所造成的是營建工程成本浪費與期程延宕。 公開競圖制度是目前國內公共工程於規劃階段時，徵選建築師較常採用之方式，此 一制度能協助工程業主徵選到符合或近似業主需求想法之建築師（設計團隊）。然而採 用競圖制度的前提為，業主必頇在徵選建築師前的先期規劃階段作業中，將先期規劃書 （亦稱需求計畫書）確實的整合出來，以做為建築師設計競圖之依據。然先期規劃書係 工程業主根據其對未來的新建建築標的物使用需求及想法的表達，進而整合出由圖、表 或文字組成的文件。但基於工程業主多為非工程專責機關或機關內專業人力不足的情 形，又每個專業領域都有其專業的訓練背景與專業的養成過程，造成業主與建築師對於 每個欲興建的建築標的物基本認知與認識，也依據本身的專業背景主觀定義【莫國箴， 2003】，故所產生的先期規劃書往往無法明確的將業主需求訊息整合並傳遞給建築師， 然而此一誤差訊息傳遞給建築師後，會造成遴選出來的建築師因為設計錯誤或是設計未 能滿足業主需求，需要面對冗長且複雜的設計修改，其所呈現的成果是為悖離設計競圖 制度的原意，更對整體工程的經費期程有負面的影響。 針對業主多為非工程專責機關及專業人力不足所造成上述的問題，於工程會所編撰 之【各機關辦理公有建築物作業手冊】第二章提出以下辦法：鑑於興辦公有建築物之主 辦機關大多非屬工程專責機關，故主辦機關可依「機關辦理工程委託專案管理廠商評選 及計費辦法」於新興個別計畫之房屋建築工程報經上級機關核可委託工程專案管理廠 商，並陳行政院核可相關費用，以協助主辦機關辦理規劃、設計及監造單位之評選、設 計圖說之審查、招標、施工管理與完工驗收等作業。主辦機關徵選規劃、設計、監造或 專案管理廠商，除得採公開招標或選擇性招標外，視工程性質或規模，依下列方式之一 辦理，倘屬公告金額以上者，應成立評選委員會，主辦機關並得視案件規模成立工作小 組襄助評選委員會辦理競標事宜。

換言之，各機關可依照上述的辦法來執行先期規劃書整合作業（圖 1-1），由過往 傳統業主評估整合、建築師設計；轉變為業主委由工程專案管理人員或自行成立工作小 組（工程專業人員）評估整合、建築師設計，進而解決因專業性不足所產生之上述問題。 然而專案管理人員或工程專業人員是經過哪些作業流程及步驟，以整合出最符合業 主需求的先期規劃書，是本研究欲探討的重點；因此，利用資料流程圖系統化的建構出 先期規劃需求整合流程模式，供工程業主於先期規劃書整合前有一個系統化之整合作業 流程可依循，又工程專業人員能透過此一模式所提供之資訊，進而進行有效率之評估及 整合作業。 業主 (評估整合) 建築師 (設計) 先期規劃書 傳統流程 業主 (構想) 使用需求 工程專業人員 (評估整合) 先期規劃書 建築師 (設計) 現行流程 圖 1-1 設計準則整合作業流程

1.2 研究問題

過往研究針對營建專案管理主要仍以施工階段為主，又於規劃階段先期規劃書整合 作業的研究上以探討業主與建築師之間的作業關係為多，探討業主與工程專業人員之間 的作業關係較為少見。本研究主要目的為建構一於先期規劃階段需求整合流程模式，協 助業主將其需求透過系統化的作業流程模式整合，以利產出最符合業主需求的先期規劃 書。基於以上所述，再進一步將實務上於先期規劃書整合過程中與整合後所面臨的問題 歸納如下：

 整合過程中： 業主與專案管理人員（工程專業人員）間異業認知的差異，造成需求資訊傳遞上的誤差。 此一問題發生於，業主經由工程專業人員協助執行先期規劃書的整合工作，工程專 業人員於此時主要的工作為將需求調查所取得的需求資訊或資料及專業顧問所提供之 專業建議整合成先期規劃書，其表示之內容可以是文字也可以是圖表；但是，工程專業 人員與業主間因為專業領域的不同所形成的異業認知差異，實務上往往會有下列下列情 形發生：（1）工程專業人員無法確實了解業主表達之需求訊息便將自身的認知轉化為 文字或圖表的情形發生（認知差異）；（2）業主對建物的結構、空間規劃、設計及建 築相關法規等等皆無法充分了解，因此造尌整合的內容需求表達不明確或是不合乎常理 及使用慣性（異業認知）。  整合後： 無法評估業主需求是否具體的整合於先期規劃書中。 實務上，業主或工程專業人員對先期規劃書的完成認定，多屬於規劃時程上的認定 以及業主個人主觀認定，也因此常常造尌先期規劃書會有需求條件過於空泛以及未提及 的部分發生。會造尌此一原因為業主無一個系統化的方式來檢視先期規劃書是否明確的 表達自身需求或是有遺漏的部分；然雖有工程專業人員代業主彙整先期規劃書，但基於 異業認知的差異亦造成完成先期規劃書後，其需求內容表達完整度還是無法達到業主的 需求。 故本研究主要在於探討先期規劃書整合過程中及整合後所面臨的問題，用來作為建 構先期規劃階段業主需求整合流程模式之基礎。

1.3 研究目的

為解決上述於先期規劃階段需求整合的問題，本研究之主要目的在於建立一個於先 期規劃階段需求整合流程模式，以協助業主透過此一模式能將先期規劃書系統化的整合 出來並且能協助其確認需求明確的被表達於該文件中，工程專業人員亦可透過此模式資 料傳遞之作業關係，找出各參與作業單位於執行作業時的關聯，以轉化為最符合該工程 專案需求整合流程策略，使各參與作業單位能夠依循此一模式提出正確的需求資訊以供 整合成真正符合業主需求的先期規劃書。因此本研究主要的目的有以下兩點：

 藉由文獻回顧、專家訪談、文件分析及案例蒐集了解先期規劃需求整合時，主要整 合重點及架構，並將案例之先期規劃需求整合作業經驗操作流程彙整成先期規劃需 求整合作業經驗學習檔案。  以本研究所採用的三個案例的需求整合流程為基礎，探討影響需求整合作業成果之 關鍵因素並建立明確且有系統的整合作業資料流程，使業主及工程專業人員瞭解自 己要做什麼且要得到哪種需求資訊來完成整合作業。 結合先期規劃需求整合作業經驗檔案配合先期規劃需求整合資料流程模式圖的展 示，所建構的先期規劃階段需求整合流程模式，有系統的整合出符合業主需求的先期規 劃書。

1.4 研究範圍及探討階段

尌目前國內公有建築物及重大工程生命週期主要分為：規劃階段、設計階段、發包 施工階段、完工驗收階段四大階段，如（圖 1-2）所示。本研究主要著重於規劃階段業 主需求整合作業過程。又目前台灣以發展高科技產業為目標，科技設施（ high-tech facility）之建造已成為目前營建業中不容忽視的一塊【王維志等，2001】，但是科技設 施的需求複雜、介面繁多，使得在規劃階段之需求整合作業更顯複雜。因此，在科技設 施工程中，利用先期規劃需求整合流程模式將業主各項需求系統化的整合成符合工程專 案特性及業主需求的先期規劃書，更是比一般工程更值得重視的課題。 總結上述說明，茲將本研究之研究範圍及探討階段歸納如下：  研究範圍 因建築工程種類繁多，僅以國家科技實驗室設施新建工程為研究類別。  探討階段 針對先期規劃階段之業主需求評估及整合作業流程進行探討。

規劃階段 評估 專案設定 徵選建築師 設計階段 業主需求確認 初步設計 細部設計 發包施工階段 工程發包及施工 土木/機電/特殊 機電 完工驗收階段 工程驗收 營運 圖 1-2 研究階段

1.5 關鍵名詞定義

 先期規劃書： 工程主辦機關對於委託評選標的，應提供先期規劃書或稱為需求計畫書，詳細載明 該標案的使用用途、規劃原則及構想、空間及機能需求、經費概估、其他特殊或重要需 求….等等，俾供參選的技術服務廠商作為規劃設計的基礎，並使參選案件契合需求機關 的原始期望。  工程專業人員： 當工程主辦機關為非工程專責機關時，對於興辦工程之各項管理及行政作業上較無 專業性可言，此時機關基於工程效率可透過委託專案管理廠商或尋求增加內部工程專業 人員來協助工程順利進行。然而專案管理廠商與工程專業人員之間的共同點為，具有工 程專業背景執行專案管理之工作；異同點為，其處於主辦機關組織型態上的組成不同， 工程專業人員屬主辦機關直接聘任之，編制上屬主辦機關內部人員。

1.6 研究方法與流程

本研究之內容主要可區分為六個章節，各章節之研究方法與架構概述如下，而研究 流程圖如（圖 1-3）所示： 第一章：緒論

主要敘述本研究之動機、研究問題、研究目的、範圍與方法，並擬定研究架構與流 程，藉以做為研究進行之準則。 第二章：文獻回顧 藉由瞭解規劃設計理論、業主需求管理相關研究、競圖制度的探討、流程相關研究 等論述，進一步釐清於規劃階段需求整合作業流程的問題，並藉由流程模式化方法之比 較確立研究工具。 第三章：資料流程圖模式化方法 本章詳細說明研究工具之特性及使用方式。 第四章：現況調查與案例探討 先藉由瞭解目前公共工程對於先期規劃階段需求整合作業之規定及辦法；再藉由三 個國家實驗室新建工程的實際案例，分析探討與比較其於先期規劃階段需求整合作業流 程的內容，以作為模式建構之基礎。 第五章：模式建構與應用分析 以第三章所說明之研究工具為基礎，透過第四章整理之內容建構出先期規劃階段需 求整合流程模式，並透過模式套用之成果據以檢視本研究所提出模式的可用性。 第六章：結論與建議 本章總結研究成果與結論，並對未來相關研究提出建議。

研究動機與目的確立 研究方法與流程確立 文獻回顧 規劃設計理論探討 業主需求管理研究 競圖制度探討 釐清及確立研究問題 流程模式化方法比較 研究工具確立及說明 公共工程先期規劃作 業辦法及相關法規瞭 解 案例介紹與分析 專家訪談 需求整合模式建構 模式應用與說明 結論與建議 第一章 第二章 第三章 第四章 第五章 第六章 圖 1-3 研究流程圖

第2章 文獻回顧

2.1 前言

根據上一章內容所述，本研究主要目的為建構一套針對工程於先期規劃階段時需求 整合流程模式，以協助業主能將其需求明確的表達於先期規劃書當中。因此本章之內容 為針對建立本研究之需求整合流程模式所需具備之理論與工具進行文獻回顧。然而其內 容將由 2.2 節規劃設計理論的介紹，據以瞭解先期規劃書的整合於規劃設計作業中的定 位；2.3 節為介紹業主需求管理過往相關之研究，據以釐清本研究模式之方向；2.4 節為 整理現行競圖制度之實施，與說明該制度與先期規畫書內容之關聯；本研究為運用資料 流程圖建構本研究之模式，於 2.5 節為介紹流程相關文獻據以探討各模式化方法及優缺 點比較；最後於 2.6 節則將本章之內容作一簡明之小結。

2.2 規劃設計理論

建築規劃乃是針對未來需求所擬採取的行動，進行分析與選擇的過程，建築設計可 說是建築規劃的產物，針對事先規劃所擬定的行事方法，包括目標及可行方案。在建築 專業的養成教育中，規劃與設計是需經過一定的概念形成與操作修改，其中也存在著許 多與設計者本身自我理念與堅持，透過建築規劃與設計的相關文獻研究，找出可供本研 究後續發展的理論依據，並先期了解建築師在規劃設計上的特定價值觀，找出可能影響 建築師對設計條件認知效果的相關議題。

2.2.1 建築規劃與設計

對於建築規劃與設計之關係，黃世孟有以下說明：規劃一般係指事先做出的一種做 事程序的方法，或對各部分配置安排。而設計則強調按照目標、意象成目的而作的小心 安排。依此定義可瞭解二與關係中，尌程序論而言存在前後之關係，尌實際內容而言具 有精粗之別【黃世孟，1990】。 在建築物之製產過程中，一般均經歷各種不同專業者、業主或使用者共同參與的階 段。規劃階段的各種決策及決定，要有明確的後續指示課題及方向，供設計階段的銜續

轉化為有用的「資訊」。 規劃報告書可以說事業主將興建此建築的構想、調查分析之過程與結果、所有的價 值標準的取向及主張，透過一冊完整的規劃歷程紀錄及宣言，將自己需求的建築以建築 條件書為媒介由規劃階段交棒到設計階段。 由上所述，設計條件書的任務是在溝通業主、建築師之間的觀念；扮演業主與建築 師溝通的角色。然而一份能夠將業主需求想法明確整合的設計條件書，要透過哪些步驟 及作業流程來整合，需要進一步的去討論。 建築構想 檢討興建行為、社 經背景、市場條件 等外部需求特性之 分析 建築區位條件、基 地建物規模、配置 動線機能、營運財 務等分析 規劃(前段) 規劃(後段) 規劃 基本構想 基本計畫 建築規劃報告書 建築空間種類、規 模、營造經費、使 用條件、管理組織 等設計條件 建築設計條件書 基本設計 建築基地都市設 計、建築機能空間 配置、量體造型設 計等建築基本設計 設計(前段) 空間造型設計、平 面、立面、剖面、 施工圖等細部設計 細部設計 設計(後段) 建築施工 設計 圖 2-1 建築規劃與設計之關係概念圖 【資料來源：黃世孟，1990 年】

2.2.2 設計溝通與媒介

建築設計者在設計過程時會以外顯或內隱的方式呈現自身的設計信念，然設計信念 的傳達需仰賴建築師與業主之間的溝通媒介。建築規劃日漸重要且普及,而建築師作業逐 漸由設計導向轉為專案企劃性質，建築師無法只以自己之意識進行設計作業，而不顧及 團隊完整服務流程及與業主之溝通。

建築實際上是個在三度空間中立體的龐然大物，建築師為了使自己和他人能充分感 受設計的內容，最重要的媒介（media）尌是使用各種不同的圖（drawings）和模型（models） 來比擬日後實際的建築量體與空間。Zeisel 在 1981 年已經指出在共享環境與行為印象， 要如何表現，而溝通雙方經由語言媒介而對同一事物，各自在心中所產生之意象不相同 的現象【劉育東，1996】。設計方法中的明箱、暗箱與程序【楊裕富，1998】，以往認 為設計是人類心靈的重要機制，設計、構思的機制都視為黑箱，但在 1960 年代，人類 已有足夠的知識逐漸將黑箱化為明箱，藉由資訊工程的概念，人類可以更清楚的描述出 這心靈部分的操作模式，如（圖 2-2）。 心靈機制 (猶如電腦) 黑箱 Input Input Input 設計條件 設計資料 設計問題 Output 設計作品 (符合條件) (解決問題) 具 體 化 評 估 選 則 形 成 方 案 綜 合 構 思 分 析 蒐 集 資 料 確 定 問 題 Input Input Input 設計條件 設計資料 設計問題 Output 設計作品 明箱 圖 2-2 設計思維的黑箱與明箱 【資料來源：楊裕富，1998 年】 藉由設計階段的溝通過程與溝通媒介，可以增加建築師與業主之間的互相信任與彼 此互動，也可讓需求滿足與設計決策的制衡過程透明化。現階段公部門的運作方式中， 將規劃及設計以發包方式斷開，僅藉由設計需求條件進行溝通，而大學圖書館以設計需 求條件作為規劃設計階段業主對建築師需求提出的溝通媒介，過於單向訴求較缺乏雙向 互動，而條件主要內容以文字、圖說方式表達，在建築師的解讀過程可能為因為專業背 景的不同，產生解讀方向的差異，因此在這樣的制度之下，設計需求條件的形式、內容 對於建築設計資訊的溝通有著相當程度的阻礙。

2.2.3 價值觀衝突

每一個計畫當中都會有一些不同的價值觀念，端賴業主、使用者、基地、氣候、甚 至計畫擬定者和設計師的態度而定【Robert, 2001】。而價值衝突實際情形如（圖 2-3） 所示，業主跟建築師之間的觀念差異極大。公部門以設計條件書歸納業主在建築規劃階 段的想法、策略、需求、計劃理念，再將這些設計資訊及價值觀轉移給設計專業於進行 後續設計作業。設計資訊在兩個傳承中因專業立場不一、關心向度不同、表現方式差異 等等產生認知上失真之現象，以致設計作業產生偏差，因而導致價值觀衝突的結果【葉 士玄，2001】。然而在這樣的情形之下，業主所關心的事項是否能有效的轉化為先期規 劃書，也是本研究在建構先期規劃需求整合流程模式時需加入探討的。 使用壽命 彈性 效能 時程 成本 資源 基地條件 活動項目 限制條件 服務 關係 系統 空間 機能 造型 建築師 業主 圖 2-3 業主和建築師關心的事 【資料來源：Robert,2001】

2.3 業主需求管理之重要性與過往研究

很多人談到需求分析時，並沒有認真去定義到底什麼是「需求」。評估者談到需求 評量時，通常是指「實然」和「應然」之間的差距，【Roth,1990】則更進一步指出，當 人們心中感受到他們心中需要什麼東西的時候，和實際狀況之間至少有下列五種狀態的 差距：（1）理想狀態；（2）一般狀態；（3）最低標準；（4）最佳狀態；（5）預期

狀態。

而一般所討論的需求很少以理想狀態作為比較基準，比較常見的是採用低於一般的 標準來定義需求，不過如此一來，只要表現超過一般或預期的標準，甚至只要超過最低 的標準，尌會被視為沒有需求【Scriven & Roth,1990】。因此單靠一種簡單的差距或不 足來定義需求是不合邏輯的。 以建築工程方面來分析，設計者在規劃階段頇將業主之需求項目，具體而明確的呈 現，以作為設計的依據。然而業主對於需求項目的表達，往往是一連串的語意描述詞（如 光線要明亮），而且需求項目之重要性及其相關性亦無法明確的表示。此外，一個完整 的設計方案是由眾多的設計要素構成，而各設計要素又可分為不同的選項。因此有必要 建立能將業主需求項目系統明確地呈現，而且得以尋求最佳設計組合的工程設計決策模 式【陳惠娟，2004】。 又一般設計專案之作業項目乃依據專案目標即業主需求進行解析而得，而其工作內 容大多是在處理資訊，但由於作業所需之資訊內容具有不確定性，因此設計作業往往需 透過反覆資訊傳遞方能得到一合適的設計結果，而反覆設計之範圍可能橫跨多個設計作 業項目，形成一個或數個反覆執行的迴圈，迴圈中作業項目越多，越易導致設計作業的 缺失。由於設計作業間之關係大多取決於資訊的流向，因此【王思琳，2005】發展一套 以資訊流傳遞行為為基礎之作業程序評估方法，以確切評量各條資訊流對於設計作業程 序所產生的不同程度的影響，並在促進規劃效率方面，應用快速混雜基因演算法之於大 型排列組合問題之求解能力，建構一完整之設計作業程序規劃之最佳化模式，以提供管 理者於處理設計作業程序規劃問題時之參考。 經由上述內容，過往研究已利用數種不同工具，如資訊模式（information modeling methods）、最佳化（optimization）、數據結構矩陣（Data Structure Matrix）和電腦工具 等，研究發展出數種以利業主掌控規劃和設計階段所具有各種特性之模式，例如資訊從 屬、設計循環的次數和合作環境等等，這都使業主管理作業更加完善。但目前似乎沒有 針對國內科技設施工程特性，所建立的需求整合流程模式，以協助業主與管理者在規劃 階段能系統化的將複雜且龐大的作業及使用需求整合，又整合的過程當中遇到需求表達 不明確的情形該如何解決，將是本研究所需探討的方向。

2.4 競圖制度探討

按「機關委託技術服務廠商評選及計費辦法」第六條之規定：「機關委託廠商承辦 公有建築物之技術服務，其金額在新台幣五百萬元以上者，應要求廠商提出服務建議書 及設計圖並辦理競圖」。因此，只要該技術服務預算金額在新台幣五百萬元以上者，機 關一定要要求建築師於參與評選投遞標單時一併提出服務建議書並附上設計圖辦理競 圖。 技術服務涉及競圖者，各機關辦理公有建築物作業手冊中明定招標文件除依前條規 定者外，應另載明計畫之目標及原則、工程名稱及地點、基地資料，包括地籍圖、都市 計畫圖、地形圖或現況圖及其他相關資料、規劃、設計內容，包括空間用途、數量、使 用人數或面積、使用方式、設備需求、特殊需求及其他需求、允許增減面積比例、工程 經費概算、工程期限、圖說內容、比例尺、大小尺寸、張數及裱裝方式等、表現方式， 包括模型、透視圖及顏色需求等。

2.4.1 競圖制度的歷程

台灣公共競圖的發展最早為東海大學校園規劃公開徵求設計開始，這項規劃案在當 時的社會背景下也引起相當大的震撼，在 1970~1999 年間共舉辦了 240 件競圖案，競 圖案以匇部為主佔總件數 64.5%之多，其次為南部地區的 23.3%【石國宏，2000】，當 時的競圖由於缺乏規則也產生了許多諸如改由評審設計(東海大學校園規劃公開徵求設 計、中山博物院公開比圖)、推翻評選優勝設計案改由他案替代(二二八建碑競圖、私人 的統一國際大樓競圖)等等爭議的問題。 採購法於民國八十八年施行以後，各機關辦理公有建築物之採購自此有了依據，與 競圖選商較相關的有政府採購法、機關委託技術服務廠商評選及計費辦法、招標期限標 準、最有利標評選辦法、各機關辦理公有建築物作業手冊，這對建築師爭取公共建築物 設計委託權的經驗來說是一大變革，傳統競圖（圖 2-4）與採購法委託技術服務作業流 程（圖 2-5）。

1.確定地點 2.先期規劃設計建築 師遴選 3.經費來源 1.資料蒐集 2.地質鑽探 3.地質分析報告 1.編著規劃方案 2.先期規劃報告書定 稿印製 1.規劃方案選定 2.經費預算編列 1.擬定徵圖頇知及委 託契約書 1.擬定徵圖公告稿 刊登廣告及通函建築 師公會 發(售)徵圖頇知 遴聘評審委員及名單 保留方式 作品及收件步驟 初選作業 複選作業 1.辦理平面審定 2.舉辦作品觀摩 3.受理退件 通知簽約及核發工本 費 決選過程及簽辦結果 1.辦理細部設計 2.編製預算書 (含水電空調) 申請建造 取得建造後發包施工 準 備 階 段 競 圖 徵 圖 階 段 設 計 階 段 圖 2-4 傳統競圖流程 【資料來源：賴忠男，1997 年】

圖 2-5 採購法委託技術服務作業流程 【資料來源：各機關辦理公有建築物作業手冊】 經原底價核定人 或授權人核准 達查核金額 招標文件釋疑 投標 查核金額以上案件 上級機關派員監辦 內容變更另行公告 資格審查公告 招標公告 發售或發給 招標文件 邀請合 格廠商 前置作業 公開招標 選擇性招標 限制性招標 資格 審查 超底價額度 最低標低於底價 最低標是否合理 決 標 決標結果公告 協商 綜合評選 最有利標 廢標 無法評定 4~8% >8% <4% 審查投標文件 審查結果通知 議價 開價格標/評比價格 異議處理 申訴 不合格者敘明理由 合格者 廠商不服 廠商 不服 減價 經上級機關核准採最有利標 開標 Y N 公告金額以上案件 邀 請 二 家 以 上 廠 商 比 價 邀 請 一 家 廠 商 議 價 審查投標文件 N Y N 比減價格後_仍超底價 上級機 關核准 Y N N 廢標 N Y 核定底價 成立評選委員會 期限內提出合 理說明或擔保 Y N Y 次低標標價合理 6 是否緊急 N Y Y

2.4.2 競圖過程問題

在公告招標前置作業過程，主辦工程機關頇擬定招標文件，它是提供建築事務所投 遞服務建議書重要參考依據，在計畫目標不易量化情形下，若招標文件資訊含糊，不易 正確評選出最優適合之建築師。另外複雜性高、專業性特殊之案件也難保能招募到合適 的評審委員，會因評選者專業背景不同而產生不同之評選結果。所以主辦機關需透過更 嚴謹的方式來撰寫招標文件及慎選評審委員。然而，招標機關辦理競圖，其所花費之預 算經費來自於人民的納稅，因此辦好一件競圖案、選擇適合之建築師、避免重新招標， 為招標單位應盡的責任。華昌琳在競圖經驗談中提到，一件失敗的競圖往往有以下的原 因【華昌琳，1998】： 一、因案子功能複雜具多面性及高度不確定性，難以在工作計畫書中說明。 二、因設計與審核程序中需介入多方面意見，而難以事先掌握。 三、因基地周圍或基地上隱藏許多難以克服的限制或問題，是主辦單位或參 選者所不清楚的，如交通問題或地質斷層等。 四、工程經費不足或來源無著落的情況。 五、籌備不周及時間不足者。 尌採購法的實施招標機關與建築師間認知上的差異，綜合文獻及其研究之見解做機 關辦理委託建築技術服務作業現況問題的研析，陳毓全提出如下之內容【陳毓全，2006】： 一、 計畫需求的不確定 計畫需求及目標不明確，是目前大部分主辦機關之通病，主辦機關在面對工程專案 計畫時，限於人力及專業知識及時間急迫性，常常無法在招標文件中明確訂定工程計畫 之需求及預期目標；造成技術服務廠商在研擬服務建議書時沒有明確依據，若因認知不 同無法掌握計畫核心於評選時往往失去得標機會，這種結果尤以非工程主辦機關為盛， 原因是非工程主辦機關專業知識的不足。 一般而言，政府機構欲新建辦公大樓其計畫書上的需要並不代表實際需要，它僅供

完成發包作業，否則預算可能會被繳回國庫，而作業單位並無辦理工程之專才，以致競 圖均拖延到會計年度截止前匆匆辦理。 計畫需求的不確定在於招標單位的溝通沒有充分瞭解，承辦員與單位主管間、招標 單位與上級機關間、招標單位與評審委員間事先都需經開會充分理解需要，而對於「需 求」總是無法令人滿足，一但制定需求表並據以辦理設計競賽，決標後機關理當不得以 需求變化為由而要求優勝建築師變更設計，失去原本競圖的用意。公共建築物最終的使 用者是社會大眾，而招標機關只是人民的代理人，因此如何讓工程的服務需求回歸到民 眾，並符合大多數民眾的需求而致使滿意，是一個重要的課題。 二、 採購對象的不確定 建築技術服務的採購對象可分選拔作品與甄選設計服務團隊兩種。競圖的目的在挑 選作品或挑選構想，而不是挑選設計團隊，但在國內這兩者的差別卻是含糊不清。「競 圖」一詞常被濫用、誤用，如果目的是甄選最有資格、經驗或合適的規劃設計者，則尌 不是競「圖」，便不應該要求在所提的服務建議書(Proposal)內或是簡報時附上設計圖。 採購法對這兩者的區分是以服務費用五百萬元來做區隔，但實際上普遍的現象是在服務 建議書(Proposal)中均附上設計圖，或是基於迎合業主貪小便宜的心理附上設計，雖名為 資格甄選型式上卻像是競圖，或是由於主辦單位採購標的名稱的誤導，讓人以為機關是 要辦理設計競賽。 按「機關委託技術服務廠商評選及計費辦法」第六條之規定：「機關委託廠商承辦 公有建築物之技術服務，其金額在新台幣五百萬元以上者，應要求廠商提出服務建議書 及設計圖並辦理競圖」。因此，只要該技術服務預算金額在新台幣五百萬元以上者，機 關一定要要求建築師於參與評選投遞標單時一併提出服務建議書並附上設計圖辦理競 圖，金額五百萬元以下之精神實乃為甄選適合之設計服務團隊，服務建議書內容以文字 為主輔以概念圖，但按服務建議書評比表機關又得逕行決定評比項目及權重，評比設計 項目權重過高時讓人誤以為機關是要辦理競圖。因此所謂五百萬元以上服務費用的競 圖，當然不是指於評選作業外，另闢一「競圖」程序，而是將設計固定為評選項目之一， 由評選委員會於綜合評選時將其納入所有評選項目中，一併評選決定之，此與傳統依「各 機關辦理公有建築物作業要點」第十點辦理建築物公開徵圖、比圖設計於圖紙貼於圖板 上，評出最優者再與其議價之方式不同。 然而經由過往研究可以瞭解，於競圖制度的實施下，對業主確認需求作業的管理面

有顯著的幫助，但是探討衍生上述問題的主要因素不外乎尌是業主對於需求無法明確表 達進而造成的，因此建構一個能夠將業主需求明確且系統化整合的先期規劃需求整合流 程模式，更顯得有其必要性。

2.5 流程相關文獻探討

本研究之目的為建立明確且有系統的先期規劃需求整合流程模式，希望透過此一模 式能夠達到清楚描述需求單位、整合單位及其他參與者各作業流程間的資料流動及功能 導向的結構化分析，下列將從流程的定義探討，以瞭解流程應具備的各種構面與觀點， 最後舉出幾個常用的流程模型及流程模式化方法，並對其特性做分析及比較，以找出最 符合本研究建構模式需求之方法，並在第三章詳細敘述。

2.5.1 流程（Process）定義

本文主要以流程描述的角度探討各種不同的模式化技巧，將各種模型的特性作分析 比較，以為爾後選取最佳模型之參考，因此必頇先對流程的定義作詳細的說明。由於應 用領域的不同，流程的定義也會有些許的不同。現在將各種不同領域的學者專家對流程 的不同定義各舉一個代表例子如下︰ (1) 以系統的角度來說，流程是系統內的質、能、或資訊，在歷經時間流逝時所發生 的所有改變【謝長宏，1999】。 (2) 以流程管理的角度來說，流程是指為達成某一特定目標或結果所必頇具備的種種 系列性作業活動，這些作業活動內容包括了人員、設備、材料、制度、方法與時 間【王立志，1999】。 (3) 以作業管理的角度來說，流程是將單一或多項投入轉換(或加值)成顧客所需 的一 項或多項產出的一個或一組活動【Krajewski,2005】。 (4) 以軟體的角度來說，流程是為達到目的之一組部份有序的步驟【Feiler,1993】。 (5) 以工作流程的角度來說，流程是企業流程的形式化觀點，以為達共同目標而連結 的一組互相協調的(平行及或系列)流程活動集合來表示【WfMC,1999】。

下： (1) 有一定的目標。 (2) 以順序或平行方式執行活動。 (3) 有起動者。 (4) 攜行資料。 一個良好的流程模式化之方法應具有的能力，可以參考【王崇丞，1999】在企業流 程描述語言之研究論文中，提出六點應有特性如下： (1) 具功能、行為、組織、資訊等四個構面。 (2) 以圖表示而非文字。 (3) 應淺顯易懂。 (4) 必頇有一套正規的語法與規則。 (5) 能夠處理較複雜的情況。 (6) 能作為資訊及或企業的分析工具。 以系統的觀點來看，流程、功能及行為有相互依賴與影響的關係。流程與功能必需 相對應，系統的任何流程必頇要有對應的功能呈現才具意義。系統之任何功能呈現必頇 要有對應的流程來運作，該一功能方可呈現。系統行為是系統流程的表現，也是系統功 能在作用的表現【謝長宏，1999】。一般而言，系統流程的外在表現是系統的行為，而 其運作所達的結果是由於系統發揮其應有的功能。系統元素是功能表現聚集的地方。元 素之間的關係引起了互動行為的流程，因此元素和流程是整個系統的主要描述。 表 2-1 流程的定義 定義 出處 應用領域

A locus of control within an instruction sequence. In general a process has two aspects: it is a data carrier and it will execute actions.

Horning and Randell

(1973) Information A set of partially ordered steps intended to reach a goal. Feiler and Humphrey

(1993)

A process is simply a structured, measured set of activities designed to produce a specified output for a particular customer or market.

T.H.Davenport (1993)

Business A process has inputs, processing and outputs, just as do the

simpler conceptualizations of systems.

Earl (1994) Business A formalized view of a business process,represented as a

co-ordinated (parallel and/or serial) set of process activities that are connected in order to achieve a common goal.

The Workflow Management Coalition Specification

(WfMC,1999)

Information

A set of coordinated activities (human or automatic) and services integrated to reach a common goal.

Aversano and Canfora (2002)

Business The representation of a business process in a form which

supports automated manipulation, such as modeling, or enactment by a workflow management system

J. Li,B. Maguire and Y.

Yao (2003) Business A partially ordered set of activities, the execution of which

will result in the achievement of some objective of the enterprise. This execution needs to be obtained by some trigger, called event.

A. Abdmouleh ,M. Spadoni and F.Vernadat (2004)

Business

【資料來源：李中奇，2006】

2.5.2 資訊流程

Curtis 在流程模式化(Process Modeling)中對流程作了一些詳盡的描述。Curtis 引述 Feiler 對流程的定義：流程是為達到目的之一組部份有序的步驟【Feiler,1993】。流程中 的任何構件(Component)都是一個流程元素(Process element) 。流程步驟(Process step)是 流程中的一個如原子的行動(atomic action)，其從外觀測應無可見的次層結構。流程元素 是否尌是流程步驟，其部份決定因素是依據元素結構是否可再向下分解而定。若無法再 向下分解，則流程元素尌是流程步驟。Curtis 又說，任務(Task)之於活動(Activity)尌好像 流程之於流程元素或流程步驟。 Curtis 提出資訊流程模式化的四個觀點，經常被學者專家視為模型參考之準繩，理 由是這些觀點包括了人、事、時、地、物以及如何等情境的相當完整描述，其內容如下 【Curtis,1992】： (1) 功能面(Functional)：呈現在執行的流程元素能作什麼(What)及與這些流程元素有關

(2) 行為面(Behavioral)：呈現何時(When)流程元素在執行(例如，進行順序)及經由回饋 環圈? 代、複雜決策條件、進入及離開的標準條件等，這些時候流程元素如何(How) 的執行。 (3) 組織面(Organizational)：呈現組織內流程元素被誰(Who)在何處(Where)所執行傳遞實 體的有形的溝通機制，以及儲存實體的有形的媒體與所在位置等三種情形。 (4) 資訊面(Informational)：呈現某一流程所產出或安置的資訊實體，這些實體包括資料、 人工製品、中間及終端產品，以及物件。此觀點包括了資訊實體的組成及實體之間 的關係。

2.5.3 流程模式化方法

流程模式化的方法有很多種，本研究取常用的幾個作為探討的對象。它們有流程圖 (Flowchart)、資料流程圖(Data Flow Diagram, DFD)、整合電腦輔助製造定義工具(ICAM DEFinition)中的 IDEF0 與 IDEF3、以及派翠網(Petri-Nets)等五種。

A. 流程圖(Flowchart)

流程圖一般可分為程式流程圖(Program Flowchart)、系統流程圖(System Flowchart) 及文件流程圖(Document Flowchart)等類型【Ivancevich,1992】。流程圖亦可簡單分為兩 類，一為資訊流程圖，另一為事務流程圖。程式流程圖可以歸類為資訊流程圖，是早期 撰寫程式語言時，用來表示整個程式的撰寫邏輯，使程式設計師能依據此發展步驟來編 碼及追蹤測詴程式以除錯，代表圖形少而簡單，但有嚴謹的語法。 系統流程圖亦可以歸類為資訊流程圖，主要描述系統內資料從進入到產出，按順序 所歷經的整個資料流動過程。常用在描述電腦檔案資料的更新過程，以及顯示資料處理 的所有有關部門。 文件流程圖可以歸類為事務流程圖，主要顯示有形文件的流動諸如發票的開立到最 後的處置。文件流程圖主要在描述人工流程及指出內部控制的弱點，代表圖形很多，語 法比較不嚴謹，（圖 2-6）為一個生產作業的文件流程圖範例。 Flowchart 採用美國國家標準學院(ANSI)的規範圖形符號，最早是以長方形代表程 式步驟、菱形代表決策步驟、圓形代表終止、橢圓形代表輸出入步驟、箭頭線代表流動 方向等五個基本簡單圖形及後續衍生的一些圖形來描述整個活動。Flowchart 的優缺點

如（表 2-2）所示： 表 2-2 Flowchart 優缺點整理 優點 缺點 展現一個系統的全部結構，追蹤資訊及 工作的流動。 沒有描述同時處理的能力，只有描述順 序流程的能力。 描繪在有形的媒介物上資料的進入、產 出及儲存。 僅能提供基本設施工具，為簡單的溝通 圖示法。 強調關鍵處理及決策點。 無執行能力(Execution Ability)，無法直 接將它實作(Implementation)於系統中。 方便使用 【資料來源：李中奇，2006】

營業部 生產處 倉儲部 產品 請製單 產品 2 請製單 填寫製令 製令 生產作業 成品入庫 成品入庫 成品入庫單 1 成品入庫單 1 圖 2-6 生產作業文件流程圖 【資料來源：王貳瑞，2001】

B. 資料流程圖（Data Flow Diagram,DFD） 資料流程圖是由 Tom DeMarco 於 1978 年開始使用於資訊軟體分析與設計。資料 流程圖是結構化分析之圖形化文件工具之一，DFD 為透過一個功能過程的相互作用與邏 輯性的資料來描述一個系統的運作流程，並利用圖表來確認、瞭解運作流程中的衝突與 多餘處，可說是一個幫助模式化的有利工具。【Kim,1992】在探討石油化學工廠工程 （Petrochemical Construction）研究中，將 DFD 的圖形分為圓形、箭頭、長方形以及兩 邊開口長方形如（圖 2-7）四類，茲將其所代表之意義簡單的說明如下： 代表是資料的輸入與輸出的轉換流程（Process）。 代表資料獲得的目的地（Terminator）或是來源地。 代表一個儲存（Store）的作業與動作，如建構資料庫作業。 代表資料流動（Flow）的方向箭頭。 圖 2-7 DFD 四元素圖說 而（表 2-3）則將 DFD 之優缺點列出比較： 表 2-3 DFD 優缺點說明整理 優點 缺點 清楚描述資料的流動。 適合靜態環境的描述，在動態的環境 中，功能面描繪的一個改變，將導致資 料流程圖重新繪製的嚴重改變。 展示發生什麼事情(What)。 缺乏時間構面的觀點，資料流程圖沒有 提供時間元素去定出流程的先後發展 順序；換言之，因缺乏行為面的描述而 無法對流程塑模，此為其致命缺陷。 以功能為導向的結構化分析。 有同時處理(Concurrency)能力

C. 整合電腦輔助製造定義工具(ICAM DEFinition, IDEF)

IDEF 中的 ICAM 為整合電腦輔助製造(Integrated Computer-Aided Manufacturing) 的縮寫。IDEF 家族共有 IDEF0(Function Modeling)、IDEF1(Information Requirements Modeling) 、 IDEF2(Simulation Modeling) 、 IDEF3(Process Description Capture) 、 IDEF4(Object Oriented Design) 、IDEF5(Concept/Ontology Description) 、IDEF6(Design Rationale capture) 及 IDEF1X(Data Base Design)等八種，其中常用於流程模式化的為 IDEF0 與 IDEF3 。 IDEF0 與 IDEF3 皆 適 用 於 系 統 分 析 ， 但 不 適 用 於 系 統 設 計 【Plai,1995】。 IDEF0 以活動為主要描述，擷取組織所想要做的是什麼。活動可以依據所需精練細 度的要求，而作向下之分解。IDEF0 所描述的活動樣式與所發生的時間及所引起的部門 都無關係。它在辨別何者為組織核心活動及何者為次要功能上是非常有效的。它不支援 流程的規範說明，使得活動的細節無法得知【Mayer,1995】。Plaia 認為 IDEF0 未明示 各活動之間時間的限制，並不表示它不能用來描述一組活動在特定時間次序下的流程。 真正不易表達的是兩個平行處理的活動。 IDEF0 的基本組成是以一個盒形圖表示活動的內容，外接四個箭頭符號表示輸入 (Inputs)、控制(Controls)、輸出(Outputs)與機制(Mechanisms)等所謂的 ICOM 圖。輸入表 達活動所需的原料與資料，輸出表達活動結果的產出，控制表達活動的限制與調節，可 以是人或其它活動來作用，而機制表達執行活動的資源，可以是人、機器或其它活動來 作用。IDEF0 的 ICOM 圖及應用例子，如（圖 2-8） 所示。IDEF0 的優缺點如（表 2-4） 所示： 表 2-4 IDEF0 優缺點說明整理 優點 缺點 以活動為核心，描述功能面及資訊面。 無邏輯決策 由上而下分解，使得複雜的系統，可用 簡單明瞭的功能模式表達。 無時間順序 無同時處理能力 無法直接將它實作於系統中。 【資料來源：李中奇，2006】 IDEF3 是一個劇情(Scenario)驅動流程流動模式化方法。IDEF3 的目標是針對一個

特定的組織內特定的問題如何去解決，提供一個領域專家表達知識的結構化方法 【Mayer,1995】。行為單元(Unit of Behavior, UOB)為 IDEF3 語法的基本單元，以盒形 圖來表示。UOB 甚至可以更進一步的被分類為功能、活動、動作、流程、操作、事件、 劇情、決定或程序等名稱。每個 UOB 內都可以包含兩個部份，一個是相關的向下分解 UOB，一個是包括物件、事實、拘限及描述等資料之詳盡描述表(Elaboration)。每一個 UOB 可以經由接合點(Junction)與連結(Link)互相連接。接合點提供語意的表達，使同步 及非同步的行為描述變得容易。連結包括優先次序連結、關連連結及物件流動連結等三 種。IDEF3 可以向下分解，也可以向上聚合。IDEF3 的圖形表達有兩種， 一為流程流 動描述(Process Flow Description)，另一為物件狀態轉移描述(Object State Transition Description)。（圖 2-9）為 IDEF3 的流程流動圖的基本概貌。（圖 2-10）為 IDEF3 的 物件狀態轉移圖的基本輪廓。經過整理分析後，IDEF3 的優缺點如（表 2-5）所示： 表 2-5 IDEF3 優缺點說明整理 優點 缺點 使用情境(Scenario)為基本結構，以描述 劇情的發展。 未能充分有力的清楚展示不同活動中 的資訊流動。 展示事情是如何發生的(How)，有行為 面觀點。 缺乏組織的描述。 可由上至下分解，也可由下至上結合。 無法直接將它實作於系統中。 【資料來源：李中奇，2006】

活動 輸出 輸入 控制 機制 Set Up Machines Foreman Set Up Equipment Set Up Plan Make Products Set Up Document Raw Materials A & B Machine Operator Production Machines Process Plan Inspect Products WIP Production Plan Product A & B Inspection Equipment Inspector 圖 2-8 IDEF0 基本語法的 ICOM 圖及應用 【資料來源：Mayer,1995】

X 1 接收物料 退貨 6 發現瑕疵 5 檢驗合格 4 3 抽樣檢驗 入庫 2 X 圖 2-9 IDEF3 的流動流程圖 【資料來源：李中奇，2006】

Customer Telephone Call

Order Received Order Opened Order Split

Order B to Backorder Order A to Picker

Order Filled

圖 2-10 IDEF3 的物件狀態轉移動圖 【資料來源：Giaglis,2001】 D. 派翠網(Petri-Nets)

派翠網是由德國學者 Carl Adam Petri 於 1962 年所提出。派翠網能夠反應系統的改 變，廣泛的被接受為動態系統模式化。它是一個含有數學法的圖形化表達工具。它的圖 形基本上是由位置(Place)節點、轉移(Transition)節點及具方向性的連接線段(Arc)所組成 的一個雙節點的方向圖(Bipartite Directed Graph)。因基本派翠網不是那麼簡潔及容易處 理 高 階 複 雜的 企 業 系統 模 式 化 ， 修 正 的高階 派 翠 網 包括 一 般 化隨 機 預 測派 翠 網 (Generalized Stochastic Petri Nets)及彩色派翠網(Colored Petri Nets)等被延伸發展出來。基 本派翠網之數學公式可表示如下【Murata,1989】：

PN = (P, T, F, W, M0)

P = {p1, p2, … , pm}為位置節點的有限集合。 T = {t1, t2, … , tn}為轉移節點的有限集合。

F = (P×T) ∪ (T×P)為具方向性的連接線段，(流動關聯)的有限集合，連接位置結點 與轉移節點。 W : F → {1, 2, … }為加權函數。 M0 : P → {0, 1, 2, … }為初始標記。 其中 P 和 T 互斥，亦即 P∩T=Ø 且 P∪T≠Ø 。 基本派翠網圖以盒形或條形代表轉移節點，圓形代表位置節點，箭號線段代表連接 及流動方向，黑點為表徵(Token)。位置節點內有一到多個表徵。含有表徵的位置節點稱 作具有標記的狀態，可以被轉移節點所激發(Fired)。本文列舉一個簡單的執行，如（圖 2-11）所示，以及一個能同時處理的執行，如（圖 2-12）所示。派翠網的優缺點如（表 2-6）所示： 表 2-6 派翠網優缺點說明整理 優點 缺點 系統結構及動態行為之分析。 對複雜系統不易處理且表達紊亂(基本 派翠網)。 能夠清楚描述所探討的問題中之同時 處理事件及非同步事件。 無組織及資訊觀點(基本派翠網)。 【資料來源：李中奇，2006】 P1 位置 t1 轉移 P2 位置 M0 W 圖 2-11 簡單的派翠網範例 【資料來源：李中奇，2006】

p1 t1 p4 p2 t2 p3 t3 p5 圖 2-12 同時處理的派翠網範例 【資料來源：李中奇，2006】

2.5.4 模式化方法比較分析

經由上述模式化方法之介紹及分析其優缺點後，遂進行上述五個模式化方法之比較 分析，然而在 Giaglis 的研究中曾提及使用功能、行為、組織及資訊四個觀點上所作的 支援能力比較。而（表 2-7）為其所提出上述四個觀點之比較結果。 表 2-7 模式化方法在四個觀點上的支援能力比較 觀點 模型 功能 行為 組織 資訊 Flowchart _{○ × × △} Data Flow Diagram ○ × △ ○ IDEF0 _{○ × △ ×} IDEF3 _{△ △ × △} Petri Nets _{○ ○ × ×} 註： ○表示能夠支援； △表示部份支援；×表示無法支援 【資料來源：Giaglis,2001】  Flowchart Flowchart 以協助分析者繪出關鍵流程步驟為主要目的。Flowchart 可描述整個系統 的概略，使人易於瞭解，然而因設施簡單且描述因人而異，現今僅具參考價值。以輔助 電腦程式撰寫的程式流程圖為例，它有起點及終點，中間經過資料的輸入、處理及輸出， 循序執行，並可能有重覆計算的環圈及簡單決策的分歧路徑選擇。總結以上敘述，得到 如下之結論【李中奇，2006】： (1) Flowchart 呈現整體的活動及描述實體(如產品或服務)的流動與活動的關係，故 支援功能觀點。

(3) Flowchart 無法呈現活動是被那位動作者在何處所執行；無資源的溝通機制亦 無實體的儲存，故不能支援組織觀點。 (4) Flowchart 的起始端可能是原料或服務需求(資訊實體)，終端可能是此一個產品 及或服務的產出或儲存，是有資訊實體產出，但是無法詳述其實體結構及實體 之間的關係，故只有部份支援資訊觀點。  DFD DFD 以描述資訊或資料在某個活動中流動的情形為主要目的。DFD 可清楚描述一 個從源頭(Source)到終點(Sink)的資訊流，其中有資訊的處理及資料的儲存位置，資料字 典是用來定義以上這些資料。DFD 無決策邏輯與時間順序的表達。另外，在結構化系 統設計時需將 DFD 轉成結構圖，以利程式編寫與測詴。總結以上敘述，得到如下之結 論【李中奇，2006】： (1) DFD 最主要的目的是在分析資料的處理轉換，及資料的流動，故支援功能觀 點。 (2) DFD 無嚴謹的進行順序，為靜態的環境，無法表示何時及如何作這些活動， 故不能支援行為觀點。 (3) DFD 無法表示處理在何處被執行，但是可以有外部實體的執行起動以及資料 流入資料儲存單元，故部份支援組織觀點。 (4) DFD 主要以資訊或資料傳遞至各處理單元及或儲存至資料儲存單元，故支援 資訊觀點。  IDEF0 IDEF0 以展示功能為主要目的。從對企業專門負責人所作的訪談中擷取企業智慧， 整理出企業經營的規則，描述成企業的活動及流程。ICOM 圖可以向下分解，以得到具 有詳細活動情形的低層次摘要圖。各個 ICOM 圖可以將資訊相連。IDEF0 只有活動及 流動兩種圖形符號，表達有限，尤其是無法對時間順序及邏輯作充分的表達。總結以上 敘述，得到如下之結論【李中奇，2006】： (1) IDEF0 以 ICOM 圖形表示其所執行的活動功能及對外之連結，並可將活動向 下分解，故支援功能觀點。

(2) IDEF0 為靜態的圖，無時間的表達以指定流程的順序，故不能支援行為觀點。 (3) IDEF0 可表示執行的動作者，但無法表示在何處被執行，有資源溝通機制，但 無資訊的儲存，故只部份支援組織觀點。 (4) IDEF0 流程中無法產出或安置資訊實體，且無法詳述資訊實體的結構及實體之 間的關係，故不能支援資訊觀點。  IDEF3

IDEF3 以擷取流程描述為主要目的。IDEF3 是針對 IDEF0 的不足而發展的。IDEF3 以描述組織是如何的工作，有活動的優先次序及因果關係。IDEF3 以 AND、OR 及 Exclusive OR 等邏輯決策來合併及或分歧流動的方向。總結以上敘述，得到如下之結論 【李中奇，2006】： (1) IDEF3 無法展示什麼活動被執行，但是可以展示邏輯決策的流動與活動的關 係，故部份支援功能觀點。 (2) IDEF3 為情境驅動塑模，對情勢及事件之間的優先次序及因果關係作直接擷 取，但是無時間的表示，故部份支援行為觀點。 (3) IDEF3 無法表示被那位動作者在何處執行，故不能支援組織觀點。 (4) IDEF3 的流程有資訊資料的產出，但是無法詳述其資訊資料的結構及資料之間 的關係，故部份支援資訊觀點。  Petri Nets

Petri Nets 是以系統結構及動態行為之分析為主要目的。Petri Nets 可以展現同步、 非同步、平行及同時處理等流程。Petri Nets 有位置節點及轉移結點兩個部份。位置節 點與條件或狀態同義，轉移結點與事件或處理同義。總結以上敘述，得到如下之結論【李 中奇，2006】： (1) Petri Nets 以轉移符號展示執行的活動為何，及展示狀態符號與轉移符號的轉 換關係，故支援功能觀點。 (2) Petri Nets 主要在反應系統狀態的改變，呈現何時及如何作這些活動，故支援