電子訂單自動處理系統的實作研究-以電梯產業為例

國 立 交 通 大 學

工 業 工 程 與 管 理 學 系 碩 士 班

碩 士 論

文

電子訂單自動處理系統的實作研究

--以電梯產業為例

An Implementation of E-Order Processing System

-- A Case Study for Elevator Industry

研究生：簡珮娟

指導教授：彭德保 博士

電子訂單自動處理系統的實作研究

--以電梯產業為例

An Implementation of E-Order Processing System

-- A Case Study for Elevator Industry

研 究 生：簡珮娟 Student：Pei-Chuan Chien

指導教授：彭德保博士 Advisor：Dr. Der-Baau Perng

國 立 交 通 大 學

工 業 工 程 與 管 理 學 系 碩 士 班

碩 士 論 文

A Thesis

Submitted to Department of Industrial Engineering and Management

College of Management

National Chiao Tung University

In

Partial Fulfillment of the Requirements

for the Degree of

Master in Industrial Engineering

July 2007

Hsinchu, Taiwan, Republic of China

電子訂單自動處理系統的實作研究

--以電梯產業為例

研究生：簡珮娟 指導教授：彭德保 博士

國立交通大學工業工程與管理學系碩士班

摘要

本論文是針對製造業的生產管理部門進行電子化改善研究，期望

能發展出一具有互動且整合的線上系統，促進各部門或供應鏈廠商間

的溝通與合作，以及提升生產力。本論文是應用一個以 BOM 概念為主

的資料儲存結構，研究與實作一電子訂單自動處理系統，並且能動態

地製作物料需求清單，在接到客戶的網路訂單後，能自動將其訂單規

格書(Order Specification)依客戶的需求轉換成所對應的電子化物料清

單(e-BOM)。其次，本研究也將顧客需求管理系統擴展至網際網路，讓

相關人員都能透過簡易的操作介面，達到資訊的分享流通，減少溝通

的時間或誤解，因此在將 e-BOM 轉換成產品採購清單(PO)之前，各部

門即能針對此資料庫的內容，加入許多客製化的要求，不但能提高客

戶的滿意度，也能即時、正確且有效率地幫助決策過程，可視情況彈

性延遲出貨或調整價格。最後，再透過儲存於零組件資料庫中的資料，

如：訂單規格資訊、零組件的資料、庫存數目、整備時間長短、供應

商資訊…等，將實作一 PO 轉換模組，透過本研究實作的簡化版 MRP

系統使得整條供應鏈上的各環節資訊都能透明化即時分享。本研究並

以一電梯產業為例，實作網際網路電子訂單自動處理系統，以驗證所

提方法之可行性，並做詳盡地討論與分析。

關鍵字：e-order、e-BOM、PO、顧客需求管理、物料需求規劃。

An Implementation of E-Order Processing System

-- A Case Study for Elevator Industry

Student: Pei-Chuan Chien Advisor: Dr. Der-Baau Perng

Department of Industrial Engineering and Management

National Chiao Tung University

Abstract

This paper was to develop an integrated web-based e-order processing

system which can enhance the interaction among the manufacturing

company, customers and suppliers in a supply chain, and can improve the

interaction among the departments in the manufacturing company. There

are four modules in the developed e-order processing system. The first

module is the order specification transformation module which is to

transform the e-order specification into e-BOM. The second module is the

e-BOM transformation module which is to transform the e-BOM into PO.

The third module is the PO integration module which is to integrate

individual m-BOM and distribute to suitable suppliers. The fourth

module is the customers' needs management module which is to collect

and integrate the customers’ needs in real time and dynamically from

customers and different departments of the manufacturing company. The

collected customers needs can be integrated and put into the website to be

shared among partners. Through this system, the customer’s need can be

shared among departments and proper correspondence be taken before

transferring. This can provide more information for decision-making in a

timely, accurate and efficient manner. All the transformation and

integration operations are based on a proposed tree structure of the parts

data base. Finally, an elevator industry was used as a case study to verify

the usefulness of the proposed web-based e-order specification

auto-processing system.

Keywords: Order Specification, e-BOM, PO, Customer Need

Management, Material Requirement Planning (MRP)

誌謝

時間真的過得很快，兩年的研究所生活轉眼就這樣過了，這段期間

感謝彭德保老師的教誨，除了在課業上的指導和學術上的研究，也讓

我在做事方法與態度上有所收穫，提早適應社會的生活型態。同時也

感謝實驗室的成員，學長彥仲、同學黛師、志凌、維琦以及學弟建男，

因為有了你們的陪伴與幫助，這兩年的生活顯得十分多采多姿，為我

的研究生生活增添許多樂趣。特別感謝富士達電梯公司提供專業上的

協助，使本研究得以順利完成。

最後感謝父母的栽培，以及提供生活上的幫助，讓我能無後顧之憂

的做完研究，謹以本文獻給所有認識我、關心我以及支持我的人。

簡珮娟

于 電腦視覺實驗室

民國九十六年七月

目次

摘要………..……...….…. I ABSTRACT………...… II 誌謝辭………...……..….… ………IV 目次………..….………….V 圖目錄………...………..…...VII 表目錄………..IX 一、緒論………...……….1 1.1 研究背景與動機……….………….…………....1 1.2 研究目的………..………2 1.3 研究假設與範圍……….……….………2 1.4 研究方法與架構流程……….……….………....3 二、文獻回顧……….…..…….…....6 2.1 3C 理論研究……….……….…...………...6 2.1.1 Commonality 共通性……….……….…………...…...…..6 2.1.2 Capacity 產能與交貨能力……….….………..……..7 2.1.3 Consumption 隨著市場需求變化而補充材料的模式………...8 2.1.4 Available To Promise(ATP)可允諾量….……….….……….9 2.2 物料需求清單的儲存方法……….………….……….……….10 2.3 顧客需求管理資訊系統………….………….……….………13 2.3.1 需求管理……….………..……..13 2.3.2 需求管理工具……….………….……….…....…..13 2.4 網路線上系統應用情形………….……….……….….……14 三、電子訂單自動處理系統之架構與研究方法………...……16 3.1 整體架構及流程簡介………….………...…...16 3.2 線上電子訂單規格輸入系統……….…………..……..………...18 3.3 零組件資料庫……….……….. …..……..…...19 3.3.1 零組件資料庫之資訊………..………..…….20 3.3.1.1 零組件資料之項目………...……..……...…20 3.3.1.2 零組件資料之來源與存取對象……...……...…..……20 3.3.2 零組件 BOM 表的儲存………..….…………..…...…..21 3.3.1.1 零組件 BOM 表儲存的方法……….……....……...….21 3.3.1.2 零組件 BOM 表儲存的功能…….….……...………....22 3.3.3 零組件資料庫之使用者運作分析………….………22 3.3.1 設計部門……….……….………....22 3.3.2 生產部門……….……….23 3.3.3 決策部門……….……….23 3.4 電子訂單規格轉電子物料清單之轉換方法...…..23 3.4.1 訂單規格轉換模組………...….……….23 3.4.1.1 訂單規格轉換流程………..………..…….……….24 3.4.1.2 訂單規格轉換方法………..………..………...…...25 3.4.2 訂單規格轉換方法簡例………….………...…...……..25 3.5 線上顧客需求管理模組…..………....………29

3.6 電子物料清單轉產品採購清單之轉換方法………...……..31 四、實作結果………...………..34 4.1 實作案例………...…...34 4.1.1 線上電子訂單規格查詢輸入系統……….………...34 4.1.2 零組件資料庫管理……….………...…39 4.1.3 電子訂單規格轉換成電子物料清單..……..……...41 4.1.4 顧客需求管理模組..……….….………..…………..42 4.1.5 電子物料清單轉換成產品採購清單………...42 4.2 討論與分析………...………....44 五、結論及未來研究方向……….………..………..………46 5.1 結論………...………46 5.2 未來研究方向………...………....46 參考文獻………...………..………47

圖 目 錄

