ERP 支撐 TOC 的實現歷程 　

DR ALAN BARNARD, DR KATJA RAJANIEMI
AND FREDRIK NORDSTROM ， 2009 版權所有
本文經 DR ALAN BARNARD 授權翻譯與刊登

一套有力的 TOC 方案能實現又快速又可靠的達交表現，使用標準的 ERP 系統，即可簡易明瞭地操作。
Achieving Fast And Reliable Deliveries With A Robust TOC Solution
Simple Enough To Be Supported By Standard ERP Systems

摘要

於當今的商業競爭環境中，長前置時間、低準時達交率（ long lead times, poor due date performance ）及無力適應顧客需求的變化等，皆是市場無法接受的現象。因而許多公司認真地投入改善，採用依系統限制與需求導向的規劃及執行方式，例如，鼓 - 緩衝 - 繩（ Drum-Buffer-Rope (DBR) ），動態緩衝管理與補貨（ Dynamic Buffer

Management (DBM) and Replenishment (TOCR) 等，那些由 TOC 限制管理及精實（ Lean ）管理所提出的方案。目的是為了提供更快與更可靠的達交表現，和以最少成本與投資而獲得更高的有效產出（ throughput ）。然而，已知於標準 ERP 系統，能支撐複雜且混合的生產環境中所需的功能有限（例如， MTS [make-to-stock] ， MTO [make-to-order] ， ATO [ assembly-to-order] 及 ETO [engineering-to-order] ）。不少公司認為修改現有 ERP 系統需要高成本，而選擇高價的 先進規劃與排程（ Advanced Planning & Scheduling ， APS ）軟體，這需要訓練有素的人力資源。或選擇自行開發複雜的試算表和資料庫軟體系統，為了提供超出標準 ERP 系統之外的功能及資料。事實上，大型組織抱怨這樣的作法，不僅令 IT 工作更昂貴、複雜、業務風險更高，還會傷及推動像 TOC 這樣優良解決方案的時效性（及將既有成效迅速多元展開的時效性）。

本文陳述一個案例研究，全球最大的 power and automation technology 供應商， ABB 與 Goldratt Research Labs 及 SAP 合作，確實地克服如此的挑戰。十五年來經歷過許多導入 TOC 的成功經驗（範例見附錄）， ABB 確認 TOC 為關鍵之競爭策略的實踐平台，並且於首次展示的最佳改善範例中，視為卓越營運的 最佳典範（ Operational Excellence “best-practice” ） ，應用了他們選擇的 ERP 平台（ SAP ），這是全球『 One-simple-ABB 』計畫的一部份。過去 ABB 要大量導入 TCO ，遭遇到一個主要的障礙，就是商用 ERP 系統缺乏 TOC 所需的功能。以致於許多自行開發及引進其他 IT 系統，造成系統整合、數據交換、集中 IT 支援及維護等，又昂貴又是種主要的業務風險。此外，在實施 TOC 的作業現場，常常 ERP 系統無法提供所需資料。近年來，於營運及物流管理領域，高德拉特集團（ Goldratt Group ）新開發及簡化的 TOC 規劃與執行規則，如 S-DBR 及 TOCR and DBM ，在 ABB 公司內商用 ERP 系統如 SAP 便可支撐 TOC 的導入工作，這是由於這些手法潛在的共通適用性，能涵蓋他們全球 300 個以上的工廠據點的所有差異與複雜度。

這個假設值得測試，所以 ABB 集合了一組專家，來自 ABB ， Goldratt Research Labs 及 SAP 。為了達成對議題的共識與注意力，和加速定義及溝通重要的 ERP 調整焦點，高德拉特博士建議該團隊使用 TOC 的策略與戰術樹（ Strategy &Tactic Tree ），這是高博士開發的新策略工具，用以指出、定義及溝通，所有程序上、政策上及衡量上必要且充足的改變方案，以能達到組織成長與穩健的標的。藉由這個工具及相關的協同開發與測試程序，該團隊定義、溝通及研擬 IT 藍圖，試圖回答 ERP 系統（ SAP ）需要調整之功能是什麼（ What ），如何做（ How to ）及為什麼要這樣做（ Why ）。這個方式在於獲得重要利害關係人的必要認同與接納上，扮演了主要的角色，對位於捷克及韓國的工廠試點，能成功實施與獲得快速營業成效，有必然的影響。基於所有利害關係人的高滿意度，『 TOC in SAP 』計畫現在正按部就班導入至 ABB 全球超過 300 個工廠據點。

