專案生產管理（PROJECT PRODUCTION MANAGEMENT）
將作業科學應用於資本專案的交付，是透過一套特定的方法論與支援技術來完成，這套總體方法稱為 專案生產管理（Project Production Management, PPM）。
這些方法論包括：
生產系統建模與最佳化（Production System Modeling and Optimization, PSMO）
專案生產控制（Project Production Control, PPC），其中包含
電腦輔助生產工程（Computer-Aided Production Engineering, CAPE）
供應流程控制（Supply Flow Control, SFC）
需要特別指出的是，PPM 並不是要取代業界團體或顧問所提出的各種協作工作方式；它的目的在於提供一個底層的技術性思考框架，用來思考如何依照專案的目的與目標，交付一個資本專案。
這些 PPM 方法的應用，直接補上了本書前面所指出的關鍵缺口。
實務證明，這些方法已為業主與承攬商在各類複雜且關鍵的資本專案中，創造了數十億美元的價值——從土木基礎建設到大型工業專案皆是如此。
涵蓋陸上與離岸的大型上游能源專案，以及商業建築等。
雖然 PPM（專案生產管理） 支持、甚至納入持續改善的元素，例如 Shewhart 的「計畫－執行－研究－行動（Plan-Do-Study-Act, PDSA）」方法論（通常將功勞歸於 Deming，因為他讓這套方法廣為人知，即所謂的 Deming Cycle），但 PPM 的核心是建立在「定義、設計與控制」的邏輯之上。
首先明確界定商業目標；接著設計或最佳化生產系統；最後對生產系統進行控制。
持續改善只是「控制」的一個子集合。
換一個角度來看，「定義－設計／最佳化」是策略性、總體性的層次，而持續改善則是漸進式或戰術性的行動。
PPM 架構提供了一套方法，能夠在專案生產系統中辨識並移除不必要資源的使用——無論是在專案定義的早期階段，或當專案開始偏離正軌，甚至如 SPS 的 Roberto Arbulu 所說，變成「一個他媽的大問題」的時候。
從部署角度來看，PSO（生產系統最佳化） 可以先於 PPC（專案生產控制） 或 SFC（供應流程控制）；也可能是 PPC 先於 PSO。
在部署 PPC 時，也應同時建立並運用標準作業（Standard Work），並在適當時機結合 CAPE（電腦輔助生產工程）。
在某個近期的客戶案例中，我們是先從 SFC 著手，再推進至 PPC，最後才評估導入 PSO。
換言之，PPM 及其三個方法，既能支援新生產系統的設計，也能用於既有生產系統的改善。
這有點像是「預防醫學或洗牙」與「急診或根管治療」的差別——只是，有些人就是偏好那種刺激、危險與痛苦！
建築產業向來以其對環境、健康與安全（EHS）的承諾自豪；但在一個重行政、輕生產的產業中，我們必須質疑：我們到底有多認真？
某家世界級的製造公司邀請我們參加他們的年度安全會議。他們會圍著桌子逐一詢問各位專家有何建議，而我們的回答始終如一：
消除任何不必要的工作，以及其所伴隨的不必要資源使用。
有一年，其中一位高階主管說：
「你們為什麼不直接來我的工廠，親自示範給我和我的團隊看，你們到底在說什麼？」
我們當然欣然接受這個邀請；而當我們離開後，他們立刻著手行動——隔年，他們自豪地展示了自己的成果。
接下來的章節，將說明一套實務且技術性的做法，專注於完成這件事：
辨識並消除不必要的工作與資源使用，且完全對齊專案與企業的目標。
如同下方圖示所示，若要確保一個生產系統能如預期般運作（符合目標），必須具備兩個關鍵要素：
理解並影響生產系統的行為方式
對生產系統進行有效控制
（圖示標題）
生產系統最佳化（PSO）與專案生產控制（PPC）之間的關係
生產系統建模與最佳化
Production System Modeling and Optimization
當我們在診斷問題或試圖讓某件事情變得更好時，似乎有兩種選擇：
（1）直接動手「修修補補」；
（2）遵循一套架構。
最佳化一個生產系統，理應與看醫生沒有什麼不同。你會期待醫師透過提問與各種檢查來診斷問題，而不是隨意嘗試。要做到這一點，醫師必須具備一個底層的思考架構，並且知道自己在找什麼。在 SPS，我們一向努力去「找問題」，而不是只「看表象」（例如：WIP 是在哪裡累積？產能是在哪裡流失？哪裡存在過剩產能？等等），因為單純「看」會變得複雜且令人不知所措。
PSO（生產系統最佳化）研究亦然——你必須從一個架構開始，而作業科學正提供了這樣一個必要的架構。
話雖如此，許多建築專業人員仍然傾向於直接動手嘗試。
簡單來說，投入的項目會流經生產系統，最後成為成品。項目能通過系統的速度，取決於瓶頸所允許的最大速率。已進入生產系統、但尚未成為成品的項目，即為 WIP（在製品）。如果我們希望在降低成本與現金占用的同時，讓更多產出通過系統，就必須在抑制有害變異的前提下，最佳化產能與 WIP。
其中一個關鍵要素是：流量必須穿越瓶頸。在高績效的生產系統中，瓶頸是被刻意設定為一個「控制點」，其角色就像調速器或調節器。這與某些精實顧問試圖「平衡」所有作業或製程中心的作法形成對比。
PSO （生產系統最佳化）是一種對生產系統進行製圖、建模、分析與模擬的實務，以達成最理想的績效表現。
PSO 研究可用於改善各種類型的生產系統與供應鏈。PSO 的關鍵關注面向包括：吞吐量、週期時間，以及資源使用（產能與庫存），同時也涵蓋變異的來源與影響。
就像工程師利用模型來理解機械或結構系統的預期行為一樣，PSO 模型也可用來理解生產系統的行為。不同於以「完成日期」為核心的專案管理，生產模型聚焦於真正驅動進度的關鍵生產績效指標，包括吞吐量、週期時間與產能利用率等。
如同前一章所述，除了產品與製程設計之外，能用來改善生產系統績效的主要槓桿只剩下三項：
-
調節產能利用率
-
控制 WIP
-
管理變異
一項 PSO 研究，始於對「哪些生產系統能從 PSO 行動中獲益」的辨識與定義。研究對象的生產系統，可能是設計階段中的技術工作、工廠內進行的製造與組裝作業、工地現場的施工活動、供應流程，或上述任意組合。
在建築領域中，對生產系統的辨識與定義，通常是透過建立一份**生產系統圖（Production System Map）**來完成。
生產系統的製圖與建模，是基於一組特定的符號，使讀者能快速理解流程中每一個步驟或作業的實際狀況：
-
圓桶 用來表示庫存
-
三角形 用來表示等待佇列
-
長方形 代表作業／製程中心
-
箭頭 則用來表示流向或路徑
（上方圖示說明）
Unlock Value → Capture Value
Define → Map / Model → Simulate / Analyze → Configure → Control → Improve
（回饋 Feedback）
Production System Optimization → Project Production Control
我記得曾在史丹佛大學，和 SPS 的 James Choo 一起教授一門關於如何進行 PSO（生產系統最佳化） 的課程。有幾位學生嘗試使用 PSO 軟體來製作長條圖。最精彩的一幕是，當學生按下「organize process（整理流程）」的按鈕時，長條圖會重新排列成一張製程流程圖——而那位學生會立刻從螢幕前跳開，接著說：「一定是排程軟體出問題了。」
我們看得目瞪口呆，而我必須承認，這一幕其實還挺有娛樂性。這種思維方式扎根之深，令人震驚；而它所造成的價值破壞，也同樣令人震驚。
（右頁圖示）
Project Production System Process Flow Diagram
（專案生產系統流程圖）
在生產系統被識別並清楚定義之後，下一個步驟就是將這張「地圖」（本身是沒有智慧的）轉換為一個具備智慧的模型。
這是透過加入生產系統的績效數據來完成的，例如：期望的、預測的或實際的吞吐量（throughput）、循環時間（cycle time）、產能利用率（capacity utilization），以及變異性因子（variability factor）等其他以生產為基礎的參數。也可以納入成本，以支援財務分析。
當地圖轉換為模型之後，便會使用各種建模方法，其中最常見的是分析法（analytics）與離散事件模擬（discrete event simulation），而且這兩種方法往往會同時搭配使用。當生產系統在組裝線等情境下使用生產控制應用系統時，控制系統所蒐集的資料可以直接輸入至 PSO（Production System Optimization，生產系統最佳化） 應用程式中。
正如本書後續所述，透過將生產控制系統與連接至 PSO 模型的 IoT 感測器進行整合，這些資料的蒐集如今已可自動化完成，從而建立一個生產系統的數位分身（digital twin）。這為接下來的發展奠定了基礎——也就是自我成形、自我最佳化的生產系統
（左頁）
接著，模型會被驗證（validated），以確保該模型的行為確實反映實際生產系統正在或將會發生的狀況。經過驗證的模型，便可依據既定目標，用來分析、模擬與最佳化各種生產參數，包括 在製品數量（WIP） 與 產能使用情況（capacity utilization）。
（圖示說明）
分析模型輸出結果
Output from Analytical Model
（右頁）
（圖示說明）
離散事件模擬模型
Discrete Event Simulation Model
以下為幾個示例，說明 PSO（Production System Optimization，生產系統最佳化） 如何用來最佳化一個生產系統。第一個案例發生於設計階段，我們與 McKinsey 合作完成。第二個案例是在一家製造工廠中進行，在該案例中可以看到，吞吐量得以提升的同時，循環時間卻下降。在財務面上，這等同於提升客戶服務水準，同時在較低的現金消耗下帶來更多現金流入。
第三個案例是在施工現場進行電纜安裝的專案，透過降低產能配置與在製品數量（WIP），成功壓縮了工期。第四個案例則是另一個與 McKinsey 合作的專案，展示了對兩個不同土木基礎建設專案進行最佳化的潛在效果。
（左頁）
PSO 應用於工程設計工作（PSO for Engineering Work）
本專案支援了一項任務關鍵（mission-critical）通訊網路的設計與部署（如國防用途）。在此案例中，確保設計能如期且完整交付是不可妥協的要求。透過 PSO 分析，並搭配其他各項補救措施，最終確保了這一目標得以實現。
PSO 用於最佳化製造工廠（PSO to Optimize a Fabrication Shop）
在此案例中可以看到，透過最佳化產能配置並控制在製品數量（WIP），不僅能提升吞吐量，同時還能降低循環時間。
做更多事、更快完成、而且成本更低！
PSO 用於最佳化施工現場作業（PSO to Optimize Construction Site Operations）
在接下來的案例中，我們可以看到，透過使用較少的產能與較低的 WIP，工作反而能更早完成。這代表必須重新思考產能策略，其中包含減少不必要的人力配置。
（右頁）
透過 PPM 演練進一步識別改善槓桿
可比較的循環時間（已正規化），單位：分鐘
（圖表說明重點翻譯）
-
改善來自於目前流程的解耦（decouple from current process）
-
改善：標準化作業（standardize work）
-
改善：增加第二台起重機（add 2nd crane）
-
改善：減少 WIP
-
改善：增加產能
-
改善：重新排序作業順序
-
改善：消除等待與不必要移動
-
改善：工作區域重新配置
（圖中範例標註）
-
每日 2 根樁（2 piles/day）
-
每日 3 根樁（3 piles/day）
-
每日 4 根樁（4 piles/day）
-
每日 5–6 根樁（5–6 piles/day）
（關鍵時間指標）
-
實際循環時間（Real cycle time）
-
班次時間（Shift time）
-
總時間（Total time）
-
非增值時間（Non-value-adding time, prorated）
-
午休（Lunch break, prorated）
（限制與瓶頸說明）
-
焊工是關鍵驅動資源（Welders as key driver）
-
起重機為瓶頸（Bottleneck = crane）
-
因高壓線存在導致作業空間受限（Low feasibility – constrained space due to the presence of high-voltage lines）
-
焊工接近滿載使用（Welders are close to fully utilized）
-
瓶頸接近完全利用（Bottleneck nearly fully utilized）
（資料來源）
資料來源：McKinsey & Company
（左頁）
機會彙總（Summary of Opportunities）
| 工作流程（Workflow） | 改善機會（Opportunities） | 影響（Impact） |
|---|---|---|
| 預鑄樁施工（Precast Piling） | 增加一部起重機 | 11.5 天 |
| 延長工作日曆 | ||
| 鋼板樁施工（Steel Sheet Piling） | 增加一部振動式挖掘機（vibro-excavator） | 10 天 |
| 延長工作日曆 | ||
| 承台施工（Pile Cap Construction） | 降低挖掘與樁頭切除之間的交接批量 | 22 天 |
| 延長工作日曆 | ||
| 鋼筋班組增加 2 人 | ||
| 降低鋼筋與模板之間的交接批量 | ||
| 柱體施工（Column Construction） | 降低支撐與鋼筋之間的交接批量 | 8 天 |
| 模板工人數由 8 人增加至 16 人 | ||
| 橋墩頭施工（Pier Head Construction） | 降低鋼筋與模板之間的交接批量 | 13 天 |
| 鋼筋班組增加 2 人 | ||
| 延長工作日曆 |
資料來源：McKinsey & Company
由於生產系統模型終究只是模型，因此必須確保生產系統的行為能依據其目標被有效控制。這正是**生產控制（Production Control）與供應流控制（Supply Flow Control）**存在的目的。
（右頁）
（圖示標題）
解鎖價值（Unlock Value） → 擷取價值（Capture Value）
Define → Map / Model → Simulate / Analyze → Configure → Control → Improve
（下方）Production System Optimization → Project Production Control
（回饋）Feedback
生產控制（Production Control）
有效的生產控制，是任何高效率且具可靠性的生產系統之關鍵要素。從技術上來說，生產控制是指任何行動、流程、機制、系統或其組合，用以組織並使生產（或工作執行）得以被控制。
生產控制透過實體手段、軟體，以及人類決策，來管理「受控中的生產路徑／作業順序」、產能使用，以及包含在製品（WIP）在內的庫存數量。
所謂的實體（physical），是指實際控制事情如何發生的裝置，例如：
就像機場行李掃描機入口的開口尺寸，或施工現場起重機的數量。
**控制（Control）**意味著對產能的實際配置、對 WIP 最小與最大水位的管理，以及對變異性的管理。
理解各種控制機制與排程方式非常重要，包括：
-
推式（push）
-
拉式（pull）
-
恆定在製品（CONWIP, constant work in process）
以及這些方式各自的運作原理。
推式系統會依據預先決定的排程日期，將工作釋放進生產系統中。
雖然在營建業中最為常見，但推式（或僅依既定排程作業），由於無法有效應對變異性，並不是一種有效的控制手段。
由 Toyota 所發展的 拉式（pull）控制機制則是——
（左頁）
這是根據下游作業發出通知——或者以 Toyota 為例，透過 看板（kanban）卡——要求上游作業進行生產。
CONWIP 控制機制則是向生產流程的起點，或接近起點的位置，發送一個訊號；藉此，它控制了在「發送訊號的作業」與「接收訊號並執行的作業」之間的在製品（WIP）。
精實專家經常爭論推式（push）與拉式（pull）的差異，但正如 Mark Spearman 所說：
「推式、拉式，有什麼差別？重點是控制 WIP。」
（圖示說明）
-
推式／排程控制機制（Push / Schedule Control Protocol）
-
拉式控制機制（Pull Control Protocol）
-
CONWIP 訊號
-
CONWIP 控制機制（CONWIP Control Protocol）
（右頁）
從設計的角度來看，策略應該是在可行時優先使用拉式（pull）或 CONWIP 控制機制。
推式系統（包含排程的使用）應該只作為最後手段。
專案生產控制（Project Production Control）
生產控制軟體已在製造業中使用了數十年，而營建業則過度依賴人為決策作為控制手段。
專案生產控制（PPC）的出現，為營建專案提供了生產控制系統中軟體層面的關鍵要素。
PPC 可有效控制技術性工作（設計與工程）與實體施工工作，無論是在製造工廠中，或是在施工現場。
一個有效的 PPC 系統必須確保：
-
工作順序被遵循
-
資源（包含產能）被有效配置，且 WIP 維持在最小與最大允許範圍內
-
變異性及其來源受到管理
雖然「專案控制（project controls）」與「專案生產控制（PPC）」在某些商業流程與資料呈現方式上可能相似（例如使用網路圖或橫條圖），但 PPC 並不是 Era 2 意義下的「排程（scheduling）」。
它是完全不同的東西——而且更好。
由於生產控制的目標是管理工作順序、資源使用與變異性（包含其來源），因此 CPM 排程並不適合作為生產控制的基礎。
此外，且這一點非常重要必須理解：
生產控制並不等同於把橫條圖或 CPM 排程做得更細（例如從週計畫細化到日計畫）。
我們所談的不是預測與報告意義下的「控制」。
我們也不是在談排程，即便你要求現場人員做—
（左頁）
……協作式拉式計畫（collaborative pull plan）。
Peter Drucker 如下描述「controls（控制）」與「control（控制）」之間的差異：
「controls 這個詞並不是 control 的複數形式……這兩個詞的意義完全不同。
controls 的同義詞是『量測（measurements）』與『資訊（information）』；
control 的同義詞是『方向（direction）』。
controls 處理的是過去已發生的事實；
control 處理的是期待，也就是未來。」¹⁴
由於生產速率會驅動排程日期，典型的專案控制報告（例如成本與進度績效，以及現金流分析）往往成為一種自動化輸出結果。
正如你將在第 10 章讀到的，現代科技的應用使這一切得以整合並自動化，能即時進行排程與成本預測／報告，並結合 AI 與 ML（機器學習），例如 Chevron 等公司即已採用。
最後責任時點排程（Last Responsible Moment Scheduling）
在 SPS，我們相信、並已發展與實際應用一個稱為**最後責任時點（LRM）**的概念，作為建立排程的方法。
LRM 排程法能在確保產能被有效投入的同時，達成對 WIP（在製品） 的管理。
簡單來說，LRM 排程是先識別 LRM 的完成日期（不要與「最後可能時點 last possible moment」混淆），再從該日期回推整個端到端流程的週期時間（cycle time），以計算流程的開始日期。
開始日期 = 最後責任時點完成日期 − 端到端流程週期時間
¹⁴ Peter Drucker，《Management: Tasks, Responsibilities, Practices》，New York: Harper & Row，1974
（右頁）
由於目標是控制 WIP，而 WIP 與時間呈反向關係，因此我們的原則是：
一路工作到最後責任時點為止。
我們只在「真的需要做」時才做事。
本質上，我們是在現場執行工作時，採取一種即時生產（just-in-time）的方式——依序、按需地完成工作，以最大化工作流的吞吐量（throughput）；而不是單純為了燒工時、製造「燒工取酬（burn and earn）」而做事。
以軟體為基礎的 PPC（專案生產控制）解決方案，正是透過三個主要的商業流程來實現這一點：
-
生產排程（production scheduling）
-
生產計畫（production planning）
-
持續改善（continuous improvement）
生產排程是透過標準作業（standard work）流程建立的，並盡可能超越單一生產計畫週期來思考；該週期可能依被控制的工作類型不同，而以班次、天或週為單位。
因為目標是控制 WIP，而 WIP 與時間呈反向關係，因此我們的目標是一路工作到最後責任時點。
生產排程提供了「何時、由誰完成哪些工作」的預測。
生產排程日期是依據 LRM 日期計算得出。
生產計畫則聚焦於特定期間內工作的配置，並作為資源承諾的基礎。
這些計畫是用來以安全且高效率的方式「釋放工作量（liquidating work）」；而生產排程則確保工作順序與相關 WIP被有效管理。
範例（Example）
2008 年，我們受邀參與美國中西部一個煉油廠專案。
業主表示，他們的問題是：工作量超過了可用的時間與金錢。
第一次會議非常耐人尋味，因為它呈現出——
（左頁）
當利害關係極高時，衝突是可能發生的——就像一位身材魁梧的德州人，與一位身形瘦削的中西部人之間，幾乎因為「該如何解決問題」而爆發肢體衝突。
最終，業主決定以最簡單的形式來導入生產控制（production control）。
首先，觀察對頁的進度曲線（progress curve），我們可以看到：
該專案原本的計畫是使用更多人力，並且需要更長的工期才能完成。
然而，透過 PPC（Project Production Control） 來控制產能與人力的使用，這個原本充滿挑戰的專案，最終在預算內、且提前於排程完成。
能夠有效管理 WIP（在製品），其成果令人驚艷。
以至於業主將此專案與其在其他煉油廠的專案進行基準比較（benchmarking），並開始真正理解 PPC 的強大威力。
指標比較表（W/PPC 專案 vs 其他專案）
指標 | 本專案（W/PPC） | 專案 2 | 專案 3 | 專案 4
管線（Piping）
-
2.5 工時／英呎（約 4 吋平均管徑）
-
4.0 工時／英呎（約 4 吋平均管徑）
-
2.9 工時／英呎（約 6 吋平均管徑）
-
3.01 工時／英呎（？平均管徑）
鋼構（Steel）
-
20.9 工時／噸
-
30 工時／噸
-
26.7 工時／噸
-
46.5 工時／噸
混凝土（Concrete）
-
9.2 工時／立方碼
-
11 工時／立方碼
-
10.5 工時／立方碼
-
24.8 工時／立方碼
保溫（Insulation）
-
0.44 工時／平方英呎
-
—
-
0.31 工時／平方英呎
-
—
-
0.24 工時／英呎
-
—
-
0.45 工時／英呎
問題專案與業主其他煉油廠專案之基準比較
（右頁）
圖表說明（Troubled Refinery Project Outcome）
-
縱軸（左）：人力投入（FTE）
-
縱軸（右）：完成百分比
-
橫軸：時間（日期）
圖中顯示：
-
實際人力（Actual Manpower）
-
EAF 目標人力（EAF Target Manpower）
-
實際完成率（Actual % Complete）
重要里程碑標示包括：
-
DB Tower 交付（Delivery of DB Tower）
-
D9 現場作業（D9 on-site）
-
D7 現場作業（D7 on-site）
-
五月中：所有 DB Tower 準時交付
圖表最終顯示結果為：
「原本問題重重的煉油廠專案，最終成果」
（左頁）Example（案例）
在澳洲一項大型、重型土木工程專案中，也取得了類似的成果。
由於各種問題，該專案面臨無法達成重要里程碑日期的風險，包括啟用（start-up）與交付（handover）。
專案控制團隊回報，所有短期與長期的里程碑皆處於風險之中。
在一次與專案經理的電話交談中，我發現他的描述更為直接：
「我們已經落後，而且落後得越來越嚴重；成本狀況持續惡化，專案超出預算；而隨著壓力全面湧現，關鍵性正在不斷提高。」
這已經演變成一場真正的災難現場，但他仍然下定決心要解決問題——而且他做到了。
PPC（Project Production Control，專案生產控制） 的導入，使專案團隊得以爭取時間，並最終在符合進度目標與成本目標的情況下完成交付。
這是如何做到的？
如前所述，PPC 的實施使得：
-
WIP（在製品）得以有效控制（包含作業順序）
-
產能得以有效使用
-
變異性得以降低
再加上 標準作業（standard work）、LRM 排程（Last Responsible Moment Scheduling） 與持續改善，共同用來最佳化生產。
就這麼簡單！
里程碑達成情況（節錄）
| 里程碑事件 | 計畫日期 | 實際日期 | 差異 |
|---|---|---|---|
| SP-1 實質完成 | 2012/08/03 | 2012/07/19 | -15 天 |
| SP-1 專案交付 | 2012/09/12 | 2012/08/28 | -15 天 |
| SP-2 實質完成 | 2012/11/12 | 2012/10/25 | -18 天 |
| SP-2 專案交付 | 2012/12/22 | 2012/12/04 | -18 天 |
（資料來源：Strategic Project Solutions）
（右頁）STANDARD WORK（標準作業）
專案生產控制的一個關鍵要素，是標準作業的使用。
標準作業的概念並非什麼突破性的創新；它在汽車產業中早已被充分理解並成功應用。
我們看到運動學家（kinesiologists） 參與其中，確保勞工執行的實體動作不會對人體造成風險——這一點對 Taylor 與 Gilbreth（各自以其方式）而言當然極具吸引力；
而 Hauer 則花費大量心力，說明使用手鏟時的正確技術，包括雙腳的正確站位，以及如何握持鏟子。
令人意外的是，許多專案專業人員並未意識到：
即使產品（最終成果）可能是客製化的，流程本身卻大多是重複性的——
無論是在設計與工程這類偏技術性的工作中，或是在現場實體作業（例如各類工種）中，皆是如此。
仔細想想：
如果我們無法在這些工作流程中進行標準化、文件化、教育與訓練，那我們根本不可能取得建築或工程學位。
同樣地，對於工種作業而言，如果我們無法標準化、文件化、教育或訓練人員，就不可能存在所謂的工種（如焊工、配管工等）。
如果我們在層級架構中再往下深入幾層，基本上可以辨識出幾乎無限多的標準作業，而這些作業都可以被：
-
辨識
-
繪製
-
最佳化
-
控制
-
改善
如前所述，標準作業在建築產業中曾經相當普遍，其歷史可以追溯至 Hauer 與 Taylor 的年代。
過去，一般承包商往往擁有大量的標準作業文件庫，用來規範現場工作應如何執行。
然而，第二代（Era 2） 對專案管理與施工管理的高度聚焦，反而削弱了這種以標準作業為核心的典範。
多年前，我曾在一家施工管理公司詢問一位現場工程師，關於他辦公室書架上一排佈滿灰塵的活頁夾。
「那是什麼？」我問。
他回答：「那是標準作業。」
「你們有在用嗎？」我再問。
「我們已經好多年沒用了。」
（左頁）
「我沒有參與實際施工。那是分包商的問題！」他說。
「但我仍然保留一個遙遠的可能性：未來我們也許會再次選擇自行施工。」
雖然標準作業（standard work）並不是什麼全新的概念，但數位科技為我們提供了新的途徑，讓標準作業得以回歸到實務操作的範疇之中，並藉此解鎖並擷取龐大的價值。
下方所示的圖表，來自與前述澳洲土木專案相關的標準流程資料庫（standard process library）。
這些流程包含了高度細緻的生產資訊，並能夠支援快速制定生產排程。
此外，標準化流程同時也是持續改善的基礎。
（右頁）
大型基礎建設專案的標準流程（工作）資料庫
Standard Process (Work) Library for Large Infrastructure Project
（圖中為該專案之標準作業流程清單與階層化工作結構，展示各項作業、工序、工種與其對應的標準化定義、順序與關聯。）
© Strategic Project Solutions, Inc.
沒有留言:
張貼留言