圖 1-1 電子訂單自動處理系統流程圖………4 圖 2-1 材料清單與規格管理的運作流程比較………...6 圖 2-2 過度訂單承諾影響推移圖………...7 圖 2-3 3C 理論與供應鏈之關係圖……….……...8 圖 2-4 傳統的模式與 3C 模式的比較……….9 圖 2-5 不同的營運模式，其訂單實現模式與庫存關係……….………..9 圖 2-6 3C 理論的訂單實現計畫系統架構……….……....10 圖 2-7 以 lamp 產品為例的結構樹………11 圖 2-8 父元件列表……….………….11 圖 2-9 子元件列表……….……….11 圖 2-10 典型的 Gozintograph……….………12 圖 2-11 記錄圖 2-4 的屬性表(左)與記錄表(右) ……….………..12 圖 2-12 需求工程架構圖……….………...13 圖 2-13 達方電子專案系統架構圖……….………...14 圖 2-14 偉全企業電子化運作模式─業務、採購部分架構圖……….……15 圖 3-1 電子訂單自動處理系統架構圖……….………..16 圖 3-2 電子訂單自動處理系統整體流程示意圖……….……….………….17 圖 3-3 研究步驟示意圖……….………..18 圖 3-4 零組件資料庫之存取對象……….………..21 圖 3-5 設計部門使用零組件資料庫之流程……….………….22 圖 3-6 生產部門使用零組件資料庫之流程……….……….23 圖 3-7 電子物料清單資料製成圖……….………..24 圖 3-8 電子物料清單製成運作流程圖……….……..24 圖 3-9 範例之零組件結構圖………...………..26 圖 3-10 顧客需求模組整體流程示意圖……….……...30 圖 3-11 MRP 轉換資料流示意圖………...…….32 圖 3-12 產品採購清單製成運作流程圖………...….33 圖 4-1 電子訂單自動處理系統功能顯示圖………...34 圖 4-2 使用者登入機制圖………..35 圖 4-3 電子訂單規格新增介面圖………..36 圖 4-4 連動控制選項圖………...…...36 圖 4-5 連動控制顯示圖………...37 圖 4-6 電子訂單規格第二頁顯示圖………..37 圖 4-7 電子訂單規格第三頁顯示圖………...37 圖 4-8 常用輸入選取示意圖………..38 圖 4-9 圖面資訊輸入介面圖………..38

圖 4-10 圖面資訊上傳檔案示意圖………...39 圖 4-11 電子訂單規格查詢說明圖………...39 圖 4-12 零組件 C1 查詢結果顯示圖………40 圖 4-13 零組件 C2 查詢結果顯示圖……….40 圖 4-14 零組件 C3 查詢結果顯示圖……….41 圖 4-15 電子物料清單顯示圖………...41 圖 4-16 顧客特殊需求查詢示意圖………...42 圖 4-17 供應商 s1 對應顯示圖……….43 圖 4-18 供應商 s2 對應顯示圖………..43 圖 4-19 生產計畫資訊顯示圖………...44

表 目 錄

表 2-1 材料暫留計算公式表………...8 表 2-2 記錄標記表……….……….11 表 2-3 Gozintograph 記錄符號表………12 表 3-1 使用系統部門對照表………..18 表 3-2 電梯產業規格主要項目與簡例表………..19 表 3-3 零組件資料庫資料表主要項目………..20 表 3-4 零組件資料庫之資料來源………...21 表 3-5 父節點符號表示說明………..21 表 3-6 子節點符號表示說明……….…….22 表 3-7 父節點儲存表……….………..26 表 3-8 子節點儲存表………...26 表 3-9 轉換後的父節點表……….……….27 表 3-10 轉換後的子節點表……….…………...28 表 3-11 物料需求統整表……….………...28 表 3-12 顧客需求管理模組三大功能……….………29 表 3-13 電梯產業常見特殊需求註記舉例……….………30

第一章 緒論

1.1 研究背景與動機 許多結構複雜及客製化程度高的產品，通常是由許多零組件交錯複雜地整 合所構成，有別於以往接單式的生產模式(Make-To-Order，MTO)，此類產品 製造商都會考慮用規格生產(Build To Configuration，BTC) 的方式或組裝式生 產，此類產品的物料清單是由客戶或預測者在需要的時候，才去產生物料需求 計畫，也就是在取得訂單後才將物料組合成最終產品的生產模式；此種 BTC 生產模式僅會針對部份共用零組件做庫存，並不會將成品當作存貨。因此，如 何有效地將客戶的規格需求快速地轉換成所需要的電子物料清單(e-BOM)與 產品採購清單(PO)，變成一個值得關注且重要的議題。但是，大部分的電子訂 單系統並不能直接連結 BTC 的運作，必須再加上其他功能模組，如產品引擎， 這樣的系統較缺乏整合性。 確定接單後的生產計畫與管理包括主生產排程與物料需求規劃，其中主 生產排程(Master Production Scheduling，MPS)系統乃是指出一個工廠用來安 排該在何時生產什麼產品以及生產多少數量，由訂單預測和短期接單資料作 為 MPS 的主要輸入項目；對客製化程度較高的電梯產業，通常不會將成品當 作存貨，而是依據顧客的訂單需求規格與數量再進行生產與組裝。物料需求 規劃(Material Requirement Planning，MRP)則是將某特定需求量之成品，轉 換成其構成零組件的物料需求，並用成品及零組件的生產前置時間及物流配 送時間等資料倒推，以決定何時該進行訂購與訂購多少數量。然而傳統的電 子訂單系統並未讓銷售訂單和生產工單有直接關聯，此部分需再經由許多轉 換，且過程較為煩瑣且耗費時間。 再者，面對客製化程度高的產品，能充分掌握並快速反應顧客需求，亦 是不可或缺的成功關鍵因素之ㄧ。因此在傳統 MRP 規畫之前，再發展一顧客 需求管理模組，以有效地回應或管理顧客需求，確保最終產品能符合其需要， 已是走向客製化時代不可或缺的。。 目前市面上已有許多製造業電子化相關的商用系統，如電子訂單系統、 庫存系統、MRP 系統、顧客需求管理系統等，但是這些商用系統對傳統中小 型製造業電子化所需的必要功能上有所不足，故本研究主要欲針對以下三個 問題提出解決方法： 1、一般電子訂單系統不能直接連結規格生產模式的運作，必須再加上其他功

2、傳統電子訂單系統並未讓訂單和生產工單有直接關聯，需經由許多的轉 換，造成時間上的浪費。 3、大部分的電子訂單系統少有提供支援客製化的功能 1.2 研究目的 本研究擬實作出一可將客戶訂單進行自動轉換的系統，能將營業部門透 過網路輸入的客戶電子訂單，根據訂單上各產品之零組件資料庫先轉換成 e-BOM，再與庫存系統整合，了解各元件或半成品的庫存狀態以及預計收貨 的時間，即時地轉換成 MRP 的輸入，如此一來，不僅能讓公司內部各部門 了解目前所需要向下游供應商開立的採購單，並且能使得各個供應商透過網 路，馬上得知所要提供或生產的零件種類、數量、交貨日期。 如此的轉換機制主要是使用 ASP.NET 以及 SQL Server 實作網際網路電 子訂單自動處理系統，將網路訂單規格及項目利用 Tree structure 作轉換，再 由規格中的日期、公司現有零組件資料庫中的庫存量、各個零組件的生產、 配送前置時間、預計收貨的數量…等，自動製成主生產排程(MPS)。其次， 因我們探討的案例對象電梯產業擁有客製化特性，故加入顧客需求資訊管理 系統以便尋找、紀錄、組織、追蹤客戶需求，在 e-BOM 轉換成 PO 前能即時 增減所需的客製化零組件，或進行延遲交貨、增減價格的決策。最後，再依 據零組件資料庫中所儲存的轉換內容執行物料資源規劃(MRP)，使各個下游 各級供應商，均能透過本研究所開發之系統自動且即時地得知需提供生產的 零組件種類、數量，以及交貨時間。 1.3 研究假設與範圍 本研究有以下七項假設與限制： 1、假設已事先做好可允諾數量的模擬。 2、假設決策者會至顧客需求管理系統，查詢顧客所列之客製化需求，並且依 此做售價及出貨時間調整。 3、客戶下訂單後，須由營業人員填寫詳細規格(Order Specification，OS)。 4、各個產品的組成結構表，以結構樹由上而下、由左而右的方式儲存至零組 件資料庫中。 5、假設無產能限制問題，只要有客戶下單即接受，並且自動轉換成 e-BOM 與 PO，最後下游各級供應廠商可透過系統即時得知需提供生產的零組件種 類、數量，以及交貨時間。 6、假設同一材料合併後，將統一開採購單給一固定供應商。 7、本研究所研發之電子訂單自動處理系統所考慮的模組項目包括庫存數量、