關鍵字： 限制 / 制約 / 約束理論（ Theory of Constraints ， TOC ）， 簡化鼓 - 緩衝 - 繩（ Simplified Drum-Buffer-Rope ， S-DBR ） , TOC 緩衝管理（ TOC's Buffer Management ， BM ）， 企業資源規劃（ Enterprise Resource Planning ， ERP ） and SAP 。

介紹

ABB ，全球最大的 power and automation technology 供應商，就像許多其他的國際製造商，處於來自所有利害關係人不斷增加的壓力下，尤其在過去十年，要求落實營運上的卓越表現，來實現且維持企業的競爭優勢。顧客則期待更好的可靠性、可得性、更短的前置時間及具有競爭力的價格（ reliability, availability, shorter lead times and competitive prices ）。股東期待獲利成長與企業穩健，供應伙伴期待更好的能見度（ visibility ）及更好的價格。這時，競爭對手也啟動他們的營運改善計畫，這表示即使 ABB 進步了，如果速度比競爭對手慢的話，還是落後。

ABB 的營運卓越計畫（ Operation Excellence Program ），綜合 TOC 與 Lean 的最佳方案，還有其他的改善方法，已在國際上被視為最成功的案例之一，不僅擁有傑出與一致性的結果（見列於附錄之 ABB 工廠 TOC 及 Lean 的實施範例），還有因為該計畫的目標與方法深化組織的文化及 DNA 。

儘管獲得如此的成效，將這套 TOC 及 Lean 作法標準化，及導入他們 300 多處的工廠據點的工作卻慢下來，有時就是被一個關鍵的衝突所阻礙（見下面圖一： ABB 善用最佳手法之戰術衝突， Figure 1 ）。為了確保 ABB 中所有事業單位都善用這套最佳手法， ABB 營運卓越計畫（ ABB's Operational Excellence Program ， OEP ）的負責小組必須有一套具效率及效能的推展方式，這需要一套標準的方式及做法。同時，善用這套最佳手法表示 OEP 負責小組必須有一套使每個單位有傑出成果的方式，這樣一來每個事業單位需要客製的方式（非標準化的方式）。

難怪， ABB OEP 小組感到左右為難，他們知道阻礙化解該衝突的關鍵假設是，每個事業單位或工廠都不同，表示沒有一體適用的解決方案，或至少有一個解決方案可能適用於大多數的情況，或是只需要一些小修改能適應於特定事業單位的特質，且不會影響成效。

這個未解的衝突與讓 ABB 之 IS 經理人感到挫折的衝突雷同（見下面圖二： ABB 整體善用一套共通的 IS 平台之戰術衝突， Figure 2 ）。為了確保 ABB 創造長期的競爭利基，他們必須有具有效率與效能的財務、 HR 及其他業務程序，和相關的控制，這需要在 ABB 導入一套共通的 ERP 平台，並限制 SCM 及 MES 的選擇，每個事業單位使用方式必須緊密整合，以確保財務報表的效率與有效性。另一方面，為了創造及維持長期的競爭利基， ABB 必須藉由營運卓越及效率化，繼續改善客戶服務與銷售，這需要 ABB 容許每個據點開發他們自己的或使用自選的 ERP ，和 / 或其他廠牌的 SCM 及 MES 系統。

由於 ABB 無論如何都不想對營運績效有不良影響，歷年來， 300 多個據點都是選擇自己想要的 ERP 、 SCM 及 MES 系統，要使 IT 集中支援成了一個成本高且十分複雜的挑戰。再次，防止化解這個衝突的主要假設是，每個事業單位或工廠都是特殊的個體，使用一套共通的 ERP 平台，及 / 或限制 SCM 及 MES 的方法及 IT 系統，不是傷及成果就是自主權。

ABB 領悟到他們必須找出化解這兩個衝突的方案。

對於第一個營運卓越方式的衝突，解決方案是 OEP 小組繼續以不斷開發、測試及公佈，許多在 ABB 組織中的 TOC/Lean 成功案例，來獲得大家的認同與支持。該小組持續宣導與驗證藉由一套共通的 ABB 入門模型的實施程序（ a generic ABB Gate model implementation process ），利於所有工廠據點實現卓越的營運表現。 ABB 開發與測試這套程序，用以加速全面導入『 TOC/Lean 』的最佳作法。（見下面圖三： ABB 入門模型的營運卓越之實施程序， Figure 3 ）。

