簡(jiǎn)介這份PPT聚焦中國免稅品集團(tuán)總公司中免集團(tuán)的零售管理流程面向零售運(yùn)營、門店管理與信息化建設(shè)相關(guān)從業(yè)者幫助梳理免稅零售業(yè)態(tài)差異、特殊業(yè)務(wù)流程與系統(tǒng)需求。內(nèi)容覆蓋市內(nèi)店、口岸店、供船店三類業(yè)態(tài)的客源、商品、銷售與提貨方式對(duì)比并詳細(xì)拆解市內(nèi)店顧客卡辦理、六聯(lián)銷售單據(jù)流轉(zhuǎn)、機(jī)場(chǎng)提貨與海關(guān)核銷以及供船店預(yù)訂單、登船推銷、報(bào)關(guān)出庫與代理轉(zhuǎn)賬等特殊流程。同時(shí)延伸至門店商品計(jì)劃、采購、收發(fā)貨退貨、運(yùn)營與財(cái)務(wù)處理并給出消費(fèi)者行為分析流程改進(jìn)要點(diǎn)及POS系統(tǒng)核心需求如客戶信息快速錄入、VIP與團(tuán)隊(duì)客戶管理、應(yīng)收控制賬戶等。資源包為1個(gè)pptx文件約557KB結(jié)構(gòu)緊湊適合作為零售業(yè)務(wù)流程梳理與系統(tǒng)需求分析的參考材料。目前已有60人學(xué)習(xí)。1. 零售業(yè)務(wù)流程與系統(tǒng)需求從一張 PPT 到可落地的需求清單很多零售項(xiàng)目翻車不是因?yàn)榧夹g(shù)選型錯(cuò)了而是因?yàn)橐婚_始就沒人把「業(yè)務(wù)流程」和「系統(tǒng)需求」這兩件事對(duì)齊。我見過太多團(tuán)隊(duì)拿著幾十頁 PPT 講門店補(bǔ)貨、會(huì)員積分、促銷引擎講得頭頭是道結(jié)果開發(fā)做完第一版業(yè)務(wù)方一句「這不是我要的」直接打回重做。問題出在哪出在 PPT 里的流程是給人看的系統(tǒng)需求是給機(jī)器執(zhí)行的中間缺了一層翻譯。零售這個(gè)場(chǎng)景尤其明顯門店、倉儲(chǔ)、電商、客服、財(cái)務(wù)五條線交叉任何一個(gè)環(huán)節(jié)的流程斷點(diǎn)都會(huì)變成系統(tǒng)里的臟數(shù)據(jù)。所以這篇筆記要聊的就是怎么把一份零售業(yè)務(wù)流程 PPT拆成開發(fā)能直接照著建表、寫接口、配規(guī)則的系統(tǒng)需求。適合正在做零售中臺(tái)、ERP 對(duì)接、門店數(shù)字化改造的工程師和產(chǎn)品經(jīng)理尤其是那種「業(yè)務(wù)方只給了一份 PPT讓你兩周出方案」的情況。2. 先拆業(yè)務(wù)流程零售 PPT 里哪些圖能直接用哪些是坑2.1 零售業(yè)務(wù)流程的三條主線與常見畫法零售業(yè)務(wù)不管規(guī)模大小流程基本繞不開三條主線商品從采購到上架的供應(yīng)鏈主線、顧客從進(jìn)店到復(fù)購的交易主線、錢從流水到對(duì)賬的財(cái)務(wù)主線。PPT 里常見的畫法是泳道圖橫軸是角色采購員、倉管、店長(zhǎng)、收銀、財(cái)務(wù)縱軸是步驟。這種圖看著清楚但直接拿來做系統(tǒng)需求會(huì)踩坑因?yàn)樗选溉斯徟购汀赶到y(tǒng)動(dòng)作」畫在了同一個(gè)框里。我一般會(huì)先把泳道圖里的每個(gè)節(jié)點(diǎn)標(biāo)上三種顏色綠色是純系統(tǒng)自動(dòng)完成黃色是系統(tǒng)輔助人工決策紅色是純?nèi)斯ぞ€下操作。綠色節(jié)點(diǎn)直接對(duì)應(yīng)接口或定時(shí)任務(wù)黃色節(jié)點(diǎn)對(duì)應(yīng)工作流引擎里的待辦和規(guī)則紅色節(jié)點(diǎn)要么砍掉要么做成系統(tǒng)里的備注字段。這一步做完你會(huì)發(fā)現(xiàn) PPT 里至少三分之一的流程節(jié)點(diǎn)根本不需要進(jìn)系統(tǒng)。2.2 從泳道圖到狀態(tài)機(jī)的轉(zhuǎn)換方法零售系統(tǒng)里最核心的抽象是狀態(tài)機(jī)。以采購單為例PPT 上可能只畫了「創(chuàng)建→審批→發(fā)貨→收貨→入庫」五個(gè)框但系統(tǒng)里必須定義清楚每個(gè)狀態(tài)之間的遷移條件、觸發(fā)角色和超時(shí)策略。下面這段 Python 偽代碼展示的是我常用的狀態(tài)機(jī)定義方式用字典描述遷移規(guī)則方便后續(xù)直接生成數(shù)據(jù)庫配置表。# 采購單狀態(tài)機(jī)定義狀態(tài) - {觸發(fā)事件: (目標(biāo)狀態(tài), 允許角色, 超時(shí)小時(shí))} purchase_fsm { draft: { submit: (pending_approval, [buyer], None), cancel: (cancelled, [buyer], None), }, pending_approval: { approve: (approved, [manager], 24), # 24小時(shí)未審批自動(dòng)提醒 reject: (draft, [manager], None), }, approved: { ship: (shipped, [supplier], 48), # 48小時(shí)未發(fā)貨觸發(fā)預(yù)警 close: (closed, [buyer], None), }, shipped: { receive: (received, [warehouse], None), return: (returning, [warehouse], None), }, received: { stock_in: (completed, [warehouse], None), }, }這段代碼的邏輯是每個(gè)狀態(tài)只暴露有限的合法事件事件觸發(fā)時(shí)校驗(yàn)角色權(quán)限超時(shí)字段用于生成定時(shí)任務(wù)。參數(shù)上超時(shí)小時(shí)為None表示不設(shè)超時(shí)設(shè)為數(shù)字則會(huì)在對(duì)應(yīng)時(shí)間后往消息隊(duì)列推一條提醒。實(shí)際落地時(shí)我會(huì)把這張字典直接存進(jìn)配置表運(yùn)營可以在后臺(tái)改超時(shí)時(shí)間不用發(fā)版。提示狀態(tài)機(jī)里不要出現(xiàn)「其他」「待定」這類模糊狀態(tài)每個(gè)狀態(tài)必須有明確的進(jìn)入條件和退出條件否則后期報(bào)表統(tǒng)計(jì)一定對(duì)不上賬。3. 系統(tǒng)需求怎么落從流程節(jié)點(diǎn)到接口和表的映射3.1 需求條目的四要素寫法PPT 里的流程描述是「采購員提交采購申請(qǐng)經(jīng)理審批后發(fā)給供應(yīng)商」這句話直接給開發(fā)開發(fā)只能猜。我要求團(tuán)隊(duì)里的需求條目必須寫成四要素觸發(fā)條件、輸入數(shù)據(jù)、處理規(guī)則、輸出結(jié)果。上面那句話翻譯過來就是觸發(fā)條件是采購員點(diǎn)擊提交輸入數(shù)據(jù)是商品編碼、數(shù)量、期望到貨日處理規(guī)則是校驗(yàn)商品編碼存在且數(shù)量大于零然后生成待審批任務(wù)輸出結(jié)果是采購單號(hào)和一個(gè)待辦消息。這四要素寫清楚之后接口的入?yún)⒊鰠⒒揪投?。我?xí)慣用一張 Markdown 表格來管理需求條目字段包括需求編號(hào)、關(guān)聯(lián)流程節(jié)點(diǎn)、四要素描述、優(yōu)先級(jí)、驗(yàn)收標(biāo)準(zhǔn)。這張表就是后續(xù)測(cè)試用例的源頭驗(yàn)收標(biāo)準(zhǔn)寫不清楚的需求一律打回重寫。3.2 用 SQL 建表驗(yàn)證需求完整性需求寫完不能只靠人眼檢查我一般會(huì)先建核心表用建表語句反向驗(yàn)證需求有沒有遺漏。下面這段 SQL 是零售采購模塊的簡(jiǎn)化版建表重點(diǎn)看字段和約束是否覆蓋了前面狀態(tài)機(jī)里的所有狀態(tài)。CREATE TABLE purchase_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 采購單號(hào), status VARCHAR(20) NOT NULL DEFAULT draft COMMENT 狀態(tài)對(duì)應(yīng)狀態(tài)機(jī), buyer_id BIGINT NOT NULL COMMENT 采購員ID, supplier_id BIGINT NOT NULL COMMENT 供應(yīng)商ID, expected_date DATE COMMENT 期望到貨日, total_amount DECIMAL(12,2) DEFAULT 0.00 COMMENT 總金額, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_status_created (status, created_at), INDEX idx_supplier (supplier_id) ) COMMENT采購單主表; CREATE TABLE purchase_order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, sku_code VARCHAR(64) NOT NULL COMMENT 商品編碼, quantity INT NOT NULL DEFAULT 0, unit_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, received_qty INT NOT NULL DEFAULT 0 COMMENT 實(shí)收數(shù)量, INDEX idx_order (order_id), INDEX idx_sku (sku_code) ) COMMENT采購單明細(xì)表;建表時(shí)我會(huì)重點(diǎn)檢查三件事狀態(tài)字段的枚舉值是否和狀態(tài)機(jī)完全一致、明細(xì)表的received_qty是否支持部分收貨、索引是否覆蓋了最頻繁的查詢條件按狀態(tài)和時(shí)間篩選、按供應(yīng)商篩選。如果 PPT 里提到「支持部分收貨」但明細(xì)表只有一個(gè)總數(shù)量字段那就是需求沒落到位。3.3 接口清單與流程節(jié)點(diǎn)的對(duì)齊檢查表建好之后把狀態(tài)機(jī)里的每個(gè)事件映射成一個(gè)接口列成清單。比如submit對(duì)應(yīng)POST /purchase/submitapprove對(duì)應(yīng)POST /purchase/approve。清單里要標(biāo)注每個(gè)接口的調(diào)用方前端頁面、定時(shí)任務(wù)、外部系統(tǒng)和冪等要求。零售場(chǎng)景里收貨接口經(jīng)常被倉庫的 PDA 重復(fù)調(diào)用冪等必須做在服務(wù)端用order_no sku_code做唯一鍵去重。這一步做完拿著接口清單和狀態(tài)機(jī)圖再對(duì)一遍 PPT如果發(fā)現(xiàn)某個(gè)流程節(jié)點(diǎn)找不到對(duì)應(yīng)的接口或表字段要么是 PPT 畫了不需要系統(tǒng)做的事要么是需求漏了。我一般會(huì)在這個(gè)環(huán)節(jié)揪出三到五個(gè)遺漏點(diǎn)比如退貨流程里的「質(zhì)檢結(jié)果」字段、促銷流程里的「分?jǐn)偨痤~」字段。4. 避坑與排查零售需求落地時(shí)最容易翻車的五個(gè)地方4.1 現(xiàn)象庫存對(duì)不上系統(tǒng)顯示有貨實(shí)際沒貨原因采購入庫和銷售出庫用了兩套庫存表或者入庫時(shí)沒扣減在途庫存。零售 PPT 里經(jīng)常只畫「入庫」一個(gè)框但實(shí)際系統(tǒng)里在途、在庫、鎖定三種庫存狀態(tài)必須分開。 解決建一張庫存流水表所有庫存變動(dòng)只通過流水記錄當(dāng)前庫存由流水匯總得出。入庫時(shí)增加在庫、減少在途銷售時(shí)增加鎖定、減少在庫。4.2 現(xiàn)象促銷規(guī)則上線后訂單金額算錯(cuò)原因PPT 里的促銷描述是「滿100減20」但沒定義疊加規(guī)則和優(yōu)先級(jí)。多個(gè)促銷同時(shí)命中時(shí)系統(tǒng)按什么順序計(jì)算是折上折還是取最優(yōu)需求里沒寫。 解決在需求階段就定義促銷引擎的規(guī)則模型每條促銷帶優(yōu)先級(jí)和互斥組計(jì)算時(shí)按優(yōu)先級(jí)排序互斥組內(nèi)只取最優(yōu)。測(cè)試用例必須覆蓋兩兩疊加的場(chǎng)景。4.3 現(xiàn)象審批流卡住單據(jù)一直掛在待審批原因狀態(tài)機(jī)里定義了審批節(jié)點(diǎn)但沒定義審批人離職或請(qǐng)假時(shí)的代理規(guī)則。零售企業(yè)人員流動(dòng)大審批人一換單據(jù)就死在那里。 解決審批節(jié)點(diǎn)配置里增加代理人和超時(shí)自動(dòng)升級(jí)規(guī)則超時(shí)未審批自動(dòng)轉(zhuǎn)給上級(jí)。定時(shí)任務(wù)每小時(shí)掃一次超時(shí)待辦。4.4 現(xiàn)象門店和電商訂單號(hào)重復(fù)對(duì)賬對(duì)不上原因不同渠道各自生成單號(hào)沒有全局唯一約束。零售 PPT 里渠道是分開畫的但財(cái)務(wù)對(duì)賬需要統(tǒng)一視角。 解決單號(hào)生成規(guī)則里加渠道前綴或者用全局發(fā)號(hào)器。數(shù)據(jù)庫層面order_no加唯一索引插入沖突時(shí)直接報(bào)錯(cuò)而不是靜默覆蓋。4.5 現(xiàn)象需求評(píng)審?fù)ㄟ^開發(fā)說做不了原因需求條目里寫了「根據(jù)歷史銷售數(shù)據(jù)智能推薦補(bǔ)貨量」但沒定義數(shù)據(jù)來源、計(jì)算頻率和兜底策略。這種模糊描述在零售 PPT 里特別常見。 解決把智能推薦拆成可執(zhí)行的規(guī)則比如「取過去四周同星期幾的平均銷量乘以安全系數(shù)1.2向上取整」。數(shù)據(jù)來源、計(jì)算時(shí)機(jī)、異常兜底全部寫進(jìn)需求條目。5. 用一份檢查清單把 PPT 鎖死成可開發(fā)的需求最后一章說一個(gè)我用了三年的習(xí)慣每次拿到零售業(yè)務(wù)流程 PPT先花半小時(shí)填一份檢查清單填不完就不進(jìn)開發(fā)。清單不長(zhǎng)但能擋住八成返工。檢查項(xiàng)通過標(biāo)準(zhǔn)常見不通過原因流程節(jié)點(diǎn)分類每個(gè)節(jié)點(diǎn)標(biāo)了綠/黃/紅把人工審批畫成了系統(tǒng)自動(dòng)狀態(tài)機(jī)完整性每個(gè)狀態(tài)有進(jìn)入/退出條件存在「其他」?fàn)顟B(tài)需求四要素觸發(fā)/輸入/規(guī)則/輸出齊全只寫了「系統(tǒng)處理」表字段覆蓋狀態(tài)枚舉與狀態(tài)機(jī)一致漏了部分收貨、質(zhì)檢結(jié)果接口冪等寫操作有唯一鍵去重依賴前端防重異常兜底超時(shí)、離職、數(shù)據(jù)缺失有策略只寫了正常流程填完清單我會(huì)挑三個(gè)最復(fù)雜的流程節(jié)點(diǎn)手動(dòng)畫一遍數(shù)據(jù)流轉(zhuǎn)從用戶點(diǎn)擊到數(shù)據(jù)庫落庫中間經(jīng)過哪些服務(wù)、哪些表、哪些消息。畫的過程中如果發(fā)現(xiàn)某個(gè)字段在兩個(gè)服務(wù)里含義不一致比如「數(shù)量」在采購服務(wù)里是含稅數(shù)量、在庫存服務(wù)里是不含稅數(shù)量那就必須在需求里統(tǒng)一口徑否則上線后一定出臟數(shù)據(jù)。這個(gè)習(xí)慣幫我省過很多后悔藥。有一次促銷模塊上線前我在檢查清單里發(fā)現(xiàn)「優(yōu)惠分?jǐn)偂棺侄卧谟唵伪砗徒Y(jié)算表里精度不一樣一個(gè)是兩位小數(shù)一個(gè)是四位小數(shù)差一分錢。就這一分錢財(cái)務(wù)對(duì)賬時(shí)差了十幾萬。后來統(tǒng)一用四位小數(shù)存儲(chǔ)展示時(shí)再截?cái)唷Ｐ枨笪臋n不是寫完就完了它得能直接翻譯成建表語句和接口定義。如果一份零售業(yè)務(wù)流程 PPT 經(jīng)過這套流程處理之后開發(fā)拿著需求條目就能寫代碼測(cè)試拿著驗(yàn)收標(biāo)準(zhǔn)就能寫用例那才算真正落地。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取