預計收貨、產品結構、需求數量、對應之供應商以及 lead-time。 而本研究的範圍則是從營業人員透過網際網路輸入客戶訂單規格資料 (Order Specification)至轉換成產品採購清單(PO)，主要的輸入項目為營業人員 輸入的電子訂單規格以及設計人員所輸入的圖面資訊，擬自動轉換成時間軸顯 示之生產計畫，可供下游各級供應商查詢以及輸出顧客特殊需求，整體步驟簡 述如下： 1、客戶確定下單，由營業人員透過網際網路，填寫線上電子訂單規格系統。 2、依”規格生產模式”的概念，將電子訂單規格自動製成電子化物料清單 (e-BOM)。 3、製成之電子化物料清單透過物料資源規劃(MRP)，轉換成產品採購清單 (PO)。 4、用時間軸的方式顯示最早開工與最晚開工的時間，就公司內部而言，可得 知所需下採購單給下游各級供應商的數量與時間點；就供應商而言，可得 知客戶下單的時間、數量總和，以及最晚需完工的時間點。 1.4 研究方法與架構流程 本論文的研究方法與流程，簡述如下： 第二章、文獻探討 分成五個部分來探討： 1. 3C 理論研究 2. Available To Promise(ATP)研究 3. 物料需求清單的儲存方法 4. 需求管理系統 5. 網路線上系統 第三章、網路訂單規格轉換系統之架構與研究方法 完整的電子訂單自動處理系統可概分為以下七個部份： 1、ATP 模擬/查詢 2、線上電子訂單規格系統 3、零組件資料庫 4、從 OS 到 e-BOM 的轉換 5、顧客需求管理系統 6、從 e-BOM 到 PO 的轉換 7、ATP 計算

營業部人員輸入

兩項輸入資訊->

設計部人 員輸入 而本研究將不實作 ATP 模擬/查詢以及 ATP 計算兩個部分，僅就 其他的五個項目作較深入的研究與實作，其流程圖如下圖 1-1 所示。 圖 1-1 電子訂單自動處理系統流程圖 第四章、實作結果 本研究以 F 電梯公司為例，運用所發展的整合性電子訂單自動 處理系統，實作訂單產品規格自動轉換機制，並且考慮客製化產品特 傳配物料清單

電子訂單規格轉換成電子物料清單模組

顧客需求管理模組

線上電子訂單規格查詢輸入系統

供應商物料清單彙整模組

下游各級供應 商、生產部門 決策部門、設 計部門、其他 審訂顧客需求

電子物料清單轉換成產品採購清單模組

零組件資料庫

電子物料清單 零組件庫存資訊 訂單圖面資訊 訂單規格資訊 產品採購清單

性，加入顧客需求管理模組，以符合客戶需求，最後製成產品採購應 用於物料規劃與生產計劃。

第五章、結論及未來研究方向

總結本研究所獲得的成果，分析實作效能，以及未來可進一步發 展的研究方向與議題。

第二章

文獻回顧

2.1 3C 理論研究 在《全球供應鏈管理》中提到傳統的資源需求計畫與第一線營業部門的 接單作業幾乎是脫節的，它不像全球供應鏈管理資訊系統一般，可以在接受 訂單的同時就做模擬，以確認客戶可以收到貨的時間。傳統的資源需求計畫 也缺乏與上下游供應商和客戶連線，進行協同運算(Collaborative Calculation) 的概念與設計，它只著重企業內部資源的需求與應用的運算。 3C 理論則是強調資源需求計畫是隨著市場的變化，以每日至少一次資源 計畫，快速調整資源的採購與應用，也特別注重上下游供應商和客戶的資訊 透通與協同運算的設計，企業必須儘可能將交易規則透過資訊系統的規劃與 建置，以達到快速反應客戶需求的基本規劃。3C 理論包含以下三個最主要的 基本理念與價值： 2.1.1 Commonality 共通性 其概念是透過擴大運用「共用材料或資源」的策略及產品組合規劃， 達成降低開發成本、簡化資源管理、降低庫存量及提供多樣化商品給客 戶的目標。但由於其強調材料的共用性，則造成產品機種數的減少。 在共用材料的規劃方面，必須打破由單一成品的角度來規劃的思考 模式，改為由提供客戶具有材料(資源)選擇功能的方式，來規劃商品的 規格，也就是所謂的＂規格管理(Configuration Management，CM)＂， 其有兩個主要的功能：一是採用產品架構的方式來定義商品與材料之間 的關係，二是從技術的角度來定義產品之組合規則。而用來定義商品與 材料之間的方法有材料清單(Bill of Material)以及產品架構(Production Structure)。由圖 2-1 可知，採用材料清單的方式，在材料編號規則上需 要下很多功夫去編製，可是如果採用規格管理的運作方式，成品的料號 只需要流水號碼就可以了，故客戶透過這樣的模組規劃，可以自由選擇 所需要的材料、商品、規格或是服務。 材料清單(Bill of Material，BOM)的運作程序： 規格管理(Configuration Management，CM)的運作程序： 圖 2-1 材料清單與規格管理的運作流程比較 產品 設計 材料 編號 成品 編號 建置 ERP Item Master 資源需 求計劃 接受 訂單 產品 設計 材料 編號 成品 編號 建置 ERP Item Master 資源需 求計劃 接受 訂單