對於第二個 IT 系統標準化的衝突，提出的解決方案是，被稱為『 One-simple-ABB （ OsA ）』的計畫。在 2007 年三月份， ABB 與位於德國的 ERP 供應商 SAP ，簽署一份策略協議書， SAP 藉由其全球運籌網，協助部署共通的 SAP ERP 軟體，以使某些 ABB 最重要的業務程序，能達一致性與簡易化。由於之前各處自行設置系統的結果，曾經有段時間 ABB 的營運系統中，擁有超過 500 套的 ERP 系統，含 70 種不同品牌。這套 OsA 計畫的目標是，每個國家一套 ERP ，最終是每個區域一套 ERP 平台，如此便能促成重要功能資訊上的高度規格化，含人力資源、財務及行政、公司治理，以及營運卓越像是 TOC/Lean 實踐的績效數據。

唯一未解的問題是， SAP 是否具足夠彈性，或是否能簡化 TOC/Lean 手法（不少專家對此持相反的看法），足以使用標準的 SAP 系統（換言之，不需引進其他系統，除非絕對必要的情況）。

為了找到一個答案，在 2007 年初，啟動一項研究合作計畫，由 ABB 企業研發單位（ Corporate Research and Development ）、企業 IT 單位（ Corporate IT ）、中央規劃單位（ Central Planning ）、 Brno Instrument T ran sformer 工廠據點（第一個工廠試點），及 Goldratt Research Labs ，貢獻個別專長與經驗，一起以標準的 ERP 系統為基礎，開發與實施一套簡易又可多次使用（ simple and reusable ）的 TOC 改善方案。

由於 ABB 已有超過 20 項 TOC 成功的實施成果（見附錄），與已做出一套策略上的決策（ a strategic decision ）（這是『 One-simple-ABB （ OsA ）』計畫的一部份），而 SAP 是優先選用的 ERP 系統，給予這個專案團隊的專案範圍（ scope ）是，設計一套以 TOC 為基礎的改善方案，以提供 ABB 之複雜營運環境中所有的需要，但還是以標準的 SAP 系統來實踐之（即是，只有做些小及少的調整）。為了確認這些目標，這個計畫被稱為『 TOC in SAP 』。

本文中作者們將分享『 TOC in SAP 』計畫的特定的研究目標、研究策略、文獻回顧，包含由 Dr. Eli Goldratt, Eli Schragenheim and Dr. Alan Barnard 等所開發的最新 TOC 方法 ， 足以定義一套簡易又有力 TOC 改善方案。本文也將陳述用於定義與測試 『 TOC in SAP 』的藍圖，和初期測試的結果及未來 ABB 整體導入的計畫。

（待續）

附錄： ABB 綜合應用 TOC 與 LEAN 的範例清單
APPENDIX: SAMPLE LIST OF COMBINED TOC AND LEAN APPLICATIONS IN ABB

 

 

拉式排程系統概要 (II) 　

Pull Scheduling Systems Overview
Copyright © David Hallett 2009 版權所有
本文經 www.PullScheduling.com 授權翻譯與刊登

拉式系統的類別（ Types of Pull Systems ）

有許多能用來實踐拉式運作的可能技巧，再次，我們的定義是：
拉式系統 -- 一套排程系統，其中庫存受某種方式所限制。
（ Pull System – A scheduling system where inventory is limited in some way ）
註：庫存含原物料、在製品、成品（ raw materials, WIP, finished goods ）等。

根據我們的定義，任和技巧能 正規地限制庫存，則能造成拉式操作。儘管如此，大多的技巧大致上可歸入下列的主要拉式方法：

• 超級市場補貨 （ Supermarket Replenishment ）
• 設限的先進先出動線（ Capped FIFO Lanes ）
• 鼓 - 緩衝 - 繩（ Drum Buffer Rope ）
• 在製品限制（ WIP Cap ）
  

本章將回顧每個作法及適合的應用。

超級市場補貨 （ Supermarket Replenishment ）

如我們所見，傳統的製造排程系統要求大量的庫存資金。當豐田在第二次世界大戰後重建時，他們現金很少，無法依照傳統的製造方式投入庫存。他們觀察並提出：『什麼產業最善於運用庫存？』答案是，超級市場！

