那麼呢,我們的下一個議題是 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 呢?那也是非常地簡單,對吧?就把 藍色的地方稍微修一下就可以啦!