實際產能 供應能力 承諾之訂 單數量 2.1.2 Capacity 產能與交貨能力 其理論是架構在「供應鏈」上所有相關企業，不論是生產能力、供 給能力或是配送運輸能力均有其限制，而所有資源的調整與分配，都是 在其限制之內進行，透過這樣的限制理論去執行資源調整與分配計劃， 可以使企業有能力在接受訂單的同時，即進行資源分配計劃作業，避免 「過度訂單承諾(Order's Over Commitment)」的情形發生。由圖 2-2 可 知準時交貨比承諾更重要。 圖 2-2 過度訂單承諾影響推移圖 Capacity 理論的另外幾個重要的理念是：暫留與確留。所謂「暫留」 是指客戶接到報價後，需要短時間的考慮，於是在客戶未下單又要求保 留資源的情形下，業務人員將與客戶洽談好的商品及實現該訂單所需要 的資源(如材料與產能等資源)，預先在資訊系統上暫時保留的動作。但 是暫留愈多，對於材料與產能等資源運用的自由度就愈低，所以必須將 暫留設定在一個可接受的時間內，否則過度運用此功能，將降低資源運 用率，增加庫存風險。另外「確留」則是指當客戶下了訂單之後，業務 人員將實現訂單所需要的商品及資源予以保留的功能，是指已經分配的 資源，不可再重新被分配。 針對執行系統方面，業務人員能在接單時進行資源保留的模擬，且 需考量是可供許多人同步操作的，即架構一個可以同步即時回應的模擬 計劃系統，如此可大幅改善耗費在處理訂單及後續作業的協調時間，達 對客戶之過度承諾 供應商材料短缺率增加 交貨期變成不確定 客戶不滿意度提高 準時交貨比承諾重要

成以下幾個目標：(1)系統可以同時供給許多人使用；(2)訂單的切割與 分批出貨情況可以降低；(3)每日的產能可以被充分運用，使效能達到 最好。 而材料暫留的計算公式可由表 2-1 計算出。 材料暫留的計算公式 ※允許被預留和保留之數 量(Available To be Book， ATB-B) 在庫存量 + 已下採購單數量–已被保留 和預留數量 + 允許再接訂單數量(ANO) ※ 允 許 再 接 受 訂 單 數 量

(Available New Order

QTY，ANO) 供應商每日之最大供給數量-已下採購單 數量 表 2-1 材料暫留計算公式表 2.1.3 Consumption 隨著市場需求變化而補充材料的模式 其基本理念是透過即時之市場資訊，並結合市場需求的預測模式， 實現在需要之前才去購買材料的機制，進而達成降低庫存水準、減少資 金準備以及降低庫存品之折價損失等多項目標。 雖然銷售預測或需求預測是不可能準確的，但是針對期長料，若沒 有銷售預測，則缺料的風險則會非常高，而 Consumption 理論的做法是 根據客戶每天的訂單需求，所消耗的材料項目與數量，去預估後續的材 料需求模式。而且 3C 理論對於一些很基本的作業會要求嚴格的執行， 例如：必須事先取得供應商對每一天「每日最大供應量」的承諾、必須 針對每一個材料設定「採購前置時間」、供應商所承諾的每日最大供應 量與採購前置時間必須百分之百做到。整體而言，3C 理論與供應鏈之 關係可從圖 2-3 了解。

Commonality Commonality Commonality Commonality Capacity Capacity Capacity

Commonality Commonality Capacity Capacity Capacity Consumption Consumption Consumption Capacity Consumption

圖 2-3 3C 理論與供應鏈之關係圖 產品 開發 資源需求 計劃分析 客戶 詢問 客戶 訂購 資源 分配 採購 作業 生產 作業 生產 作業 客戶 服務

2.1.4 Available To Promise(ATP)可允諾量 3C 模式是一種整合訂單實現模式與資源需求計劃關係的作業模式， 依據下列三個階段來實現客戶的訂單，以達到客戶滿意與兼顧近低庫存 的目標。 (1) 接訂單之前，企業必須先依據訂單與銷售預測，執行材料與產能之需 求計劃，及執行期長料之採購計劃。 (2) 接受訂單時，企業必須同時將材料的數量與生產的產能保留下來，即 利用 3C 理論中 Capacity 所提到的暫留概念。 (3) 接受訂單後，企業必須依據生產計劃，去執行 JIT 料的叫貨；意思是 指在需要時才打電話訂貨，以利後續作業。 其訂單實現模式與傳統的其他訂單模式比較如圖 2-4、圖 2-5 所示。 另外 3C 理論的訂單實現系統架構則如圖 2-6 所示。 傳統模式 3C 模式 圖 2-4 傳統的模式與 3C 模式的比較 ‧接單出貨(BTS)的訂單實現模式 ‧接單生產(BTO)的訂單實現模式 ‧3C 訂單實現模式 圖 2-5 不同的營運模式，其訂單實現模式與庫存關係 材料需 求計劃 回覆客 戶訂單 資源需求 協調會議 材料需 求計劃 回覆客戶訂單 前之資源需求 回覆客 戶訂單 生產 計劃 採購 作業 生產 作業 客戶 詢問 客戶 訂購 資源 分配 配銷 作業 客戶 詢問 客戶 訂購 生產 計劃 資源 分配 採購 作業 生產 作業 配銷 作業 資源需 求分析 客戶 詢問 客戶 訂購 資源 分配 採購 作業 生產 作業 配銷 作業

Reservation 計算 訂單實現

圖 2-6 3C 理論的訂單實現計劃系統架構

2.2 物料需求清單的儲存方法

物料管理是 MRPII 系統中一個很重要的核心，而物料需求清單則是物料 管理的基石，一個有效率的、有彈性的儲存模組將是企業資訊系統績效好壞的 關鍵。本研究引用 Guoli et al. (2003)對於 BOM 的儲存方法，大致可分為以下 兩類： (1)樹狀結構：使用產品樹的結構(圖 2-7)，儲存內容分為兩個列表，分別記錄 父元件與子元件內容，其中各個標記所代表的內容如表 2-2。 在父元件表格中，每一項記錄中都包含有三個位址項目(圖 2-8)： a.指出此元件所歸屬的產品 b.此元件在產品樹的哪一個階層 c.此元件所在產品樹某一階層中的位置 在子元件列表中則是另加入兩項特殊連結(圖 2-9)： a.指出其父節點的所在階層 b.此子節點之下是否已無其他子節點 訂單輸入 規格管理 可用 產能 計算 每日建 議生產 排程 排程 可用 庫存 計算 調整訂單 Allocation 採購

圖 2-7 以 lamp 產品為例的結構樹

表 2-2 記錄標記表

Product no. The serial number of the final product

Level no. The serial number of the level, the item belongs to. Location no. The serial number of the location on the level. Parent loc. The parent item＇s location number.

Child mark Boolean to indicate the existence of a child item. Material name User-define fields.

圖 2-8 父元件列表

(2)圖形結構：典型的圖形儲存結構─Gozintograph (Guoli et al. 2003)如圖 2-10，相當於一個網路結構，其能避免重複的項目出現，其特點 是 每 個 物 體 只 出 現 一 次 ， 但 是 其 記 錄 結 構 也 較 為 複 雜 。 Gozintograph 之符號表如表 2-3，整體記錄表格如圖 2-11。 圖 2-10 典型的 Gozintograph 表 2-3 Gozintograph 記錄符號表 I Record Addr (attribute table) II Addr as Parent (attribute table) III Addr as Child (attribute table) IV Product (attribute table)

V Record Addr VI Parent Addr VII Child Addr VIII Next Parent IX Next Child X Quantity 圖 2-11 記錄圖 2-4 的屬性表(左)與記錄表(右) 如此的圖形表示方法，在建構與維護上都較為複雜困難，並且要留意 dead loop 的出現，本研究將採用樹結構方式作儲存依據。

2.3 顧客需求管理資訊系統 2.3.1 需求管理

Leffingwell and Widrig (2000)認為需求管理包含尋找顧客的需求、記錄 顧客的需求、組織顧客的需求、以及追蹤顧客需求變化等活動。故將需 求管理定義為「一個擷取、組織，及文件化需求的系統化方法。亦即在 一個系統需求改變時，建立及維護顧客與專案團隊之間協議的過程」。 而 Larman (2002)則明白地指出了在軟體的開發過程中，若在使用者需 求不明確的情況下，需求會有不可避免的變動。所以需求管理亦是「用 系統化的方式找出、紀錄、組織並追蹤系統的變動需求」。 另外，需求工程(requirement)常會與需求管理有所混淆，Wiegers (2003) 認為需求工程不僅包含了需求管理，亦囊括了需求開發這個部分(圖 2-12)。其中需求開法主要有需求的擷取、分析、規格化、確認等活動； 而需求管理則有需求的變更控管、版本控管、需求追蹤等活動。 資策會在其所發表的 CMMI 導入指引(資訊工業策進會資訊系統實驗 室，2002)內提到需求管理的目的是在「避免成本超支、延遲交貨、品 質不良及客戶不滿意的情況發生，並有效地管理使用者需求，以確保最 終產品及產品組件均符合使用者需求。」 圖 2-12 需求工程架構圖 (資料來源：Wiegers, 2003) 2.3.2 需求管理工具

Ulrich and Eppinger (2002)認為需求管理工具在創造一個高品質的資訊 流通管道，讓資訊得以直接在目標市場的顧客與產品開發者之間順利流 通。達成下列目標： (1)確保產品的焦點放在顧客需求上。 (2)確保潛在和隱藏的需求如同確保明確的需求一般。 (3)為產品規格的適切性提供一個事實基礎。 (4)創造一個開發流程中需求活動的檔案記錄。

(5)確保沒有任何主要顧客的需求被遺漏或忽略。 (6)在發展團隊成員中逐漸養成對顧客需求的共同認知。 目前在市面上已有許多需求管理系統，Volere 公司對於這些需求管理工 具的功能做了簡單的描述與評論，提供選擇需求工具的一項參考。 2.4 網路線上系統應用情形 資訊技術的演進，透過網際網路的協同合作架構，已是製造業下一步所 應著手的領域，Bentley (1995)首先指出各廠商合作的資料是可共享於網際網 路上，而 Lau (1998) 則進一步地研究 Intranet/Internet 技術未來在製造業的角 色，總結此新科技是企業希望達到更快速反應、高度彈性的一個有利且經濟 的解決方法。 此外許多學者紛紛提出一些線上系統的架構，Wang et al.(2003)發展了一 個 e 化入口，使企業在訂購流程合作、協同規劃透過網路更為容易便利。而 Xiong et al.(2003)則是開發了一線上 ATP 系統，利用 BOM 表的結構，開發出 動態計算系統，使公司營業部門人員能夠即時得知各個時期的 ATP。

而在客戶關係系統方面，Veeramani and Joshi (1997)提出了一個方法能快 速回覆報價需求，提供網路上買賣互動關係的基礎。而 Helander and Khalid (2000)則進一步地分析客戶在電子商務中之決策流程。 目前經濟部工業局也成功地完成了許多產業電子化的專案計畫，像是零組 件供應商的達方電子(2005)，改變其營運模式為協同式關鍵零組件合作伙伴， 透過預測生產、接單後加工、電子化快速回應客戶需求，開發一體系電子化系 統，涵蓋業務、設計、採購、驗收、生產、出貨等部門，提高作業效率、需求 預測準確度以及供應鏈流程效率。其系統架構如圖 2-13。 圖 2-13 達方電子專案系統架構圖 (資料來源：經濟部工業局產業電子化網站)

而偉全企業(2005)由於在台灣及大陸都有設廠，為了改善以往透過電話、 FAX、e-mal 等人工作業方式，降低其造成專案延誤、無法即時回覆客戶交期、 訂單處理時間冗長等情形，發展體系間作業模式整合及流程再造，建立體系間 電子商務 B2B 系統等。其電子化運作模式如圖 2-14。 圖 2-14 偉全企業電子化運作模式─業務、採購部分架構圖 (資料來源：經濟部工業局產業電子化網站)

第三章 電子訂單自動處理系統之架構與研究方法

3.1 整體架構及流程簡介 本研究的主要目的除了將生產管理過程導入電子化外，亦希望能夠提高效 率、加速決策時間以及動態即時反應，解決傳統電子訂單系統的一些問題。 整個系統的架構如圖 3-1，而其中可允諾量計算(Available To Promise，ATP) 的兩個部份，在此研究中並未實作出僅做說明及文獻探討。 圖 3-1 電子訂單自動處理系統架構圖 整體流程主要包括以下五個部份： (1)線上電子訂單規格查詢輸入系統 (2)零組件資料庫管理 (3)電子訂單規格轉換成電子物料清單模組 (4)電子物料清單轉換成產品採購清單模組 (5)顧客需求管理模組 整個運作流程一開始是企業進行可允諾量(Available To Promise，ATP)的 模擬，計算出可滿足或承諾給客戶的商品數量與交貨時間，並於客戶下單後， 業務人員為客戶將實現訂單所需要的商品及資源予以暫留或確留，降低無法

線上電子訂單規格查詢/輸入系統

電子訂單規格轉換成電子物料清單模組

電子物料清單轉換成產品採購清單模組

供應商物料清單彙整模組

顧客需求管理模組

下游各級供應 商、生產部門 公司內決策部門、 設計部門、其他 客戶訂單資訊 電子物料清單 零組件庫存資訊 產品採購清單

準時交貨的風險，此部份假設企業已進行完成。另外企業內建立零組件管理 資料庫，將廠內的 BOM 表資料、庫存狀況、對應供應商…等資訊，加以管 理且能及時做更新。當透過網路輸入網路訂單規格表時，能利用＂Order Specification 到 e-BOM 的轉換＂,先從元件資料庫中讀取所對應的資訊，再 進一步地製成電子化物料清單(e-BOM)。 接下來依據顧客需求管理模組中客戶的特殊需求，做修改或是交貨日期 變動等決策。最後再由零組件資料庫中的資訊、顧客需求管理系統中的客製 化項目的調整與設定之後，執行 e-BOM 到 PO 的轉換，也就是將物料需求規 劃(Material Requirement Planning，MRP)電子化，使各供應商在網路訂單規格 輸入完成的同時，能夠透過網路馬上得知所需生產的零組件數量以及交期。 亦能進一步地計算出可允諾量，供營業部門作為對於客戶需求是否允諾的參 考依據。其流程示意說明如圖 3-2 所示，而各個部份的詳細說明將於後面章 節再進行討論。 圖 3-2 電子訂單自動處理系統整體流程示意圖 告知圖面需求 _設計部門 營業部門 告知規格 需求 客戶 輸入 OS 線上電子訂單規格 查詢輸入系統 輸入圖 面資訊 查詢 OS 顧客需求管理模組 輸入顧客 特殊需求 查詢顧客 特殊需求 讀取 OS 中 rematk 生產部門 e-BOM PO 詳細規格 查詢零組 件資訊 查詢顧客需求 零組件資料庫 庫存 其他 輸入/查詢庫存 量、前置時間… 等資訊 查詢 MRP 資訊 決策部門 各級供應商 查詢所需生產零組件種類、數量及交期 查詢 OS 產品規 格查詢/ 變更

另外上述實作部分的使用者，在本研究中的電梯產業，將給予不同權限 登入使用各個功能，其使用對照整理如下表 3-1 所示。 表 3-1 使用系統部門對照表

<系統之使用者權限對照>

使用功能 使用部門 備註 線上電子訂單規格輸入系統 設計部、營業部門、決策者 零組件資料庫管理系統 設計部、生產部、決策者 顧客需求管理系統 決策者、設計部 產品採購清單製成 生產部、供應商、決策者 皆可使用 查詢功能 而整個研究的進行步驟分成三個階段逐步完成，首先先與電梯產業廠商 討論一般電梯產業現況、電梯設計圖…等的資料；接下來探討目前所使用的 系統或是檔案，如何轉而製作符合電梯產業要求的線上系統以及目前所使用 的品目明細表；最後討論實作系統測試後應修改的項目，再做修正與日程表 的製作。整個進行的研究步驟階段可由圖 3-3 清楚了解。 圖 3-3 研究步驟示意圖 3.2 線上電子訂單規格輸入系統 此部份是將以往的訂單規格系統轉移至網路平台，使客戶的要求，由營 業人員使用此系統輸入其電子訂單規格資料，除了基本的輸入模式之外，更 增加了許多動態連動關係，以避免在輸入規格資料時造成不必要的錯誤，損 耗其他人員核對的時間；此外也加入了圖面管理系統，可上傳設計圖表，使 客戶所需要的產品規格能更完整的讓製造廠商了解。而針對電梯產業而言， 其主要規格包含的以下幾個重要的項目如表 3-2 所列，並舉一些範例輔助說 明。 電梯產業現況討論 電梯 Order Specification 設計部所繪製之設計圖 期望成果討論 目前使用單機系統與檔案 線上系統功能項目討論 系統測試 & 更新 ¾ OS 之 excel 檔案 ¾ 設計圖紙本 ¾ 歷史 Access 資料庫檔 ¾ OS 範例資料 ¾ 品目明細表轉換 excel 檔案 ¾ 大日程表 excel 檔案 ¾ 功能項目修正

表 3-2 電梯產業規格主要項目與簡例表

<電梯產業 Order Specification 主要項目>

項目 範例 編號 TW-5415 用途 Condominium 出貨日 20051025 安裝完成日 20060105 測試完成日 20060115 0.基本項目 保固與保養 2/1000/per day 1. 主要規格 700kg/10persons、B1、01-13、R 樓…等。 2. 電子動力規格 3 phase 380V…等。 3. 應用與結構規格 Earthquake Zone(Y)…等。 4. 控制規格與選項 9.5kw/T type、Roping 1:1…等。 5. 各樓層停靠設計與固定 Door Do-700、SI-2…等。

6. 內部電話、警報器設備規格 Phone Type: GMT、with car bell…等。

7. 未決定之項目 無 8. 註記 殘障專用運轉樣式、機車箱內 CCTV 設置 在改善規格表輸入錯誤方面，就電梯產業而言是十分重要的項目，由於 有許多規格上的限制，因此填入資料的錯誤將導致電梯的無法運作，在此本 研究探討電梯所需注意不可隨意填寫之規格，製作連動控制以確保輸入資料 的正確性，大致上包含了許多需做連動控制，例如：(1)電梯主要用途←→重 量←→人數；(2)開門 R←→開門 L←→開門 C；(3)電燈電力←→V←→ KVA……等許多電梯規格上所需注意的限制。 本研究另外製作一圖面管理系統，其編號是依照電子規格輸入系統所填 入的資料，可讀取電子訂單規格資訊，再進行圖面資訊的補充，將許多原本 附註於工程圖旁的紀錄與描述，填入此系統中，並且可讓設計部門上傳工程 圖或是掃描圖片，讓規格資訊更能貼近客戶的需求，減少事後修正討論所需 耗費的時間。而圖面管理系統中包含項目如各個停靠樓層空間示意圖、同一 標號不同機車箱的資料說明…等。 3.3 零組件資料庫 此資料庫的內容包括庫存量、生產/配送前置時間、各零組件之 BOM 表、 零組件所對應供應商關係等，各部門可透過查詢功能得知目前所剩餘的庫存 量、各零組件的前置時間與所對應之供應商。另外，由營業人員所輸入的電

子訂單規格資訊也儲存於此資料庫中，可供其他部門做查詢、轉出製作日程 表…等其他用途，而在電子訂單轉 e-BOM 的轉換模組中所需要的數量及名 稱，可由零組件資料庫讀取獲得。 3.3.1 零組件資料庫之資訊 3.3.1.1 零組件資料之項目 本研究中所考慮的資料庫項目，主要為能使所儲存的資訊有 效地轉換成電子化物料清單，故其項目如表 3-3 所列。 表 3-3 零組件資料庫資料表主要項目 前置時間 (週) 供應商 時間點 (週) 期初庫 存量 預計收 貨量 - 10 - C001-001 1 - 2 10 - 20 - C002-002 1 - 3 - 75 - 15 - C003-003 2 - 3 - 50 - 10 - 3 - 200 5 - 120 C1 1 S1 6 - 180 另外也將電子訂單規格資料加以儲存，使資料庫中的零組件 做即時更新，同時也把各產品的主要結構資訊儲存其中，如物料 清單，也就是包含了一組為生產一個單位最終產品所必須之半成 品、零件與原物料等相關資訊，而物料清單通常可用表列式或結 構樹的方式來顯示其關係，目前普遍的表達方式是使用多階物料 清單，本研究在此將對儲存方式做修正，使此系統可支援 Build To Configuration 的運作，解決以往需有產品引擎的電子訂單系統。 3.3.1.2 零組件資料之來源與存取對象 本研究中的零組件資料庫管理系統，主要由決策部門、設 計部門、生產部門進行存取，而其中決策部門人員僅做讀取的 動作，所提出之意見將不儲存於此零組件資料庫中，而生產部 門以及設計部門的人員，則包括儲存資料及讀取資料兩個動作 如圖 3-4 所示，而各部門所存取的資料如表 3-4 所示。

表 3-4 零組件資料庫之資料來源 使用者 儲存資料 讀取資料 決策者 - 全部資訊 設計部門 OS 資料、圖面資料、產品 結構資料 零組件規格資料 生產部門 零組件前置時間、零組件 庫存資料、對應供應商 庫存數量、應生 產的數量 3.3.2 零組件 BOM 表的儲存 3.2.2.1 零組件 BOM 表儲存的方法

運用類似 Guoli et al. (2003)對於 BOM 的儲存方法，將每個零 組件的 BOM 表分成父節點與子節點兩個項目先做儲存，其中父 節點表格包含八個項目，如表 3-5 所示。另外子節點表格則包含 七個項目，如表 3-6 所示。 表 3-5 父節點符號表示說明 Product No. 產品編號 Level No. 零組件所在結構樹中的層次(設第一層為 1) Branch No. 零組件所在層次中的分支(最左設為 1) Sub-Quantity 所需零組件數量

Parent Level No. 此零組件父節點之層次 Parent Branch No. 此零組件父節點之分支位置 Material Name 物料名稱 Mark 此節點的父節點之上是否已達 Level 1 (T/F) 生產部門 決策部門 設計部門 零組件資料庫 圖 3-4 零組件資料庫之存取對象

表 3-6 子節點符號表示說明

Product No. 所對應的產品編號

Level No. 子零組件所在結構樹中的層次 Branch No. 子零組件所在層次中的分支 Sub-Quantity 所需子零組件數量

Parent Level No. 此零組件父節點之層次 Parent Branch No. 此零組件父節點之分支位置 Material Name 物料名稱 3.3.2.2 零組件 BOM 表儲存的功能 將各零組件的 BOM 表資料先依照父節點、子節點分開儲存 至零組件資料庫，若有變動則可直接至資料庫中加以修改，而轉 換模組也會自動重新計算，可大幅節省時間、增加效率。另外運 用樹結構的儲存方式也可以降低複雜度，較容易實作。 3.3.3 零組件資料庫之使用者運作分析 本研究中的零組件資料庫由設計部門、生產部門以及決策部門進行存 取動作，而各個部門的運作流程皆不相同，且在任一部門更動此零組件資 料庫資訊的同時，所有相關的報表與資料會自動轉換更新，因此以下將對 各個部門的操作流程做詳盡的分析。 3.3.3.1 設計部門 設計部人員針對零組件資料庫的使用上，主要分兩大部分：第 一部份是建立零組件結構表，以及儲存詳細規格資料如圖面資訊， 第二個部份則是維護/更新產品結構表資料，並且可即時查詢電子規 格訂單資訊，這兩個運作的流程可由圖 3-5 說明之。 圖 3-5 設計部門使用零組件資料庫之流程

零組件資料庫

設計部門 建立/更新訂單規格資料 或零組件結構表 結構表、OS 資 料、圖面資 訊…等 輸入圖面資訊 查詢訂單規格資料 或零組件結構表

3.3.3.2 生產部門 一些零組件生產管理上的基本資料需先建立完成，如各個零 組件的前置時間、期初庫存量、所對應之供應廠商…等，並且有 變動時需做維護更新的動作；另外生產部人員可藉由零組件資料 庫管理系統，查詢目前庫存狀況、預期收貨日期、發放訂單日期、 需生產數量…等與生產規劃有關的資訊。同樣的，生產部門對於 本研究中此零組件資料庫的運作流程，亦可由圖 3-6 更為清楚了 解，而對於生產部門極重要的日程表與產品採購清單，將在第三 章第六節再做更深入的討論。 圖 3-6 生產部門使用零組件資料庫之流程 3.3.3.3 決策部門 決策人員主要僅讀取零組件資料庫中的資訊，包含變更決策 以及查詢兩項動作，其中變更決策的部門，將針對需做變動的項 目再與生產部門、設計部門、採購部門以及營業部門共同討論後， 再由各部門去進行變更，決策部門不直接做儲存變更的動作，而 決策部門擁有全部的權限可登入此零組件管理庫，以監看所有流 程的運作。 3.4 電子訂單規格轉電子物料清單之轉換方法 3.4.1 訂單規格轉換模組 此訂單規格轉換程式的重點在於如何利用結構樹作自動轉換，即時 地將電子訂單規格轉成電子化的物料清單表，以期能即時地轉換成為產 品採購清單(PO)。

零組件資料庫

生產部門 輸入零組件基本資料 查詢零組件資訊 存貨記錄檔 e-BOM PO MRP 資訊 前置時間、庫 存資訊、收貨 日期…等

3.4.1.1 訂單規格轉換流程 完整的電子訂單規格轉換過程是從營業部門輸入電子訂單規 格資訊至電子物料清單(e-BOM)轉換完成，而所擬轉換成之電子 物料清單將包含的資訊如圖 3-7 所示，整個操作流程圖則如 3-8 所示。

+ +

圖 3-8 電子物料清單製成運作流程圖 電 子 訂 單 規 格 資 料 零組件資料庫 父子節點表 轉換後之父/ 子節點表 物 料 需 求 統 整 表 電子物料清單 線上電子訂單規格輸入系統 客戶 營業人員 設計部門

電子訂單規格轉換成電子物料清單模組

自動轉成 電子物料清單 圖 3-7 電子物料清單資料製成圖 告知需求 輸入電子 訂單規格 輸入圖面資訊 父節點表 子節點表 零組件庫存資訊、零組件結構表…等 轉換後之父節點表 物料需求統整表 客戶需求

3.4.1.2 訂單規格轉換方法 此轉換方法需運用零組件資料庫、電子訂單規格輸入系統兩 大部分共同完成，預定輸出完成的電子化物料清單，包含轉換過 後的父節點表、子節點表以及共用料統一整理的物料需求統整 表，此統整表僅顯示三個項目─Material、Quantity、Supplier，可 進一步依據電子訂單規格中的預定出貨日期，製成主生產排程 (MPS)，供各部門與各供應商即時地透過網路得知。而其轉換方 法主要包含以下三個步驟：

步驟一：完成 Parent 表，取出[product no, parent level no, parent branch no] 與資料庫中的[product no, level no, branch no] 比對，若存在則將 Sub-Quantity * Parents' Quantity，放入此節點的 P-Quantity 中，直 到所有的註記(mark)項目處理完畢。

步驟二：完成 Child 表，取出[product no, parent level no, parent branch no]與 資料庫中 parent 表中的[product no, level no, branch no] 比對，若存 在則將 Child 表中的 Sub-Quantity *Parents' P-Quantity(or Child's C-Quantity)，再放入此節點的 C-Quantity 中。

