那麼呢，我們的下一個議題是 Inventory Control。 好，我們來看一下 Inventory Control 有什麼議題。 存貨這種東西啊，在實務上呢，總是需要的。 比如說，你是零售商的話，你要存 這個產品的存貨嘛，你必須貨架上要放著東西，後面的庫房要放著東西，不然消費者來買不到- ，就搞笑啦！ 那你，如果你是製造商的話，你可能要存原料的存貨，這樣以便有訂單來的時候，你可以趕- 快生產， 趕快出貨。 那到底為什麼需要 Inventory 呢？很多的時候是因為我們需要 Supply 跟 Demand 中間的一個 buffer。 那比如說，因為訂貨有前置時間， 你不可能消費者來到你的店裡，你才馬上打電話跟製造商叫貨， 那來不及嘛！所以你需要有一個 buffer 在那邊， 以便就是你每個禮拜進一次貨，每個禮拜進一次貨， 進了以後就用存貨來賣，賣，賣，賣，賣，大概是這樣子的想法。 或者是呢，你必須要 balance 你的 fixed ordering cost 跟 variable holding cost。 這個是什麼意思啊？就是說，你每一次訂貨可能有一些固定成本， 那因為有這固定成本，所以你不想要一個一個叫，你想要一批一批叫， 比如說，運貨成本；比如說處理成本；比如說檢貨成本，等等。 可能都是一批一批算的，而不是一個一個算的。 那因為這樣，你自然就不會想要 一個一個叫，你會一批一批叫。 那你一批一批叫， 自然就有存貨啦！哦，是這個樣子，好！ 那麼我們今天要 Control inventory 的時候呢，我們就需要有這個 Inventory policy， 就是存貨政策，它通常講的事情是說我們要什麼時候 訂貨，是每個禮拜訂嗎？每兩個禮拜訂嗎？每一次訂要訂多少？ 我們要訂二十個呢，還是兩百個呢？然後呢，我們要跟誰訂之類的。 那我們今天 會來討論這個其中的一些議題。 主要是什麼時候訂，還有訂多少。 那麼存貨政策在這個世界上有百百種，有的很簡單，有的很複雜。 那其中幾個最簡單的，一個是所謂的 ( Q. R ) policy。 它的意思就是說，你呀， 比如說，每天每天你都做生意。 每天結束，你要打烊 之前，你去 check 一下你的 item 的 inventory level， 就是每一個東西還剩下多少個。 如果剩下的量太少了，少過 你的設定的大 R 的數量，那麼呢，我們就去訂貨。 我們就訂 Q 這麼多， 不然的話就什麼事都不要做。 那這樣子的大 R 被稱為是一個 Re-order point， 也就是說呢，當你的存貨量低到一定程度，低過 Re-order point，你覺得不行啦，該交貨了，你就叫。 你叫，你就叫 Q unit，是這樣子。 那這樣合起來叫做一個 ( Q, R ) policy。 另一個非常像的叫做 ( s, S ) policy。 它的意思是說呢，你一樣，就是定期地這個檢查，檢查，檢查。 然後， 當你的大 I 小於小 s，這個時候，小 s 也是一個這個 Re-order point， 當你小於小 s 的時候呢，你就訂到大 S。 也就是說，如果你大 S 設定的是 50，那么當你剩下 5 個， 你就會叫 45 個；當你剩下 8 個，你就會叫 42 個，以此類推。 那長得跟 Q,R 其實差不多像，只是你訂貨的行為略有一點點不同，如此而已。 好，那麼當然哪，你今天如果你家的店裡有 1000 個 item，或者是有這個一百萬、 一千萬 item 在你們的電子商務網站上的話， 你恐怕沒有辦法用人工做 Ordering。 所以很多的時候呢，我們會嘗試 Implement automatic ordering。 那講起來也很簡單啦！就是我們大概會 想要做一件事情，就是一旦觸發 reorder 的這個 event， 我們就去訂貨。 那這個時候呢，跟我們使用的是 continuous 還是 periodic 的 review system 會有差。 Continuous 的意思就是說，你其實你知道賣東西的發生的時間吧。 你每一次在店的前面，用這個刷條碼或什麼的，嗶一下的時候， 你的 point-of-sale，就是銷售點的這個 system 它會記錄，你的存貨量要減 1，減 1， 減 1。 所以你一觸發這個 Reorder point 的時機，一定是你銷貨的時候，銷掉的那一瞬間， 你的系統就會自動向你的供應商傳一張訂單，就是說，嘿，我要訂貨啦！ 好，這是一個可能性。 如果你整合你們家的銷貨系統 和你們的訂貨系統的話，就可以做到這個自動訂貨。 那很多時候啊，你雖然能夠做這個整合，畢竟是你自己店裡面的東西嘛， 但你還是沒有辦法在任意的時間訂貨，因為供應商可能不配合。 好，你每天每天每天，一觸發就訂，一觸發就訂，供應商可能不堪其擾。 所以供應商可能還是會跟你約定，欸，一個禮拜訂一次吧，或者是一天訂一次吧。 那如果有這樣的訂貨週期的話，那你當然是每一次訂貨週期前再去檢查，其實也就 可以了。 因為你早發現也沒用，你還是要等到訂貨週期到了的時候。 大概就是這麼一回事。 好，所以呢，在這裡，讓我們來試著 implement 一個很簡單的 periodic review system。 那我們呢，來試試看，implement 一個 ( Q, R ) policy 吧， 所以呢，大概是像這樣。 請使用者告訴我，Q 是多少，R 是多少。 再請他告訴我，我這個東西的 Initial inventory 有幾個。 比如說， 有二十個啊，五十個啊，之類的。 好，然後把東西印出來，看一下。 接下來跑一個無窮迴圈，為什麼是無窮迴圈呢？因為這個系統必須要一直 run，對吧？每天 check，每天 check， 每天 check。 所以呢，每一天請你告訴我，你今天 賣了幾個。 根據這個賣了幾個， 我來看看我的存貨要減 sales，對吧？然後呢，我要不要 減 sales 其實是一個議題，因為這個取決於我現在的這個手上的貨到底夠不夠。 所以這裡有一個 ternary 的 if else。 它什麼呢？它是說我的 I 要變化，那怎麼變？ 如果 I－sales >= 0，也就是說我手上的存貨量足夠 在今天賣 8 個，賣 10 個，賣 20 個，那這個情況下呢，我的存貨量自然就變成剩下的量。 但如果想要的人太多，那我的存貨量就歸零。 歸零了以後呢，我不要讓存貨量變成負的。 那我的 I 在那個情況下， 就要變成 0。 大概是這樣子。 好，總之一天的銷售結束了以後，如果 I 比 R 小，那我們就訂貨。 訂貨的時候呢，就把 I 變大，變成 I 加 Q。 那如果這件事沒發生，就不要訂。 那就沒事，然後呢，我們就把東西 print out 看看。 好，那我們來試一下。 這個 簡單的這個 ( Q, R ) policy 的 implementation 就在這個地方，所以我們就執行啦！比如說， 30 跟 10 好了，然後 Initial inventoory 假設 20，今天賣 2 個， 沒事，我剩 18 個，今天賣 7 個，沒事。 今天再賣 3 個的話，它就會瞬間 order，對吧？ 11 減 3 變成 8。 8 它 order 完了以後呢，就會變成 38。 那好，比如說我們賣 40 個好了， 40 個以後呢，不會變成負 2，會變成 0，0 又訂貨，變 30。 然後，以此類推，這樣子。 OK，好，大概就是這麼一回事。 那你當然不免可能會問啦，欸，老師啊，怎麼會 一訂貨貨就來？這個沒什麼了不起的嘛，就是實務上，人們會把 正在運送到我們店裡的那些東西，也列入存貨水準的計算。 好，那如果你不要這麼做，也無所謂。 就是你可以把存貨分成手上有的、 正在送來的、 或者是這個，還沒有訂的，等等。 然後呢，把這個 rule 寫得 複雜一點就可以啦！這個不是什麼大問題，我們今天在這裡就不討論了。 那大家可以想一下，如果我要 implement 的不是 ( Q, R ) policy，而是 ( s, S ) policy 的話， 那我要怎麼 implement 呢？那也是非常地簡單，對吧？就把 藍色的地方稍微修一下就可以啦！