今天，以典型的超級市場來看，他們的庫存轉數每年超過 50 次。使用推式系統（ Push system ）的典型製造商每年的庫存轉數超過 1-10 次。使用拉式系統及其他精實（ Lean ）製造技巧，豐田的製造環境中能達每年 50-100 的庫存轉數。

我們來看超級市場補貨系統的運作。

圖六呈現一個基本的超級市場補貨系統，過程如下：

• 顧客作業程序從超級市場的貨品展示架上取得所要的產品。
• 每個物品號都設定一個數量為再訂購點。只要是庫存量加上已發出之訂貨量，低於設定的數量，則發出一張新的訂單給供應作業程序。一個容器（ container ）、看板卡（ kanban card ），燈誌信號，清空的空間等等，皆能用於代表需要訂購（紙張訂單不必然需要 – 簡單來看，就是『清空了，補足它』）。
• 每個物品號都有一個再訂購數量（ re-order quantity ），新訂單的數量等於某個物品號的再訂購數量。
• 供應作業程序完成該訂單。
• 購得的物品擺上超級市場的展示架。

在此例子中，只有顧客作業程序能設計一套正式的訂購運作方式。供應作業程序受帶動而自動發生，這是拉式系統非常重要的部分。不管一個拉式系統中有多少程序，只有一個排程點（ one scheduling point ）！

單一計畫點（ Single Schedule Point ） – 在拉式系統中，於某個單一程序獨立計畫整個拉式系統，而所有其他的程序由拉式系統自行計畫。（ Single Schedule Point – Single process in a Pull System where the entire Pull System will be independently scheduled. All other processes are scheduled by the Pull System itself. ）

想想相較於分別計畫系統中的每個程序，這是多簡單與有效用。大多數公司試圖不是手動計畫每個程序，就是使用傳統的 MRP/ERP 系統。

下面的變數會影響到，計算系統中每個物品號的再訂購點（ Re-Order Point ）和整體潛在的庫存（ Total Potential Inventory ）：

• 一段時期的平均需求量（ Average Demand per period ）
• 一段時期的需求變化性（ Variability in Demand per period ）
• 從發出一張訂單給供應作業程序，直到完成該訂單，即是貨品補回超級市場的展示架之前置時間（ Lead-time from when an order is released to the Supplying Process until the completed order is received at the Supermarket Shelf ）
• 再訂購數量（ Re-Order Quantity ）
• 服務程度（ Service Level ），是超級市場希望在多少時間比率上，展示架上至少有某些產品，可進行顧客作業程序。註：因刻意設計，絕不是 100% ，由於費用太高或統計上就是不可能。

上述任何一項的增加會使的系統的整體潛在庫存提高。

當使用這套系統時，在超市架上的庫存很少等於整體潛在的庫存，其中包含拿走而不達再訂購數量，等待供應端處理的訂單，供應端處理中的訂單，及供應端送出在運送途中的訂單。在一個設計良好的系統中，超市架上的實際平均庫存經常是整體潛在庫存的 10-50% 。

多重超市能使用拉式系統，如同數個作業程序：

這個例子中的各個超市都是獨立的，如圖六所示的運作方式。單一計畫點（ Single Schedule Point ）在此系統中是在程序四（ Process 4 ）。一個簡單的方式來決定這個位置是：

單一計畫點的位置就在整個拉式系統中，緊接在最後一家超市之後的程序。（ The Single Schedule Point Location will be located at the process immediately after the last Supermarket in the entire Pull System. ）

所以，如果你比對每個拉式系統中接續的作業步驟，從收到原物料和資訊，到將產品交給顧客，在超級市場的情況，下一個作業程序就是單一計畫點。這指出有多種方法我們能用於單一的拉式系統，這是正確的。事實上，超級市場補貨方式通常是最不想要使用的拉式作法。

當顧客作業程序需要能選擇多樣物品號時，採用超級市場補貨技巧。假如顧客作業程序是個人電腦的組裝程序，這家公司按訂單組裝個人電腦。在收到訂單之前，組裝工作無法知道顧客想要的配件選擇。因此，超市建立庫存，持有每種想賣的物品，可能有四種不同的音效卡。在此例中，為每張不同的音效卡需要建立一個特殊的超市補貨系統。

（待續）