步驟三：電子訂單規格中的數量，則是記錄在 Parent 表中的最初一列中： [product no, level no, branch no, sub-quantity, parent level no, parent branch no, material name, mark] = [no, 1, 1, number, x, x, name, x]，在 此列中的 number 值、material name 由電子訂單規格輸入系統所填 入的資料決定，若有所更動時，則重複步驟一、步驟二，算出新的 P-Quantity 與 C-Quantity 數值。

步驟四：統計各個 material 所應生產或加工的數量─[material name, quantity, supplier]，其中 quantity 數值即是步驟二所計算出的 C-Quantity 數 值，再搭配電子訂單規格系統中所輸入的出貨日期，製成主生產排 程。 3.4.1.3 訂單規格轉換方法簡例 在此列舉一簡單範例補充說明整個轉換方法的主要前三個步 驟，另外，在做整個轉換之前，需將各個零組件的結構表依照第 3.3.2 節所介紹的儲存方式，先存入零組件資料庫中。例如一電子 訂單規格中要求下方此一產品，其零組件結構如圖 3-9 所示。

圖 3-9 範例之零組件結構圖

而依照之前所詳述的儲存定義，可知上圖 3-9 中包含 4 個父 節點，分別為 Level1 之 C001-001、Level2 之 C1、Level3 之 C2， 其餘則為子節點共 5 個，就第三章第三節所提到的儲存方式可將 其儲存成兩個表，分別為 parent table 以及 child table，此範例之 儲存表如表 3-7 以及表 3-8 所示。 表 3-7 父節點儲存表 表 3-8 子節點儲存表 Product No. Level No. Branch No. Sub-Quantity Parent Level No. Parent Branch No. Material Name 1 3 2 3 2 1 C3 1 4 1 1 3 1 C4 1 4 2 2 3 1 C3 1 4 3 1 3 3 C4 1 4 4 2 3 3 C3 Product No. Level No. Branch No. Sub-Quantity Parent Level No. Parent Branch No. Material Name Ｍark 1 1 1 1 x X C001-001 x 1 2 1 3 1 1 C1 F 1 3 1 2 2 1 C2 T 1 3 3 1 1 1 C2 F

