前置倉系統設計之采購篇
編輯導語:采購模塊是各個工作業務場景中的常見模塊,不過由于業務對象、業務場景的差異,采購模塊的設計也有所不同。在前置倉系統中,采購模塊設計需要考慮到供貨對象、采購數量、采購單等方面。本篇文章里,作者就前置倉系統的采購模塊設計做了總結,一起來看一下。
上篇文章給大家講解了前置倉系統設計中關于訂貨的邏輯和思路,本篇文章給大家聊聊前置倉系統的采購。
一、采購的職責和使用場景
1. 采購的職責
采購這個角色自從有零售的時候,其實就誕生了。雖然行業眾多,業務不一,但是采購這個角色的本質職責其實是沒變的:即從資源市場獲取資源的一種經濟活動。說的直白點,就是找到合適的賣主,以合適的價格,買到合適的東西。
2. 使用場景
由于行業和業務的不同,采購這個角色的使用場景或者說工作場景其實是有區別的。比如從事生鮮業務的采購員,大部分是移動App場景為主,而從事超市非生鮮品類的采購,大部分是以固定工位PC場景為主。不同的使用場景,產品的設計也有所區分。
二、向誰采
“向誰采”中的“誰”其實指的就是資源市場,也即我們常說的供應商。既然有供應商,那么就涉及到供應商的信息管理,常見的信息管理方式有:
- 【增】:新增供應商信息,包括供應商名稱、聯系方式、法人、地址等基礎信息;
- 【刪】:刪除供應商信息,如某個供應商不再使用,為避免信息混亂,可刪除供應商信息(前提是該供應商不存在未完結的單據和財務相關信息);
- 【改】:修改供應商信息,如聯系人、聯系電話等等的變更;
- 【查】:通過一定條件,如供應商名稱、聯系人、經營品類等進行信息查詢;
- 【顯】:顯示供應商信息,即在需要該信息時,完整準確的顯示供應商信息;
- 【算】:通常指的是計算,比如當前總共有多少供應商,每頁展示10條,一共要展示多少頁(頁碼);
- 【傳】:信息傳輸,比如上傳營業執照、食品經營許可證等等。
蔬東坡供應商管理界面示意
三、采什么
1. 數據來源
采什么的數據來源主要有兩部分:
- 下屬部門/門店的訂貨需求:這個很好理解,作為總部的采購員,需要負責下屬門店/部門的訂貨需求;
- 總部的市場/營銷/人力需求:這個是除了下屬門店/部門的需求之外,總部市場/營銷/人力部門還有另外的需求,比如作為總部的人力,需要采購一批粽子作為節日禮品發放給員工。
2. 產品方案
采什么的重點在于“什么”,這里要解決的一個問題就是品商關系,即商品與供應商的關系,核心關鍵在于下面5點:
- 商品所屬的供應商:A商品屬于1號供應商;
- 商品采購單位:飲料是按件采還是按箱采;
- 采購規格:即采購單位與商品最小單位的換算關系,比如一箱等于12瓶;
- 采購價:對應采購單位的采購價,比如一箱礦泉水12元;
- 最小采購量:單次采購的最小采購數量,比如農夫山泉最小采購量為5,即5箱起采。
悅厚品商關系管理界面示意
四、采多少
采多少需要考慮數據來源方的需求及供應商的采購單位和最小采購量。正常情況下,采購量應該大于等于最小采購量的。而對于采購量的大小,除了人工錄入,更多依賴系統的預測,而業界對于采購量的系統預測有比較成熟的算法模型,這里簡單列舉一下。
1)定性預測
- 經驗估算法;
- 菲爾德法;
- 生命周期預測法;
- 顧客意見法;
- ……
2)定量預測
① 時間序列分析法
- 簡單平均法;
- 移動平均法;
- 指數平均法;
- 季節變動預測法。
② 因果分析法
- 相關回歸預測;
- 馬爾可夫預測;
- ……
五、怎么采
在明確了向誰采、采購多少后,我們需要明確一下怎么采。采購與供應商之間交互的單據通常是采購單。而采購單就是怎么采的核心。
1. 生成流程
因為采什么的數據來源是下屬部門/門店的訂貨需求和總部的市場/營銷/人力需求,所以生成流程一般是將這兩個需求來源的數據(通常叫訂貨單)進行匯總,生成采購單。
2. 包含元素
采購單主要包含以下元素。
供應商信息:
- 名稱;
- 聯系人;
- 聯系電話;
- 聯系地址。
商品:
- 名稱;
- sku編碼;
- upc編碼。
采購單位、采購數量、采購單價、采購規格、采購門店/需求方、采購總價。
系統的采購單需要將紙質采購單數據還原
作者:Wick;微信公眾號:產品基本功
本文由 @產品基本功 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議
- 目前還沒評論,等你發揮!