供应链管理讲解

供應鏈管理期末報告資管一 何承澤主題：CPFRI. 簡介協同規劃、預測、補貨(CPFR, Collaborative Planning Forecasting Replenishment)系統的建立可以公式化買賣方的交易合夥關係。用此模式買賣方可以共同訂立合作計畫、協商預測並且利用補貨的效益是否提升及例外事件的處理來檢視合作績效。CPFR的建立是以快速顧客回應(ECR, Efficient Consumer Response)1為基礎包含了供應商管理存貨(VMI, Vender-Managed Inventory)、聯合存貨管理(JMI, Joint-Managed Inventory)、連續補貨(CRP, Continuous Replenishment)和貨物分類管理(CM, Category Management)1。全球商務協會(GCI, Global Commerce Initiative)將CPFR視為一個促進商業活動整合的角色。事實上，CPFR是ECR的一個延伸，所以說合作夥伴在之前用於ECR系統之輸入都可以用在CPFR之上。再了解CPFR之前有幾項的指標原則是採用CPFR時需要先注意的，再此我們先檢視之4：l CPFR使得交易夥伴間的處理程序更貼近甚至以顧客需求為準，以此達到價值鏈的成功。l 交易夥伴間在存貨的管理以及契約的訂立上都以一份單一且共享的需求預測為準，利用這些資訊可以在價值鏈上得到相當完善的計畫l 交易夥伴間利用單一且共享的需求預測來共同分擔風險 (Risk Pooling)並減少採購、補貨活動間的諸多限制從VMI以及JMI實行的經驗來看，可以發現：不可能找到一個單一的企業處理程序滿足所有合作夥伴的需求或符合所有合作夥伴所面臨的狀況。合作夥伴依據其所使用的策略或投資方式都有不一樣的企業競爭力。對於資訊的攫取他們也有不一樣的管道及來源，甚至市場的觀點也不一樣。CPFR被架構成一系列劇本的集合或者說CPFR是合作夥伴間的另一種選擇，這些劇本讓企業可以依據合作夥伴間關鍵競爭力之所在來決定誰可以在流程中扮演仲裁的角色。每一組的交易夥伴都可以利用產品的屬性、季節、交易步驟的層級來選擇適合它們之間最佳的協同合作劇本。根據剛剛所提，買賣方對於市場具有不同的觀點，這影響到需求預測的建立，如下面這個例子所示：零售商檢視POS(Point-of-Sales)資料並且與顧客互動來推論顧客的購買行為；另外零售商可以直接觀察供應商提供貨物的範圍、種類以及各種產品的行銷計畫來作為其預測的依據。供應商也會觀察零售商購買物品的種類以及採購計畫甚至直接取得顧客活動資料、供貨的延遲、零售商退貨單、POS(如果有共享的化)等資料來做預測。所以，可以得知，供應商和零售商在做預測時會所用的資料和觀點可能非常不一致，如果能夠將這些資訊全部匯總起來，將可以有效的提升預測的精準度。這個程序最後的結果就是一張單一且共享的需求預測，這包含了訂單預測及銷售預測。訂單預測可以明顯的揭露出交易夥伴之間的需求狀況(也就是說零售商會跟供應商買多少東西、買什麼東西)；銷售預測則顯示出客戶對於貨品的需求。單一需求共享計畫的訂定成為內部計畫活動的一個基準，也就是說，這促使了價值鏈的整合。因為資料的交換提供預測的精準度，使得加入CPFR的預測結果可以高過許多成熟且複雜的預測技巧，這是CPFR所帶來的主要效益。II. CPFR運行劇本上述的CPFR的幾項原則根深蒂固的影響了CPFR的實作模型。在這個部分我們將揭示供應鏈的九項主要處理流程以及這些步驟的輸出輸入。劇本A、B、C、D顯示了程序的變異性，這些變異性依據競爭力、資源和系統而來，主要決定各個交易夥伴在CPFR運行時所要扮演的角色表一每種劇本在CPFR各程序所扮演仲裁的角色劇本銷售預測訂單預測產生訂單劇本A買方買方買方劇本B買方賣方賣方劇本C買方買方賣方劇本D賣方賣方賣方有一點很重要的是，在每一個劇本中，不管是買賣方都要輸入資料以供預測，不過某一方有最後的決議權。在劇本A中，是一個買方仲裁的交易關係，在這裡，買方控制了銷售預測、訂單預測和訂單的產生。劇本B、C和D將某部分的權利交給賣方，就像是使用供應商管理存貨(VMI)一樣。在劇本B中，買方提供需求預測，賣方將心力放在訂單的產生上；在劇本C中，買方仲裁銷售預測和訂單預測；在劇本D中，賣方負責了所有的流程。各種不同劇本運行時的差異我們會在待會CPFR詳細步驟的時候作一個解釋。如下圖一所示，CPFR可以分為九個步驟，但是這九個步驟依據功能又可以群組為三個部分，分別是計畫、預測、補貨。步驟一、二為計畫的部分，負責流程的初始化的動作，步驟三到八是預測的部分，為CPFR最核心的部分；步驟九是最後一個步驟，就是在預測沒有例外事件和差異時就可以進行補貨。圖中顏色標出在不同時期何者為仲裁的角色，紅色代表買方仲裁，深藍色代表賣方仲裁。雙分一起進行的活動用黃色表示。圖一CPFR九大步驟流程III. 詳細執行步驟步驟 1 ：建立協同關係在步驟1中，買方和賣方建立建立協同關係的方針和準則。所謂協同準備工作(Collaboration Arrangement)訂立了每一個交易夥伴所期望達成的目標以及達成這些目標所要採取的動作或是需要的資源。為了要完成這項準備工作，買方和賣方共同完成一套一般性的企業處理準則，這包含了對於合作目標通盤的了解、機密的保護、哪些資料需要被共享以及資源的授權，這些參數可以在CPFR程序執行的時候被正確的使用在系統中。步驟1：輸出步驟一執行之後的輸出結果是一份公開的協同計畫(Collaborative Planning)，協同計畫是由交易夥伴所共同制定的一份營運藍圖，目的是為了開始協同關係的準備工作或根據CPFR重新定義重新定義協同關係。文件用了許多實用的術語定義程序，並指出各交易夥伴在系統中所需要扮演的腳色以及執行效能如何被測度。除此之外，它也明確指出系統中各組織是否就緒且是否能從合作關係中找出將利益最大化的利基。這份藍圖也可以紀錄了追求更高效能、是否有意願做知識交換以及風險共擔等落實之後的結果。步驟1：處理程序以及資料的輸入步驟一會詢問交易夥伴幾個關係的輸入資料，並且將之整合、統整為一個架構以利預測的進行，幾個關鍵資料的輸入如圖二所示：圖二步驟一處理程序1. 制定CPFR準備作業及敘述：將任務包含知識的共享、合作的目標、機密的保存和資源的授權等敘述作成文件。2. 決定CPFR的目標及目的：建立CPFR的目標和目的這包含了機會的定義、效能測度的意義以及對於各交易夥伴間商業活動的影響因子、商業流程還有例外事件的尺度。3. 討論競爭力、資源和系統之間的關係：決定各個決策夥伴間的競爭力、資源及系統還有它們在處理CPFR流程時所能需要的能力。4. 定義協同合作點(Collaboration Point)以及所要負責的企業功能：將協同合作點對應到交易夥伴的競爭力中並且建立企業功能的責任分工。5. 決定哪些資訊需要被共享：決定哪些資訊可以支援流程處理，這些資訊就應該被分享出來，另外，也要定出多久要更新一次資料的時間、預測的方法有哪些、資料的元素和結構的以利交易夥伴剖析。6. 之前合作所得到的經驗：收集有關之前合作所得的結果和經驗。7. 建立服務和訂單的委託關係：這包含了凍結訂單期間(預測變成真正訂單的前置時間)的定義8. 決定CPFR程序所會使用的資源以及相關委派資料：決定相關人員、時間分配；將資源分配到各流程9. 決定如何處理CPFR交易夥伴間的衝突：建立衝突的解決規則10. 決定檢視協同準備計畫的週期：設計一個效度測量機制來衡量協同關係，並適當的修改協同準備計畫11. 發放協同準備計畫：將協同準備計畫交付給各個執行單元作為其作業的指引，並且在需要的時候修改這些計畫。步驟2：建立共同營運計畫在CPFR第二個步驟中，買賣雙方交換各自的營運策略和商業計畫以此合作產生初一套共同的營運計畫。在供應商/零售商的劇本中，交易夥伴應該以CM(分類管理, Category Management)的原則來產生夥伴間的策略和定義分類的規則、目標、戰術。另外，所有的劇本中都要建立好各個協同合作品項的管理檔案(包括最小訂購量、前置時間、訂購間隔等) 。聯合營運計畫的建立牽涉到雙方資訊的整合所以可以有效提升了整體預測的品質，再某方面也落實了供應練間的連結性。步驟2：輸出步驟2的輸出結果是一個交易夥伴雙方都認可的共同營運計畫，這份計畫很清楚的定出品項的管理上的任務、策略和戰術。在協同合作一開始訂立共同營運計畫可以有效的減少例外事件和交易夥伴間交涉的次數。步驟2：執行程序以及資料的輸入步驟2主要目的在取得買賣雙方對於交易品項在策略上和戰術上的共識。主要輸入的資料如下圖三所示：圖三步驟二處理程序以及資料的輸入I. 訂立合作策略：包含週期性商業目標、測略、目的的分享；產生某特定期間產品的合作策略II. 建立產品分類角色(Category Roles)、目標和目的：針對某特定產品分類討論其產品分類角色、目標和目的III. 協議出共同的產品分類以及促銷計畫：指出或訂立適當的產品分類策略、區域性或全域性的促銷策略和定價計畫。IV. 建立品項管理檔案：利用品項檔案的建立支援戰術活動，品項管理檔案應該包含最小訂購量、前置時間、訂單週期、訂單凍結時間和安全庫存)V. 建立營運計畫：以先前交易夥伴間所共享的資訊建立個別的營運計畫VI. 協同完成共同營運計畫：比較個別營運計畫的差異，並且完成共同營運計畫步驟3：建立銷售預測在步驟3利用消費者的資料產生銷售預測，這份銷售預測可以支援上一階段所產生的共同營運計畫。消費資料因為產品、產業、交易夥伴的不同會產生差異。消費資料的來源可能是POS資料、零售商配銷中心退貨資料或供應商的消費資料等。另外還要注意很重要一點就是偶發性事件資訊的蒐集。在劇本A、B、C中，這部分由買方進行。在劇本D中，這部分由賣方負責。步驟3：輸出這個步驟的輸出是由某一方所產生的銷售預測，這份預測會交給另外一方以利協同作業。並且以此銷售預測為基礎來產生訂單預測。步驟3：執行程序和資料的輸入步驟3主要的輸入元素如下圖四所示：圖四步驟三處理程序以及資料的輸入I. 分析目前的共同營運計畫：分析在目前共同營運計畫中未來可能會影響銷售的重要干擾因子II. 分析偶發資訊：利用歷史性的事件資料、事件影響銷售的結果來分析可能影響銷售的偶發事件，例如百分之十五的降價可能提高百分之二十的銷售量。III. 收集並分析消費資訊，這些資訊可能來自POS、倉庫的退貨單、生產所消耗的原料；利用這些資料可以產生銷售預測並且可以進一步產生訂單預測。IV. 訂立計畫好的事件：這些事件會影響產品的銷售量，例如零售商營業時間、促銷活動、新產品的介紹等等，利用這些資料可以進一步整合成一份共享事件日誌(shared-event calendar)V. 更新共享事件日誌：將交易夥伴所訂立的商業世界排列好，產生一份較一般化的計畫，並且讓雙方都可以同意這一份短期計畫。VI. 收集例外事件決議資料：收集前期銷售預測時所產生的例外事件決議資料(也就是下個步驟要解決銷售預測所產生的例外事件所產生的決議事項)VII. 產生銷售預測步驟4：識別銷售預測的異常狀況步驟4會找出那些無法套用在銷售預測的例外品項，例外品項標準的訂立在建立協同準備計畫階段皆已經定義好了。步驟4：輸出步驟4的輸出是一系列的例外品項清單，這個清單會在步驟5中被用到步驟4：處理程序以及資料輸入步驟4幾個重要資料的輸入如下圖五所示：圖五步驟四處理程序以及資料的輸入I. 取得例外事件標準：取得銷售預測例外事件標準，利用這些標準來判定品項是否為例外事件。(這個標準在協同準備計畫階段就已定義完成)II. 改變和更新的識別：檢查買賣方是否已經改變或者是更新了聯合營運計畫III. 取得銷售預測的限制：利用訂單預測的過程取得銷售預測限制，銷售預測限制主要來自於賣方在比較過訂單預測後找出銷售預測在某些方面的限制可能會影響到未來的需求分析。IV. 算出品項數值是否符合例外事件標準：算出品項的數值和剛剛所取得的例外事件標準決定該品項是否為例外事件，例如：某貨品X銷售佔存貨的比例為83%，而例外事件的標準是90%)V. 識別例外品項：找出例外品項，並作成清單步驟5：解決異常項目步驟五牽涉到解決銷售預測的例外品項，可以檢視共享資料、使用電子郵件、電話、開會等方式來解決，並且將解決後的結果反映到銷售預測上。步驟5：輸出交易夥伴之間的協同交涉解決了品項例外的問題，調整過後結果也會反映到銷售預測上。另外，在CPFR中更加重視及時決策的訂立，盡量縮短交涉的時間可以得到較佳的訂單。步驟5：處理程序以及資料輸入步驟5是從步驟4所得到的例外品項清單為主要輸入，其它輸入項目如下圖六所示：圖六步驟五處理程序以及資料的輸入I. 取得例外品項清單和決策支援資料：從買賣雙方取得一些可以支援決策的資料，這些資料在協同準備計畫中已經定義好的，包含時間序列的資料(例如：歷史銷售紀錄)以及非時間序列的資料(如：存貨百分比)。II. 選擇例外品項的標準和被定義為例外品項中所算出的值 (所有在商店中存貨小於90%的品項)III. 研究例外事件：利用共享事件日誌(shared-event calendar)和支援決策資料作例外事件的研究IV. 提高協同層級：如果研究結果不能產生一個令人滿意的改變，則需要提高協同層級，例如本來使用電話協商可能要變成開會面對面協商V. 將改變的結果反映到銷售預測中步驟6：建立訂單預測依據銷售預測、影響訂單的因果資訊和存貨策略來產生未來特定時間特定品項和地點的訂單預測，短期預測可用下單，長期部分可用來作規劃，由根據不同劇本而裁定的仲裁者決定最後的訂單預測。步驟6：輸出步驟六的輸出為一份訂單預測，這份預測可以讓賣方在安全存貨降低之前就可以事先配置好生產貨品的數量，也可以增加買方對於貨品的供貨水準的信心。步驟6：流程處理以及資料輸入下圖七為步驟六的輸入項目：圖七步驟六處理程序以及資料的輸入I. 之前步驟產生的銷售預測II V. 其他預測所需要的資料，包含POS資料、影響銷售預測的重要因子(例如配銷商配銷中心的改變、新產品問世、商店的開店時間)，存貨策略以及目前存貨的狀態(包括在庫存的、訂購中的、運送中的)VI VII. 分析歷史需求、配銷資料和目前容量限制(包含供應商倉庫大小、運輸量)VIII. 取得額外品項的管理檔案：這份資料再建立共同營運計畫階段就已經定義好了，包含最低訂購量、凍結時間、前置時間、訂購間隔、安全存貨等資訊。IX. 收集訂單資訊：收集訂單資訊並分析交易成功的訂單以及回饋的資料作為訂單預測最主要的輸入資料。X. 從上一回合的步驟八中取得例外品項的解決方式，並將之加入訂單預測的參考中XI. 產生訂單預測步驟7：識別訂單預測例外品項識別訂單預測的異常狀態，找出訂單預測限制外的異常品項步驟7：輸出步驟7的結果為一訂單預測例外品項之清單步驟7：流程處理以及資料輸入步驟七的輸入如下圖八所示：圖八步驟七處理程序以及資料的輸入I. 取得例外事件標準：取得訂單預測例外事件標準，利用這些標準來判定品項是否為例外事件。(這個標準在協同準備計畫階段就已定義完成)II. 改變和更新的識別：檢查買賣方是否已經改變或者是更新了聯合營運計畫III. 取得訂單預測的限制：利用訂單預測的過程取得訂單預測限制，訂單預測限制主要來自於賣方在比較過訂單預測後找出銷售預測在某些方面的限制可能會影響到未來的需求分析。IV. 算出品項數值是否符合例外事件標準：算出品項的數值和剛剛所取得的例外事件標準決定該品項是否為例外事件，例如：某貨品X銷售佔存貨的比例為83%，而例外事件的標準是90%)V. 識別例外品項：找出例外品項，並作成清單步驟8：協同解決異常項目調查訂單預測異常的程序，以透過分享資料、電子郵件、電話交談、會議等方式，說明對訂單預測結果的改變。步驟8：輸出交易夥伴之間的協同交涉解決了品項例外的問題，調整過後結果也會反映到訂單預測上。另外，在CPFR中更加重視及時決策的訂立，盡量縮短交涉的時間可以得到較佳的訂單。步驟8：流程處理以及資料輸入步驟8使用了步驟7的例外品項清單，其他的輸入項目如下所示：圖九步驟八處理程序以及資料的輸入I. 取得例外品項清單和決策支援資料：從買賣雙方取得一些可以支援決策的資料，這些資料在協同準備計畫中已經定義好的，包含時間序列的資料(例如：歷史銷售紀錄)以及非時間序列的資料(如：存貨百分比)。II. 選擇例外品項的標準和被定義為例外品項中所算出的值 (所有在商店中存貨小於90%的品項)III. 研究例外事件：利用共享事件日誌(shared-event calendar)和支援決策資料作例外事件的研究IV. 提高協同層級：如果研究結果不能產生一個令人滿意的改變，則需要提高協同層級，例如本來使用電話協商可能要變成開會面對面協商V. 將改變的結果反映到訂單預測中步驟9：產生訂單轉換訂單預測成為實際的訂單。不管是買方、賣方都可以依據競爭力、系統和資源執行這個步驟。不管是誰建立了訂單，這份訂單都將反應預測結果。步驟9：輸出步驟9的輸出就是將凍結期間的訂單預測轉換成為訂單。步驟9：流程處理以及資料輸入步驟9的資料輸入如下所示：圖十步驟九處理程序以及資料的輸入I. 取得凍結預測：根據協同準備計畫所訂立的補貨前置時間取得凍結預測II. 部署凍結預測：將凍結預測作為訂單產生的依據III. 產生訂單IV. 通知其他交易夥伴：是賣方產生訂單，買方也必須要得到訂單產生的通知，不管是哪一方產生訂單都必須將訂單通知送給對方。IV. 簡單的協同合作範例1. 劇本在這裡我們假設有一個零售商ABC公司和一個製造商XYZ公司。兩家公司想要使用CPFR來做協同規劃預測補貨的工作。2. 制定協同準備工作(Develop Collaborative Arrangement)ABC零售商和XYZ製造商在供應鏈上使用CPFR來增加兩間公司在物流上的整合。主要目標放在增進相互的效益並且讓顧客的滿意度在動態資訊分享的機制下可以達到最高。在此前提下，它們定立了幾個成功目標：減少缺貨量、提高銷售量以及減少交易成本、增加資本利用率並落實供應鏈夥伴間的合作關係。經過雙方協商後，成功的指標量化後定立如下： 零售商庫存率(retail in-stock)必須低於96% 每年必須有六次的存貨週轉 預測的錯誤率必須在15%以下訂立成功目標之後，開始決定CPFR運行的劇本，根據ABC零售商和XYZ製造商在雙方的競爭力、資源以及系統都因素的評估之下，決定使用劇本B最為這次協同合作的方式，也就是說ABC公司必須要仲裁銷售預測；XYZ公司必須負責訂單的預測和訂單的產生，這有點像是供應商存貨管理(VMI)的方式。3. 建立共同營運計畫共同營運計畫的建立牽涉到銷售預測、訂單預測等參數的建立，經過ABC零售商和XYZ製造商的協調之後，它們訂立了銷售預測例外事件和訂單預測例外事件的量度： 零售商存貨少於95% 銷售預測錯誤低於20% 銷售預測低與同期銷售預測誤差不得超過10%(以上為銷售預測) 零售商存貨少於95% 訂單預測錯誤低於20% 每年零售商退貨數量必須少於品項管理檔案所定義的數量 緊急的訂單請求必須低於每週的預測5%(以上為訂單預測)接著定義各交易夥伴所要負責的商業功能：l 買方：採購，銷售預測，存貨管理l 賣方：計畫，預測，配銷下一階段定義所要共享的資訊，在CPFR中資訊的共享必須公開且常在進行的工作。下面定義了四種需要被共享的資訊：l 可能會用來測量成效的資料，像是零售商存貨百分比、存貨和預測的正確性。l 可能會用來辨識例外品項的資料，像是零售商存貨百分比、零售商退貨率和預測的正確性。l 可以支援例外品項辨識決策的資料，像是促銷活動、POS資料以及一些會影響預測結果的資料l 品項管理檔案(Item Management Profile)，這是在第二個步驟所要訂立的部分，包含產品的ID，物流規則等最後定義的是一些其他的營運參數，包含資料更新的頻率、資料共享的方式，以及回應時間和計畫調整的時間，如下所示：l 預測的執行以每週為基礎，但是資料、例外品項的更新應該每日更新一次l 在可能的情況下，盡量利用XML作為資料交換的核心語言l 每次交涉的回應時間應該低於30秒，就算有衝突要調整也應該在12個鐘頭之內完成下表顯示了其他的執行程序：程序ABC零售商XYZ供應商活動聯合營運計畫(Joint Business Planning)買方和計畫銷售管理分析、分類管理雙方訂立聯合營運計畫，並且建立品項管理檔案銷售預測(Sale Forecasting)買方、計畫、分析銷售預測以及產生新的存貨管理計畫銷售管理及分析以共同營運計畫為準加上其他輸入資料，包含POS資料、事件、偶發性資料，ABC公司的預測分析師每週產生一筆新的預測資料訂單預測(Order Forecasting)買方、計畫、訂單預測分析、庫存重新採購、物流規劃銷售分析、預測管理以銷售預測為基礎，加入幾項會影響訂單預測的資訊、存貨策略、目前存貨水準，XYZ的預測分析師分析這些資料並且每週產生一份新的訂單預測訂單產生買方庫存規劃以凍結期間的訂單預測為準，XYZ產生訂單。V. 案例討論一 台灣零售業協同規劃預測補貨模式可行性之研究 以烘培業與百貨量販業為例31. 簡介吳慧玲學姊利用CPFR其中的第一到第五個步驟實作了烘培業及百貨業的協同計劃預測系統，利用瀏覽器作為主要介面，XML為資料的描述工具組成了一個協同預測的平台。此系統考慮了許多的銷售影響因子並加入了績效評估的模式，很適合繼續延伸開發成一個更完整的CPFR平台。2. 系統架構及功能系統總共分為四大部分：基本資料上傳、資料上傳、銷售預測、預測方法績效評估，其中，各部份的關係與CPFR的步驟對應如下：CPFR步驟系統元件步驟一、二基本資料上傳步驟三資料上傳、銷售預測步驟四、五預測方法績效評估 基本資料上傳此部份為CPFR的九大步驟的步驟一與步驟二，包含公司資料檔、產品類別資料檔和協同規劃預測補貨協議。 資料上傳此部份為九大步驟的步驟三，包含POS資料 銷售預測此部份為CPFR的九大步驟的步驟三，透過訪談烘培業專家、營業主管和行銷主管，得知銷售預測的方法和因果資訊。有些公司已經有一套預測方法或模式，固系統加上原有預測法，所以包含：l 簡單移動平均法l 因果關係法：使用簡單回歸分析收集影響因子以及銷售資料，並做回歸l 原有預測法：公司原本使用的方法 預測方法及績效評估測量誤差很重要，所以這一套雛型系統也加入了績效評估的部份，總共使用了三種方法來追蹤誤差：l 平均平方差(MSE, mean square error) l 平均絕對偏差(MAD, mean absolute deviation)l 追蹤信號(track signal)3. 劇本推演根據VICS所提出的CPFR共有三階段、九大步驟及四個劇本，而本研究系選擇以買方市場作為研究範圍，故為了增加了整個雛型系統的流暢性，而增加雛型系統劇本的說明，以利對於雛型系統的了解，在此選擇以劇本B作為整個雛型系統的劇本，並以此劇本來進行整個流程說明。步驟一：建立協同關係l 買方應先選擇一家適合的合作夥伴共同實行CPFR雛型系統l 上傳公司基本資料檔(公司名稱、統一編號、電話號碼、傳真號碼、地址、資本額、連絡Email、預期目標、想轉寄此公司資料於賣方的Email)步驟二：建立共同營運計畫l 買賣雙方開始針對整個合作的協商類別進行討論與協談，並決定進行買賣方協商的產品類別l 針對協商等級進行協談，亦即買賣雙方共同訂出買賣雙方差異在多少個百分比內，應透過Email協商、電話或會議來協談l 輸入協商類別l 買賣雙方登入系統進行雙方協同規劃預測補貨協議的輸入(包含：協同預測的產品、賣方、買方以及賣方採用的銷售預測方法)步驟三：建立銷售預測買賣雙方分別輸入下列資料：買方： (1) 使用簡單平均法進行銷售預測 做法： a. 選擇協同策略b. 依序選取前四週的POS資料檔c. 是否為促銷期間*d. 是否為協調後的銷售預測 (2) 以買賣雙方所共同提供的影響變數，利用因果關係法進行銷售預測 做法：a. 選擇協同策略b. 選擇前一周的POS資料c. 考慮下列因素：天氣、商圈活動*、競爭店活動*、自家店其他活動*、新聞*、其他*d. 是否為協調後的銷售預測 (3) 以公司現有正在使用的銷售預測模組或系統進行銷售預測，並說明緣由 做法：a. 選擇協同策略b. 輸入銷售預測週數c. 原系統銷售預測數字為何d. 來源及求法e. 是否為促銷期間*f. 是否為協調後的銷售預測賣方： (1) 使用簡單平均法進行銷售預測a. 選擇協同策略b. 依序選取前四週的POS資料檔c. 是否為促銷期間 (2) 以買賣雙方所共同提供的影響變數，利用因果關係法進行銷售預測 做法：a. 選擇協同策略b. 選擇前一周的POS資料c. 考慮下列因素：天氣、其他 (3) 以公司現有正在使用的銷售預測模組或系統進行銷售預測，並說明緣由 做法：a. 選擇協同策略b. 輸入銷售預測週數c. 原系統銷售預測數字為何d. 來源及求法e. 是否為促銷期間最後，系統列出雙方差異的比較，並提供與去年前期、上個月同期和去年同期的差異比較，讓使用者辨別是否修改預測數字。步驟四：識別銷售預測的異常狀況l 完成銷售預測後，買方將POS資料轉成制定的XML格式，而上傳到系統。POS資料上傳後，開始進行績效評估：n 進行單週期平均絕對誤差之計算u 選擇協同策略u 選擇進行單週期平均絕對誤差計算的週數為何u 自動發送單週期平均絕對誤差的提醒信件，以告知買賣雙方可以進行多週期平均絕對誤差n 進行多週期平均絕對誤差來看簡單移動平均法、因果關係法以及原有預測法u 選擇協同策略u 選擇進行多週期平均誤差計算的起始週數及進行多周期平均誤差結束週數n 進行追蹤指標計算 VI. 案例討論三 - 使用機器學習61. 背景在普及運算(Pervasive Computing)的環境中，我們利用情境的感知以及語意網路的建立讓訊息可以被自動解析，在不知不覺中幫助人類完成工作。在此架構下，感知器(Sensor)以及感知器所形成的網路(Sensor Network)是很重要的元素，感知器蒐集情境資訊，如人類所在的位置、天氣、溼度等資料，並且能夠做出相對的回應，例如：感知器偵測到某區人可能非常擁擠，可能就會啟動GPS導引人往人比較少的路徑，這就是普及運算眾多例子之一。為了達成這個理想，我們必須賦予機器自動學習的能力，讓機器可以在收到許多組輸入, 結果的組合後，可以學習一個方程式來處理類似的事件。我們可以考慮下面一個物理上的規則：這是一個實數對應到實數的函數，我們可以假設它是一個階度為n的多項式把它寫成：事實上，因為感知器所收集到的資料會有許多的干擾，所以我們得利用高斯最小平方法將這些雜訊移除：因此，我們只要有足夠數量的輸入, 輸出組合就可以推回之前的物理規則，這是機器學習最基本的規則，也因為它類似於統計上回歸分析，所以我們也可以用它來做銷售以及訂單預測。因此，這部分我們就將使用在Sensor Network的學習理論套用到銷售和預測分析以及例外品項的偵測中。2. 問題的一般化及解決方式上面所使用的高斯最小平方法只能夠解決輸入資料只有一維的狀況，當輸入資料階度大於等於1時就不容易實行，雖然統計上也有使用向量回歸的方式解決多維輸入的問題，但是效用有限。在實際預測中，很難將輸入資料控制在一維，所以我們先將問題一般化：假設輸入資料是(X1,Y1),(Xm, Ym)則考慮輸入輸出為：l Xi屬於某輸入集合X，其中l Yi屬於某輸出集合Y,，其中在銷售預測中，可以把Xi想像成影響銷售的因子對，維度可以從1k (k為正整數)，可能是天氣、促銷活動等資料，Yi可以想像為這些影響因子所產生的結果，通常只會有一個值，所以說我們將集合 X x Y可以看成一個輸出-輸入的組合對，用此組合來預測資料。3. The Key Algorithm7我們將問題一般化後就可以使用一個新的方式來作為預測之用，稱為The Key Algorithm，它在機器學習上的執行成效遠高於回歸分析，所以用在預測上也應該比傳統因果預測法會好一點，且更加的一般化，The Key Algorithm執行步驟如下：l 取得輸出-輸入的組合(X1,Y1),(Xm, Ym)l 選擇一個Mercer Kernel Kn Mercer Kernel的選擇應具備下列性質u 對稱性，if K(x,x) = K(x,x), for all x, x in Xu 正有限性(positive definite) 如果任何一個有限的集合 p1,pn 屬於X, nn 的矩陣中每個值 K(pi, pj) 是正數，且非亟值。u 連續性(Continuous)n Mercer Kernel的兩個例子：l 選擇一個正實數並且令 c = (c1,cm) 為此特殊方程式的解： (mI + K )c = y 其中：n I是m x m的單位矩陣n K是正有限的一個方陣K(Xi, Xj), 1 = i, j y寫成：4. The Key Algorithm的一些討論Mercer Kernel的挑選，方程式(1)中的 值控制了產生出來方程式平滑的平滑度、干擾的容忍度以及一般化。另外，值得挑選也很重要，越大的值可以得到較好的預測結果。5. 預測結果的整合以及例外事件的處理在預測時考慮許多的因素，這樣會造成許多不同的預測結果，這些預測結果如何整合是一個大問題，如果單純使用平均將所有的預測值作平均，或是給每個預測值權重再計算其加權平均都不是一個很精確且良好的做法。幸好，Sensor Network中也提供了處理類似問題的機制。Sensor Network是好多好多的Sensor所組成的網路，每一個Sensor