表 3-7 與表 3-8 的儲存順序是由左而右、由上而下，其中本研究暫將 此一產品編號設為 1，此部份可就各公司需求自行命名，並且將 root 設定 在 level 1 中，每一層自左而右由 1 開始編號，即為各節點的 branch no，而 在父節點中的最後一欄即是指出此節點的上一層父節點，是否是 root，我 們可由電子訂單得知第一列的 Sub-Quantity 值。 接著此轉換程式則是需運用圖 3-8 以及電子訂單規格中的數量與名稱 來完成電子物料清單，最後得到兩個轉換後的父子節點表以及 Material、 Quantity、Supplier 三個項目的物料需求統整表，再依據電子訂單規格中的 出貨日期，製成主生產排程(MPS)，此範例的步驟流程如下所述。 在上述轉換步驟的步驟一當中，首先需依照電子訂單規格系統中所填 入的零件數量與名稱，完成另一轉換後 Parent 表，取出[product no, parent level no, parent branch no]與資料庫中的[product no, level no, branch no] 比 對，若存在則將 Sub-Quantity * Parents' P-Quantity，放入此節點的 P-Quantity 中，直到所有的 mark 項皆為 F 為止，即表示所有節點都已追溯至最上層 Level1，其中 root 的 P-Quantity 等於 Sub-Quantity，相當於電子訂單規格所 填之數量。若目前為 C001-001 此一零件的需求數量為 1，則 Parent 表將自 動轉換成如表 3-9 所示，主要不同之處為增加一 P-Quantity 欄位。 表 3-9 轉換後的父節點表 Product No. Level No. Branch No. Sub-Quantity Parent Level No. Parent Branch No. Material Name Mark P-Quantity 1 1 1 1 x x C001-001 x 1 1 2 1 3 1 1 C1 F 3*1 1 3 1 2 2 1 C2 T 2*3 1 3 3 1 1 1 C2 F 1*1 步驟二則是依據已完成的 parent 轉換表，進一步轉換 child 表，首先取出 child 表中的[product no, parent level no, parent branch no]與資料庫中 parent 表中的[product no, level no, branch no] 比對，若存在則將 child 表中的 Sub-Quantity * parent's P-Quantity，放入此節點的 C-Quantity 中，如表 3-10 所示。

表 3-10 轉換後的子節點表 Product No. Level No. Loc No. Sub-Quantity Parent Level No. Parent Loc No. Material Name C-Quantity 1 3 2 3 2 1 C3 3*3 1 4 1 1 3 1 C4 6*1 1 4 2 2 3 1 C3 6*2 1 4 3 1 3 3 C4 1*1 1 4 4 2 3 3 C3 1*2 接著在步驟三中，依據電子訂單中下單的數量，是記錄在 parent 表中的最 上方的一列中：[product no, level no, branch no, sub-quantity, parent level no, parent branch no, material name, mark] = [編號, 1, 1, 數量, x, x, 產品名稱, x]，此列中的 number 值、material name 由電子訂單決定，若有所更動時， 則可重複步驟一、步驟二，算出新的 C-Quantity 值。

最後即可統計各個 material 所應生產或加工的數量─[material name, quantity, supplier]，其中 quantity 數值即 P-Quantity 與 C-Quantity 的加總數 值，如表 3-11 所示，可再搭配電子訂單中的日期，製成主生產排程，

表 3-11 物料需求統整表

Material Quantity Supplier

C1 3 S1

C2 7 S2

C3 23 S3

3.5 線上顧客需求管理模組

除了擴展以往的 Customer Requirement Management (CRM)系統至網路平 台之外，本研究針對客製化程度高的產業─電梯產業，充分掌握顧客需求確保 最終產品能符合其需要，亦是不可或缺的成功關鍵因素。而一般需求管理可分 為「需求的取得」及「需求的維護」兩個過程，通常需求的取得主要是蒐集顧 客的聲音，常以訪談或是市場調查等方式；而需求的維護則是包含了需求追蹤 及需求變更兩個部份。 本研究所設計之線上顧客需求管理模組主要包括了三項功能：顧客需求之 取得、顧客需求之查詢、顧客需求之變更。顧客需求之取得部份本研究主要是 將公司各部門所獲得的資訊紀錄於此系統中，以取得更多的客製化訊息；另外 在 Order Specification 輸入系統中的註記(Remark)部分，亦可轉出顯示於此系統 中。而顧客需求之查詢部分，本研究是依照 Order specification 的 JOB No 來做 查詢，主要是查詢已輸入的需求項目並且定期追蹤顧客的需求。最後顧客需求 之變更部分，是針對目前需求管理系統分類中尚缺乏的項目，做新增項目的動 作，以及當原本輸入的顧客需求有變動時，做即時地修改更新，且供各部門參 考使資訊能夠充分地分享流通，上述三項功能可由下表 3-12 清楚了解，而整體 流程運作如圖 3-10 所示。 表 3-12 顧客需求管理模組三大功能 使用/存取部門 資訊存取項目 顧客需求之取得 設計部門、決策者、 其他營業部門 顧客反應之即時需求、電子訂單規 格中的註記(Remark)部分 顧客需求之查詢 設計部門、決策者、 其他營業部門 已輸入的顧客特殊需求項目 顧客需求之變更 設計部門、決策者 原輸入顧客需求有變動的部分、新 增刪減需求項目

顧客需求註記 (Remark)部分 輸入顧客特殊需求 顧客需求之取得 輸入顧客特殊需求 查詢顧客特殊需求 查詢顧客特殊需求 查詢顧客特殊需求 圖 3-10 顧客需求模組整體流程示意圖 在本研究中所針對的電梯產業，最初資訊是取出 Order Specification 輸入 系統中所輸入的註記(Remark)部分，而其類別項目再由設計部門與決策部門 共同商討需做增減變更之項目，而於電梯產業中常見的顧客特殊需求如下表 3-13 所示之範例。 表 3-13 電梯產業常見特殊需求註記舉例 項目 內容 車廂門板材質 鋼板貼美耐板+鋁製銀白色收邊飾條 車廂側壁壁板材質 鋼板貼美耐板+鋁製銀白色收邊飾條 車廂踢腳板材質 髮紋不銹鋼板 車廂地板材質 25mm 後大理石 殘障專用運轉樣式 38mmSUS-HL 圓管扶手一支。 適用號機：D1 號機。 殘障專用主 COB 採用 COB-T13S。 車廂後側壁設半身玻璃明鏡一面…等。 全號機車相內 CCTV 設置 安裝位置、CCTV 本體、CCTV 顯示器 設計部門 營業部門 線上電子訂單規格輸入系統

線上顧客需求管理模組

其他部門 決策部門

3.6 電子物料清單轉產品採購清單之轉換方法 在營業人員輸入電子訂單規格資料後，透過一連串的輸入與轉換可得到一 如表 3-11 之物料統整表，但尚需考慮目前的庫存量與預計收貨數量，故需將此 統整表作修正，使公司內各部門與供應商能夠經由此線上系統，即時地獲得所 需生產的零組件數量與名稱，以及所需下單的日期，再以整備時間推估取得各 零組件的時間，最後加上完成品組裝時間，可大幅提升生產過程的效率。 此部份的 MRP 內存資料結構設計是以各個產品的結構樹為單位，最終再 做合併的動作，並且根據零組件資料庫中資訊，使各供應商能透過此平台即時 得知，故在此訂單發放時間即為營業人員輸入電子訂單規格資料的時間，可大 幅提升整個生產流程的效率。 而在進行 MRP 之前需轉換出其所需的輸入資料，可分為以下三項： 1. 最終產品項目的預測需求量：一般即所謂的主生產排程，指出一個工 廠在何時該生產什麼產品？以及生產多少？此部份可由電子訂單規格 系統的輸入得知。 2. 物料清單：包含了一組為生產一個單位最終產品所必須之半成品、零 件與原物料等相關資訊，通常可用表列式或結構樹來顯示其關係，而 本研究中此部分零組件結構是由設計部門輸入之，而電子化物料清單 則是依據電子訂單規格系統的輸入再動態產生。

3. 存貨記錄檔(Inventory Record File)：依照時間記錄每一存貨項目的狀態 資料，包含預計庫存、預期訂單收貨以及現有庫存量等。本研究中此 部分的資料存於零組件資料庫中，並且動態更新。 4. 而在 MRP 的輸出資訊，一般包含計畫訂單、訂單開立、變更通知、 績效管制報告、計畫報告、例外報告等。本研究中可透過線上時間軸資訊， 即時得知關於生產計畫之資訊，即產品採購清單，使正確的零組件或產品 能以正確的數量、正確的時間提供給需要的客戶，減低未能準時出貨的風 險。 此部分運作的資訊流程可由圖 3-11 得知，而整體運作流程圖則如圖 3-12 所示。

產品採購清單

Week1(5/8) Week2(5/15) Week3(5/22) Time /Item CT OT CT OT CT OT 5/9 5/11 5/20 TW5555 20 TW5514 50 TW5555 18 C1 …. …. Total 100 Total 80 圖 3-11 MRP 轉換資料流示意圖 主生產排程 物料清單 存貨記錄檔

電子物料清單轉換成產品採購清單模

電子物料清單 零組件庫存資訊

零組件資料庫

OS 中的註記部份

圖 3-12 產品採購清單製成運作流程圖 線上電子訂單規格輸入系統 客戶 _告知需求 營業人員 設計部門 輸入電子 訂單規格 輸入圖面資訊

電子訂單規格轉換成

電子物料清單模組

電子物料清單 主生產排程 存貨記錄檔 父節點表 子節點表

電子物料清單轉換成產品採購清單模組

其他零組件資料 產品採購清單

第四章 實作結果

4.1 實作案例 接著，將以一個電梯產業的實際案例為例子，說明如何利用此電子訂單自 動處理系統，提高生產計畫效率，使下游各級供應商、公司內部各部門都能透 過此電子訂單自動處理系統，即時且準確地掌握所需要的資訊。 在此我們使用 ASP.NET 2.0 以及 SQL Server 2000 來實作此一系統，並利 用之前第三章第四節以及第三張第六節所提出的轉換方法，提高此一系統的效 率。而實作結果之首頁如下圖 4-1 所示，主要分為五大功能： (1) 線上電子訂單規格輸入/查詢子系統 (2) 零組件資料管理 (3) 電子訂單規格轉換成電子物料清單模組 (4) 顧客需求管理模組 (5) 電子物料清單轉換成產品採購清單模組 圖 4-1 電子訂單自動處理系統功能顯示圖 4.1.1 線上電子訂單規格查詢輸入系統 此一案例我們架設訂單編號(Job Number)為 TW-0716，並且假設顧 客已下單，而需由營業人員以及設計部門人員使用此線上電子訂單規格 查詢輸入系統，如圖 4-1 中所標示(1)的部分。

分別由營業人員使用[新增]功能來輸入顧客所需要的電子訂單規 格，而由設計部門人員使用[information System]功能來輸入顧客電子訂 單中有關圖面的資訊，並且此功能需有權限方能登入做輸入的動作。因 此，第一個步驟則是輸入帳號與密碼，登入使用此電子訂單規格查詢輸 入，如下圖 4-2 所示。 圖 4-2 使用者登入機制圖 當營業人員登入之後將進入[新增]功能來輸入電子訂單規格，總共有八 頁，包含的主要項目如之前表 3-2 所列，而此實際範例的輸入介面第一頁如 下圖 4-3 所示，除了訂單編號、主要用途、出貨安裝完成日…等，主要包含 了 MAIN SPEC.的輸入，並在下方標註其版本編號，以便有變動時，可依版 本順序作正確地修正與查詢動作。

圖 4-3 電子訂單規格新增介面圖 另外在此一電子訂單規格的輸入部分，本研究也設計了許多的連動控 制，以避免當營業人員在輸入顧客規格時，會發生許多在電梯產業上必須避 免的錯誤，如此處的全品質抵工日可選取 Yes 或是 No，如下圖 4-4，而當全 品質抵工日若是選取 Yes 時，將只顯示出一個日期可供輸入。 圖 4-4 連動控制選項圖

另外當全品質抵工日若選取 No 時，則介面將顯示如下圖 4-5，全品質抵 工日一列會自動去除，改為輸入乘場出貨日以及乘場以外出貨日。

圖 4-5 連動控制顯示圖

此電子訂單規格輸入系統總共有八頁的輸入，在此僅取第二頁以及第三 頁 顯 示 說 明 ， 包 含 ELECTRIC POWER SPEC. 、 APPLICATION AND STRUCTUAL SPEC.、CONTROL SPEC. AND OPTION 這幾個項目，如下圖 4-6 以及下圖 4-7 所顯示。

圖 4-6 電子訂單規格第二頁顯示圖

為了加速輸入速度，在此本研究額外製作了特定語句選取的功能，使常 輸入的語句項目能透過勾選的方式，降低輸入時打字的錯誤，同時縮短了輸 入所需耗費的時間，舉例如下圖 4-8。 圖 4-8 常用輸入選取示意圖 另外設計部門人員登入之後可進入[Information System]功能來輸入電子 訂單規格中的圖面資訊，這部份總共有二頁，並且包含上傳圖片的功能，如 下圖 4-9 顯示登入以及圖 4-10 顯示其上傳圖片之功能 圖 4-9 圖面資訊輸入介面圖

圖 4-10 圖面資訊上傳檔案示意圖 當營業人員與設計部門人員皆輸入資訊之後，即可透過 [OS 查詢]功能 來查詢剛才輸入完畢的 TW-0716 訂單的規格資訊，包括電子訂單規格資訊以 及圖面資訊，並且有標明版本編號，如下圖 4-11 所示。 圖 4-11 電子訂單規格查詢說明圖 4.1.2 零組件資料庫管理 此部份主要供使用者查詢目前零組件的庫存狀況、預計收貨日期與 數量、前置時間…等資訊，在此我們試搜尋 C1、C2、C3 此三項 TW-0716 中所需要的零組件狀況，C1 為此產品的父節點，而 C2、C3 為此產品的

子節點，其查詢結果分別如下圖 4-12、圖 4-13 以及圖 4-14 所示。

圖 4-12 零組件 C1 查詢結果顯示圖

圖 4-14 零組件 C3 查詢結果顯示圖 4.1.3 電子訂單規格轉換成電子物料清單 透過[e-Order to e-BOM]此功能，能將原本存於零組件中的電子訂單 規格資訊，轉換製成電子物料清單，其中包括轉換後父節點表、轉換後 子節點表以及物料需求統整表三份資料，由於本範例 TW-0716，包含三 大主要 product，故會自動取出作轉換後顯示，應輸出顯示的三種表單， 如下圖 4-15 所顯示。 圖 4-15 電子物料清單顯示圖

4.1.5 顧客需求管理模組 本研究中的顧客需求管理模組，可輸入電子訂單規格編號再加以搜 尋出電子訂單規格中的註記部份，也可再做新增、刪除以及修改的動作 如圖 4-16 所示。 圖 4-16 顧客特殊需求查詢示意圖 4.1.6 電子物料清單轉換成產品採購清單 在電子物料清單轉成產品採購清單的模組中，本研究分為兩個部份 顯示，分別為[供應商查詢]以及[e-BOM to m-BOM]兩個部份，其中供應 商查詢是讓下游各級供應商登入，顯示出其所對應零組件的時軸表，可 清楚得知顧客下單日期、交期、所需生產的零組件種類及數量，且此時 軸表會即時更新，讓下游各級供應廠商可以透過網際網路在第一時間得 知生產計畫資訊，如下圖 4-17 以及圖 4-18 所示。

圖 4-17 供應商 s1 對應顯示圖

圖 4-18 供應商 s2 對應顯示圖

另外，在[e-BOM to m-BOM]的部份，主要是供公司內部部門觀看各 個零組件的生產計畫資訊，即時得知計畫訂單收貨數量以及日期、計畫 訂單發放數量以及日期…等資訊，如下圖 4-19 所示。

圖 4-19 生產計畫資訊顯示圖 4.2 討論與分析 本研究所開發之電子訂單自動處理系統，可實際解決在本文一開始所提到 的三大問題： 1、一般電子訂單系統不能直接連結 BTC 的運作：此部分已由電子訂單規格轉 換成電子物料清單模組解決，可在電子訂單規格輸入之後，自動取出相對 應的零組件，轉換成電子物料清單，如第四章第一節所顯示的圖 4-15。 2、傳統電子訂單系統並未讓訂單和生產工單有直接關聯：此部分本研究的電 子物料清單轉換成產品採購清單模組，可讓生產工單與電子訂單規格之間 有緊密的結合，電子物料清單可透過此一模組進一步地製成產品採購清 單，清楚地顯示何時需生產哪種零組件、所需要的數量為何、所對應的供 應廠商是哪些…等資訊，如第四章第一節所顯示的圖 4-17、圖 4-18 以及 圖 4-19。 3、大部分的電子訂單系統少有提供支援客製化的功能：本研究中所提供的顧 客需求管理系統可解決這樣的問題，除了自動將電子訂單規格中註記的部 份顯示出來，同時公司內部其他部門也都有權限可做新增的動作，使資訊 能透明地流通，最後再由決策部門或設計部門審定這些特殊顧客需求是否