中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：這篇文章作者從系統全局分析、系統詳細分析和熟悉的系統原型設計三方面入手，詳細地向我們展示如何逆向解構萬里牛電商ERP，通過自己的實踐推導出其產品分析方法，作者把書里的知識學以致用，非常值得我們學習借鑒，一起來看一下吧~

在此我想感謝譚云杰老師的《大象—Thinking in UML》，我深受這本書的啟蒙，這本書不是單純的講UML，而是講軟件過程，軟件分析方法。反復研讀后，我把書中的思想慢慢內化成自己的產品分析方法，實現可以一步步推導的分析方法，并運用在本次文章上。

本文有1.3萬字，請保持耐心。

此次本著學習的態度解構萬里牛ERP（專業版），我是從萬里牛的頁面和功能入手，逆向分析得到關鍵輸出物和原始需求，以此深入學習電商ERP的業務。

獲得關鍵輸出物后，本文是以正向設計的邏輯進行描述，還原從需求到原型的設計過程。

本文按分析粒度大小，分為三部分，如圖1：

1. 系統全局分析，分析粒度保持在模塊管理，目的是獲得系統的全局認識。
2. 系統詳細分析，分析粒度變小，保持在增刪改查功能的粒度，目的是獲得全部系統用例。
3. 熟悉的系統原型設計，分析粒度變小，保持在頁面和元件交互，目的是獲得可交付的原型和標注。

圖1 分析邏輯

一、系統全局分析

系統全局分析，分析粒度保持在模塊管理，目的是獲得系統的全局認識。第一節是從業務的角度獲取需求和用例，第二節是從系統的角度獲取需求和用例，我稱這個粒度為一級用例，第三節和第四節是在前兩節的用例基礎上分析主流程和對象。

1. 業務用例

在軟件項目里，業務范圍和系統范圍是不同的。業務范圍指這個項目所涉及的所有客戶業務，這些業務有沒有計算機系統參與都是客觀存在的。系統范圍是指軟件將要實現的那些對應于業務功能的系統功能，從功能性需求來說系統范圍是業務范圍的一個子集，但是一些系統功能則會超出業務范圍，例如操作日志，有沒有操作日志并不影響業務目標的達成，客戶也不一定會提出這個要求，但從系統角度出發，操作日志會使得系統更加健壯。

——來自《大象—Thinking in UML》

在引入計算機系統之前，業務也一直跑得很順暢，因此在初始階段，不引入系統的角度，純粹站在業務的角度，分析業務的主流程場景，獲取業務用例。

獲取業務用例需要分析出業務主角和用例，業務主角即參與到業務流程中的角色，例如采購員、售前客服等。用例即業務主角需要在業務流程中完成的事情，這里需要注意用例的粒度，我經過思考，系統全局分析階段，建議使用管理一類事物的粒度，例如銷售訂單管理，這個粒度僅供參考。

開始獲取業務用例，以下是一段商家工作內容的場景。

店長小明想開一家網店，在商品上架銷售前，小明做了以下準備工作：

1. 在淘寶注冊一個店鋪；
2. 選擇想要做的品類和賣的商品，并維護商品信息；
3. 找合作快遞公司，用于發貨給客戶；
4. 找倉庫，用于存儲采購的商品；
5. 店長還需要關注店鋪各業務的運轉情況，即查看銷售、采購、庫存、資金的報表。

除此之外，還招了6個崗位一起合作：

1. 采購員，負責采購商品補充庫存；
2. 售前客服，主要為買家介紹商品特性和解答銷售方面的問題，買家下單后審核訂單；
3. 發貨員，對通過審核的訂單進行配貨打包，進行發貨；
4. 售后客服，主要為買家解答售后方面的問題，并審核買家發起的退換貨申請；
5. 倉庫管理員，記錄商品的出入庫和管理商品庫存；
6. 財務員，記錄銷售訂單和采購的資金出入。

團隊到位了，可以開展工作了。

采購員根據店長選好的商品進行采購工作，聯系供應商采購商品，即提交采購訂單。采購訂單的貨品到了之后，需要倉庫管理員記錄采購入庫單，并為商品安排庫位和增加商品的庫存。商品入庫后，采購員和供應商登記結算單。如果到貨的商品有問題則進行退貨處理，即提交采購退貨單，采購商品出庫時需要倉庫管理員記錄采購退貨出庫單，并減少退貨商品的庫存。

至此，把商品上架在淘寶，就可以開始接單了。當買家在淘寶下單并支付后，訂單的處理就交給售前客服和發貨員了。

首先售前客服會審核訂單，如有注意事項可對訂單進行備注，例如有什么贈品、指定發什么快遞等，通過審核的訂單即流轉給發貨員。發貨員在倉庫中進行配貨并打包，最后打印快遞單，進行發貨。發貨時，需要倉庫管理員記錄銷售出庫單，并減少銷售商品的庫存。

另外小明還希望發展一下線下大客戶，所以有的售前客服在線下開拓客戶?？蛻艨芍苯雍褪矍翱头聠?，售前客服創建訂單，然后流轉給發貨員。發貨員在倉庫中進行配貨并打包，最后打印快遞單，進行發貨。發貨時，需要倉庫管理員記錄銷售出庫單，并減少銷售商品的庫存。

以上是正向的交易流程，買家下單，商家發貨。當買家提出退換貨的時候，就需要售后客服介入。買家在淘寶提交了退換貨申請，售后客服進行審核是否同意退換貨，審核通過后，買家寄回商品。寄回商品到達指定退貨倉庫后，倉庫管理員記錄退貨入庫單，并更新商品庫存。如果是退貨，售后客服進行退款處理，如果是換貨，售后客服根據售后單，手動創建銷售訂單，然后該銷售訂單正常發貨。

倉庫管理員日常工作除了記錄銷售訂單、采購訂單的出入庫單外，平時需要維護倉庫的基礎數據，庫區、庫位等，并且記錄商品的擺放位置。每次商品出入庫都會更新庫存，定期查看各商品的庫存數量。還會為了保證商品數量安全，定期對倉庫的商品數量進行盤點。如果商品的成本近期發生變化，還會對商品進行調價。當前小明擁有兩個地方的倉庫，有時候需要進行商品調撥，即倉庫管理員把A商品從甲倉庫調撥到乙倉庫，調撥出庫和入庫時也都需要記錄調撥出庫單和入庫單。

以上是采購訂單和銷售訂單的場景，每次商品出入庫，都伴隨著資金的收支變化，所以財務員有以下日常工作。首先，財務員需要維護資金賬戶基礎數據，其他主要工作就是收款、付款、賬目對賬檢查。

收款主要是收取銷售訂單的錢，有三種收款方式：現金收款、充值款消費（預收款）、賒賬（記錄應收款）。現金收款是買家下單時進行支付費用，例如淘寶訂單。充值款消費是買家提前充值費用存在該客戶的賬戶上，然后下單時進行扣減，主要適用于線下訂單。賒賬是買家下單時不進行付款，客戶賬上也沒有充值款可以扣減，這樣就會記錄該客戶的應收款，然后定期收款，并記錄收款單，適用于月結的客戶。

付款是支付給供應商采購訂單的貨款和支付給快遞公司的快遞費。有三種支付方式：現金支付、充值款支付（預付款）、賒賬（記錄應付款）。現金支付是采購訂單到貨后現金支付貨款給供應商。充值款支付是預存充值費用在某個供應商那，每次采購單到貨后選擇使用充值款支付貨款。賒賬是采購訂單到貨后不支付貨款給供應商，然后記錄該供應商的應付款，定期付款，并記錄付款單，適用于月結的供應商。

快遞費目前是選擇月結的方式結算。為了保證賬目的準確，財務員會定期進行快遞單對賬。

有時候需要轉移資金，即財務員把資金從A賬戶轉到B賬戶，則進行轉賬。財務員在有資金往來的時候都會記錄資金流水。

基于以上場景，獲取業務主角和提煉一級用例，如圖2。

圖2 業務用例

1）店長

是店鋪的管理者，會管理基礎數據和查看報表：

1. 注冊淘寶店鋪，即管理店鋪；
2. 選擇銷售的商品，即管理商品；
3. 選擇合作的快遞公司，即管理快遞公司；
4. 確定倉庫，即管理倉庫；
5. 查看報表。

2）采購員

負責采購商品，會管理采購相關的事項有：

1. 選擇供應商進行采購，即管理供應商；
2. 提交采購訂單，即管理采購訂單；
3. 采購商品入庫后和供應商進行結算，即管理采購結算單；
4. 如有商品需要退貨，提交采購退貨單，即管理采購退貨單。

3）售前客服

是銷售訂單的跟進人，會管理訂單相關的事項有：

1. 線下開拓客戶，即管理客戶；
2. 審核銷售訂單，保證訂單順利完成，即管理銷售訂單。

4）發貨員

負責對銷售訂單進行配貨、打包、發貨：

1. 參與管理銷售訂單的發貨流程；
2. 打印快遞單，進行發貨。

5）售后客服

負責審核售后單，即管理售后訂單。

6）倉庫管理員

負責倉庫商品的庫存安全，會管理倉庫相關的事項有：

1. 維護庫存的存儲區域，會參與管理倉庫；
2. 采購商品到貨后，記錄采購入庫單，即管理采購入庫單；
3. 采購退貨商品出庫時，記錄采購退貨出庫，即管理采購退貨出庫單；
4. 銷售訂單商品發貨時，記錄銷售出庫單，即管理銷售出庫單；
5. 銷售退換貨商品退回倉庫時，記錄銷售售后入庫單，即管理銷售售后入庫單；
6. 記錄商品庫存更新記錄，即管理庫存；
7. 定期盤點商品庫存，即管理庫存盤點單；
8. 定期盤點商品成本，即管理成本調價單；
9. 把商品從甲倉庫調撥到乙倉庫，即管理庫存調撥單；
10. 調撥商品出庫記錄，即管理調撥出庫單；
11. 調撥商品入庫記錄，即管理調撥入庫單。

7）財務員

負責資金的往來，會管理財務相關的事項有：

1. 管理資金賬戶；
2. 幫助客戶充值預收款，記錄每次消費或充值后，客戶預收款余額，即管理預收款單；
3. 客戶訂單未支付結算，會記錄應收款，即計算應收款；
4. 對銷售訂單的應收款進行收款，即管理收款單；
5. 充值到供應商的預付款，記錄每次付款或充值后，供應商預付款余額，即管理預付款單；
6. 采購訂單未支付結算，會記錄應付款，即計算應付款；
7. 對采購訂單的應付款進行付款，即管理付款單；
8. 定期進行快遞單對賬，即管理快遞對賬；
9. 記錄資金轉賬，即管理轉賬單；
10. 記錄資金往來，即記錄資金流水。

2. 系統用例

得到業務用例后，雖然能看到業務主流程的雛形，但要完成系統的閉環還需要站在系統的角度去補充用例，例如系統權限管理的需求，業務用例中并沒有體現出來。

系統用例也是需要獲得角色和用例，這個階段的用例粒度和上一步驟的業務用例保持一致，即管理一類事物。

開始獲取系統用例，我站在系統的角度，從三個方向分析系統需求：

1. 系統管理的需求
2. 系統易用性的需求
3. 系統擴展性的需求。

于是我列出了以下場景的需求：

1. 萬里牛ERP是一款SaaS產品，會服務多家公司的客戶，所以需要創建一家公司才可使用系統。
2. 每個系統都需要考慮權限管理，所以系統管理員需要維護角色權限，才能夠管理公司員工的權限。
3. 系統管理員需要創建員工，為員工分配賬號，員工才可以登錄系統開展工作。
4. 萬里牛ERP服務多家公司，各家公司的需求會存在差異性，需要做到高可配置化來支持差異化需求。
5. 每個用戶需要注冊、登錄、修改密碼等賬號相關的功能。
6. 用戶想及時得到訂單狀態更新、庫存預警等消息，方便跟進，提供消息通知功能。

根據上述場景的需求，獲取到系統用例，和業務用例放在一起，展示所有一級用例，如圖3。

圖3 一級用例

1）系統管理員

1. 需要創建公司才能使用該系統，由他管理公司；
2. 需要管理員工的權限，由他管理角色；
3. 需要維護員工信息，由他管理員工；
4. 需要配置系統以實現差異化的功能，由他管理系統配置。

2）全部用戶

1. 每個用戶都需要進行注冊登錄，進行管理賬號；
2. 每個用戶都需要獲取消息通知，支持消息通知。

3. 主流程分析

主流程就是按某種邏輯把主要的一級用例組合起來，歸納出幾條主流程，驗證是否可以實現業務目標。得到主流程可以對系統有全局的認知，也能輔助后續的對象分析。

電商日常主要處理兩大業務，采購和銷售。采購和銷售都有正向流程和逆向流程，即采購主流程、采購退貨主流程、銷售主流程、銷售售后主流程。這4條主流程中都會引起庫存更新和資金收支，所以除了商品出入庫過程，也要關注庫存變化和資金收支。

外加一條系統管理主流程，合計5條主流程。

1）采購主流程

主要是提交采購訂單，到貨后進行入庫，并更新庫存和支付貨款，如圖4。

圖4 采購主流程

• 提交采購訂單：①采購員在管理供應商模塊創建供應商，供采購訂單引用；②采購員在管理采購訂單模塊創建采購訂單，需要選擇在哪家供應商采購什么商品；
• 貨品入庫和更新庫存：③提交采購訂單后，倉庫管理員在管理庫存模塊增加該商品的在途數量；④待采購商品到貨后，倉庫管理員在管理采購入庫單模塊創建采購入庫單；⑤入庫后，倉庫管理員在管理庫存模塊增加商品庫存；
• 支付貨款：⑥財務員在管理資金賬戶模塊創建采購資金賬戶；⑦入庫后，采購員確認采購商品沒有問題，在管理采購結算單模塊創建采購結算單，支付金額為0，計算應付款；⑧付款日期到了，根據結算單，財務員在管理付款單模塊創建付款單進行付款；⑨付款后，財務員記錄資金流水。

2）采購退貨主流程

主要是提交采購退貨單，退貨商品出庫，并更新庫存和收回退款，如圖5。

圖5 采購退貨主流程

• 提交采購退貨單：①如果采購商品存在問題需要辦理退貨，采購員在管理采購退貨單模塊創建采購退貨單；
• 退貨商品出庫和更新庫存：②提交采購退貨單后，倉庫管理員在管理庫存模塊增加商品的鎖定數量，可用庫存等于【商品在庫數量】減去【鎖定數量】；③退貨商品出庫，倉庫管理員在采購退貨出庫單模塊創建采購退貨出庫單；④出庫后，倉庫管理員在管理庫存模塊減少商品庫存；
• 收回退款：⑤出庫后，采購員在管理結算單模塊創建采購退貨結算單，讓供應商退款；⑥若供應商沒有退款，根據采購退貨結算單，財務員在管理付款單模塊創建退款單收回退款；⑦退款后，財務員記錄資金流水。

3）銷售主流程

主要是處理銷售訂單，進行發貨，并更新庫存和訂單收款，如圖6。

圖6 銷售主流程

• 審核訂單和發貨：①售前客服在管理客戶模塊創建客戶，客戶供線下訂單引用；②售前客服在管理銷售訂單模塊創建線下訂單，或者審核線上淘寶訂單；③訂單審核通過，發貨員在管理銷售訂單模塊進行配貨、打包、發貨等工作；④發貨時，發貨員為訂單打印快遞單，用于快遞運輸；
• 訂單商品出庫和更新庫存：⑤新增銷售訂單后，倉庫管理員在管理庫存模塊增加商品的鎖定數量，可用庫存等于【商品在庫數量】減去【鎖定數量】；⑥發貨時，倉庫管理員在管理銷售出庫單模塊創建銷售出庫單，如果訂單之前沒有支付過，計算應收款；⑦出庫后，倉庫管理員在管理庫存模塊減少商品庫存；
• 訂單收款：⑧財務員在管理資金賬戶模塊創建銷售資金賬戶；⑨如果出庫后，訂單沒有支付過，根據銷售出庫單和應收款，財務員在管理收款單創建收款單進行收款；⑩收款后，財務員記錄資金流水。

4）銷售售后主流程

主要是審核銷售售后單，等退貨商品入庫后，更新庫存和售后單退款，如圖7。

圖7 銷售售后主流程

• 審核售后單：①如果有客戶發起退換貨售后單，售后客服在管理售后單模塊審核售后單；
• 退換貨商品入庫和更新庫存：②同意退換貨后，倉庫管理員在管理庫存模塊增加該商品的在途數量；③收到客戶寄來的退換商品，倉庫管理員在管理售后入庫單模塊創建售后入庫單；④入庫后，倉庫管理員在管理庫存模塊增加入庫商品庫存；
• 售后單退款或換貨：⑤收到退換貨的商品無誤后，如果是退貨，售后客服在管理售后單模塊操作退款，如果是換貨，售后客服在管理售后單模塊直接創建銷售訂單進行換貨；⑥如果退款，財務員記錄資金流水。

5）系統管理主流程

主要是創建公司并邀請員工加入公司，之后進行系統配置和維護基礎數據，如圖8。

圖8 系統管理主流程

1. 系統管理員首次登錄系統時創建公司；
2. 系統管理員在管理角色模塊創建角色和配置權限；
3. 系統管理員在管理員工模塊創建員工或邀請員工，并為員工分配角色；
4. 員工在管理賬號模塊接受邀請進入公司，并登錄系統；
5. 系統管理員在系統配置模塊配置自定義的參數；
6. 店長維護基礎數據供采購流程和銷售流程引用，在管理店鋪模塊創建店鋪、在管理商品模塊創建商品、在管理快遞公司模塊創建快遞公司、在管理倉庫模塊創建倉庫。

4. 對象分析

神盾局特工第四季里有一個概念是虛擬數字世界：框架（Framework），看過的朋友就很容易理解：軟件系統就是在計算機世界模擬現實世界，現實世界中的物體會映射成計算機世界里的對象。

這里使用面向對象分析方法（OOA），也是《大象—Thinking in UML》中的分析步驟之一，意圖是將現實世界中的物體映射成計算機世界中的對象，在系統中使用這些對象去解決需求。比如分析對象需要哪些屬性和功能來解決需求，在后續的步驟會詳細分析這些對象。

獲取到主要的對象，還可以幫助我們對系統有整體的認知。從以上的用例和主流程中進行抽象，我把得到的一級對象按業務分成6類：采購、銷售、快遞、系統管理、倉庫、財務，對象內容如圖9。

圖9 一級對象

上圖無法描述對象之間的關系，在下圖展示對象的關聯關系（有連線代表有關系）。

由于對象太多，關系線太多，無法繪制到同一張圖中，所以有些對象會重復出現。延續采購和退貨、銷售和售后、系統管理5個主流程，并補充了用例中提到的倉庫倉內管理、財務管理業務相關的對象關系。

①采購和采購退貨，包含采購入庫、采購退貨出庫、庫存更新、結算付款，如圖10；

圖10 采購和采購退貨相關對象

②銷售和售后，包含銷售出庫、售后入庫、庫存更新、收款，如圖11；

圖11 銷售和售后相關對象

③系統管理，如圖12左一；

④倉庫倉內管理，如圖12左二；

⑤財務管理，如圖12右一。

圖12 系統管理/倉庫倉內管理/財務管理相關對象

二、系統詳細設計

系統詳細分析，分析粒度變小，保持在增刪改查功能的粒度，目的是獲得全部系統用例。

第一節，把系統全局分析里的用例進行細化，即用例流程分析，可以發現基本的二級用例；

第二節，搜集所有的二級用例，即在流程中體現的用例以外，再補充其他必要的二級用例，例如刪除、導入、導出；

第三節，為了滿足高可配置化，還需要引入配置對象，例如商品自定義屬性；

第四節，找到配置對象的用例，我稱為三級用例，例如創建商品自定義屬性，以滿足配置需求。

1. 用例流程分析

用例流程就是用例的實現方式，是常用的需求細化方法，即細化上述一級用例的粒度，流程分析的目的是可以從中發現下級用例，現在開始分析流程，下圖列出一級用例和對應的流程圖，如圖13。

圖13 一級用例對應流程圖

圖14 基礎信息維護相關流程

圖15 采購相關流程

圖16 銷售相關流程

圖17-1 管理庫存流程

圖17-2 倉庫管理相關流程

圖18-1 預收款單和收款單流程

圖18-2 預付款單和付款單流程

圖18-3 財務相關流程

圖19 系統管理和用戶相關流程

2. 二級用例

完成流程分析后，已經獲得一部分細化的二級用例，但對于整個系統的閉環還是不夠的，這節就補充完善二級用例。

現在獲取的用例粒度，保持在主要對象的增刪改查即可。獲取二級用例從兩個角度分析，一是從上述的流程中進行提取用例；二是專注分析的對象，然后圍繞該對象設想一些場景以獲得需求，例如刪除、導出、打印、批量處理等在流程中找不到的需求，開始獲取二級用例。

沿著一級對象的6個業務類別：采購、銷售、快遞、系統管理、倉庫、財務，把業務類別中的對象一個個進行分析。

1. 采購

如圖20。

圖20 采購相關二級用例

• 供應商，補全供應商的新增、查看、修改、停用、啟用、刪除，另支持設置供貨商品、導入供應商、導出供應商、導入供貨商品；
• 采購訂單，補全采購訂單的新增、查看、修改、關閉，提供審核功能：提交審核、審核、查看審核信息，另支持復制、導入、導出、批量關閉、打印采購單；
• 采購入庫單，補全采購入庫單的新增、查看、修改，另支持快速導入、直接入庫、導出；
• 采購退貨單，補全采購退貨單的新增、查看、修改、關閉，提供審核功能：提交審核、審核、查看審核信息，另支持復制、導出；
• 采購退貨出庫單，補全采購退貨出庫單的新增、查看，支持直接出庫、導出；
• 采購結算單，采購結算有兩種類型：采購結算、采購退貨結算，提供新增采購結算單、新增采購退貨結算單，支持查看詳情、導出。

2. 銷售

如圖21。

圖21 銷售相關二級用例

• 店鋪，補全店鋪的新增、查看、修改、停用、啟用，需獲得淘寶店鋪的授權才可以同步線上的商品、訂單、售后單，所以支持店鋪授權；
• 客戶，補全客戶的新增、查看、修改，支持復制、導入；
• 銷售訂單，①訂單操作，創建銷售訂單有兩種方式：系統新增銷售訂單、下載店鋪線上訂單，另支持查看、修改、審核、打回、掛起、恢復、拆單、合單、提交異常、關閉訂單、導入訂單、批量修改、指定操作員；②發貨操作，支持整個發貨流程：生成快遞單、打印快遞單、打印發貨單、打印配貨單、配貨、揀貨、驗貨、打包、稱重、發貨；
• 銷售出庫單，補全銷售出庫單的新增、查看，支持打印出庫單、導出；
• 銷售售后單，創建銷售售后單有兩種方式：新增售后單、下載店鋪線上售后單，支持售后流程操作：查看詳情、同意換貨、同意退貨、同意退款、拒絕申請、審核、打回審核、入庫、換貨下單、關閉售后、售后完成，另支持批量操作：批量入庫、批量換貨下單、導入售后單、導出售后單、指定操作員；
• 銷售售后入庫單，補全銷售售后入庫單的新增、查看、修改，支持導入、導出。

3. 快遞

如圖22。

圖22 快遞相關二級用例

a）快遞公司，補全快遞公司的新增、查看、修改、停用、啟用，支持運費成本設置、導出；

b）快遞單，補全快遞單的新增、查看，支持打印快遞單。

4. 系統管理

如圖23。

圖23 系統管理相關二級用例

• 公司，補全公司的新增、查看、修改；
• 角色，補全角色的新增、查看、修改、刪除，支持編輯角色權限：修改操作權限、修改數據權限；
• 員工，①補全管理員維護員工的操作：新增、查看、修改、刪除、停用員工，還有其他新增用戶的方式：復制員工、邀請員工、同意員工加入，還有管理員設置：設為管理員、取消管理員、轉讓超級管理員；②另支持用戶視角的用例：激活員工賬號、注冊賬號并申請加入公司、登錄、忘記密碼、修改密碼、修改手機號；
• 消息，觸發系統規則后發送消息、用戶收到消息并查看；
• 商品，為了支持線上的業務，除了維護系統商品外，還需要關聯淘寶店商品，進行對應。①維護系統商品：補全商品的新增、查看、修改、刪除、停用、啟用，提供“復制商品”的快捷新增操作，提供批量、導入導出、打印操作：批量修改、導出條碼、打印條碼、導入商品、導入商品價格、導出商品；②關聯淘寶店商品：“下載線上商品”并“關聯系統商品”，系統沒有的商品支持直接根據線上商品“生成系統商品”，建立好關聯商品后，可以查看關聯商品、更換對應關系、解除對應關系、導出對應關系、導入對應關系。

5. 倉庫

如圖24。

圖24 倉庫相關二級用例

• 倉庫，補全倉庫的新增、查看、修改、停用、啟用，支持導出倉庫信息；
• 庫存，庫存是管理商品的數量，實際庫存代表實際倉庫中擁有的庫存量；在途庫存是尚在運輸途中，還未入庫的庫存數量；鎖定庫存是待出庫的數量，不可操作；①因此需要提供三類庫存的更新：增加鎖定庫存、減少鎖定庫存、減少實際庫存、增加在途庫存、減少在途庫存、增加實際庫存，②還需設置期初庫存：設置期初庫存、導入期初庫存、導出期初庫存，③提供基礎查看庫存、導出庫存功能，④庫存需要同步至淘寶店，提供上傳庫存功能；⑤庫存不足時發送預警消息，提供庫存預警功能；
• 庫存盤點單，補全盤點單的新增、查看、修改、審核、關閉，另支持導入、導出、打??；
• 成本調價單，補全調價單的新增、查看、修改、審核、刪除，另支持導入、設置期初成本均價；
• 調撥單，實際調撥，需要發快遞進行出入庫，虛擬調撥不需要發快遞，直接調整倉庫的庫存。支持新增實際調撥、新增虛擬調撥、查看調撥單、修改、關閉、審核、導入、導出、打印調撥單；
• 調撥出庫單，補全調撥出庫單的新增、查看，另支持打印調撥出庫單、導出；
• 調撥入庫單，補全調撥入庫單的新增、查看，另支持打印調撥入庫單、導出。

6. 財務

如圖25。

圖25 財務相關二級用例

• 資金賬戶，補全資金賬戶的新增、查看、修改、停用、啟用，支持設置初始余額、設為默認賬戶；
• 預收款單，預收款單有三種類型：充值、消費和提現，提供新增預收款充值單、新增預收款消費單、新增預收款提現單，另支持查看、打印、導出；
• 收款單，補全收款單的新增、查看，另支持打印收款單、收期初欠款；
• 預付款單，預付款單有三種類型：充值、消費和退回，提供新增預付款充值單、新增預付款消費單、新增預付款退回單，另支持查看、導出；
• 付款單，付款單有兩種類型：付款給供應商、付款給快遞公司，提供新增供應商付款單、新增快遞付款單，另支持查看、打印、付期初欠款；
• 快遞對賬單，補全快遞對賬單的新增（導入）、查看、修改、刪除，另支持結算、查看快遞單對賬結果；
• 轉賬單，補全轉賬單的新增、查看；
• 資金流水，資金流水有兩種類型：收入和支出，提供記收入流水、記支出流水，另支持查看和導出。

3. 補充對象

以上的二級用例，基本已經解決業務的需求，業務可以閉環流轉了。但還需要考慮一些非功能性需求，例如系統的配置需求、安全需求等。

萬里牛ERP提供的是SaaS服務，使用一套系統服務所有客戶，就需要提供強大的配置化功能，以滿足不同客戶的個性化需求，一般有兩個配置方向，一個是對象的上下級對象和屬性配置，二是配置一些用例場景的規則。

從之前獲取到的對象進行分析，聚焦每個對象的場景，得到以下對象有強烈的可配置化需求，并提取補充對象，如圖26。

圖26 補充對象

• 供應商，①供應商需要分組來歸類，引入供應商分組；②為了適應更多用戶各自的業務，引入供應商自定義屬性；
• 采購訂單，①審核采購訂單時，不同企業的規則不同，需要設置有幾級審核，以及每級的審核人員，引入采購審核規則；
• 店鋪，①店鋪需要分組來歸類，引入店鋪分組；
• 客戶，①為了適應更多用戶各自的業務，引入客戶自定義屬性；
• 銷售訂單，①不同企業的發貨流程可能不同，大企業發貨流程較長，小企業發貨流程較簡單，支持設置發貨流程，引入發貨流程；②訂單出庫會附帶發貨單，支持配置發貨單的內容項，引入發貨單模板；③訂單配貨時，需要配貨單，支持配置配貨單的內容項，引入配貨單模板；④為了加快銷售訂單審核的效率，希望無異常的訂單可以自動審核通過，引入訂單自動審核規則進行設置；⑤有些訂單需要拆單發貨，例如大件商品，或者商品在不同倉庫，希望可以自動拆單，引入自動拆單規則進行設置；⑥有些訂單可以合單進行發貨，例如同一客戶下了兩個地址一樣的訂單，希望可以自動合單，引入自動合單規則進行設置；
• 售后單，①用戶的售后單審核通過后，退貨地址希望自動匹配到某個最適合的收貨倉庫，引入退貨倉庫匹配規則；
• 快遞公司，①每個快遞公司都需要設置運費，而快遞的運費規則差別不大，為了方便設置運費時調用模板，引入運費模板；②用戶下單支付后，希望自動匹配到某個最適合的快遞，引入發貨快遞匹配規則；
• 快遞單，①銷售訂單出庫時，需要打印快遞單，但是每家公司的快遞單都不同，所以支持配置快遞單的內容項，引入快遞單模板；
• 商品，①店鋪的商品存在分類，引入商品分類；②不同商品的規格可能不同，例如衣服的規格是顏色、尺碼，手機的規格是顏色、內存，所以規格支持自定義，引入規格；③不同商品的品牌也不同，所以品牌支持自定義，引入品牌；④不同商品的計量單位也不同，例如飲料最小單位是1瓶，12瓶一箱，而零食最小單位是1包，25包一箱，所以計量單位支持自定義，引入計量單位；⑤為了適應更多用戶各自的業務，引入商品自定義屬性；
• 倉庫，①一個倉庫很大，一般會分為3級，分別是區域-庫區-庫位，區域和庫區統稱庫區，用于業務隔離和區分作業功能，引入庫區；②庫位就是倉庫中最小的定位標識，一般屬于某庫區下，引入庫位；③倉庫需要分組來歸類，例如屬于華東倉、華南倉等，引入倉庫分組；④用戶下單支付后，希望自動匹配到某個最適合的發貨倉庫，引入發貨倉庫匹配規則；⑤為了適應更多用戶各自的業務，引入倉庫自定義屬性；
• 庫存，①庫存中有二級用例是上傳商品庫存至線上店鋪，由于用戶可能同時運營多家店鋪，每家店鋪有訂單出庫了是會影響到其他店鋪的庫存的，需要配置上傳庫存的規則，所以引入上傳庫存規則，；
• 資金流水，①記錄資金流水時，需要記錄收支科目，為了適應更多用戶各自的業務，引入自定義收支科目；
• 最后，還考慮一些簡單的配置項，某些功能、規則的開關，例如出庫單、入庫單是否需要審核的開關。這樣簡單配置項有很多項，如果設計一大堆對象，但每個對象永遠只有一條記錄值，每增加一個配置項，就新增對象，還是永遠只存一條記錄值。所以這類配置項不適合分別單獨作為對象管理，需要引入一個通用的配置項對象進行管理，配置項一般是系統內置的規則，進行規則的開關、或者選用某種規則。

4. 三級用例

得到補充對象后，就繼續分析以上補充對象的用例，我稱為三級用例，這樣就完成該粒度層次的分析。

三級用例粒度是補充對象的增查改刪，例如新增商品分類，是新增商品分類供商品調用，達到配置的目標。該粒度的用例比較有規律，大概有新增、查詢、編輯、 刪除、復制、排序、停用、啟用、默認等功能。如圖27，列出了補充對象的用例。

圖27 三級用例

三、原型設計

系統原型設計，分析粒度變小，保持在頁面和元件交互，目的是獲得可交付的原型和標注。在原型設計前，需要梳理功能清單，一來可以展示系統的全貌，二來可以了解工作量和分配各模塊的執行人。

1. 功能清單

功能清單就是把上文分析的所有用例按某種展現邏輯組織起來，而這種展示邏輯就是導航設計，所以在列功能清單前先進行導航設計，然后把用例放置到相應的導航菜單中，即可完成功能清單。

導航設計的粒度保持在一個比較高的層級，可對照到上文系統全局分析中的主流程和一級用例，以及系統詳細設計中的補充對象，站在用戶的角度，把主流程、一級用例、補充對象進行分類結構化。

功能清單的粒度則保持在操作的層級，可對照到上文系統詳細設計中的二級用例和三級用例，站在用戶的角度，把二級用例、三級用例放置到相應的導航菜單中。這樣上文的所有分析就發揮作用了，功能清單被自然的推導出來了，如圖28。

在完成功能清單后，即完成產品規劃的部分，就可以按模塊分配給多名產品經理，設計各個模塊。

圖28 功能清單設計思路

1）導航設計

參考5個主流程：采購主流程、采購退貨主流程、銷售主流程、銷售售后主流程、系統管理主流程，可以看出電商日常高頻率的工作是銷售和采購，伴隨著倉庫和財務管理。采購工作的正向流程和退貨流程合并成一個菜單（采購），所以常用的業務菜單如圖29。

圖29 常用業務菜單

c常用業務菜單但在開展業務之前，需要設置基礎數據及系統配置，所以加入基礎信息、商品、設置、個人中心四個菜單放置系統管理主流程的功能。另外，店長需要關注經營情況，需要看報表，增加一個報表菜單，最終的一級導航菜單如圖30。

圖30 一級導航

把上文系統全局分析中一級用例，和系統詳細設計中的補充對象歸類放到一級導航下，就是完整的導航菜單，如圖31。

圖31 導航菜單

2）功能清單

在導航菜單的框架下，按模塊填充二級用例和三級用例。例如商品相關的常規功能（二級用例）放在商品信息菜單中，商品相關配置功能（三級用例）就放在各自的配置菜單下，如圖32。

圖32 商品功能清單

完整功能清單寫在騰訊文檔，請訪問 https://docs.qq.com/sheet/DQUdWUUtUeHl1VWpi。

說明：圖32和騰訊文檔中的功能清單是最終系統上的功能清單，所以菜單并不完全和導航設計中的一致，是在實際設計中根據用戶場景進行了調整。

2. 原型設計

不知道各位是否有這樣的困擾，在原型設計時會有這樣的卡頓，例如查詢列表頁要展示什么字段，創建頁要展示什么字段，就有被打斷的感覺。因此建議在開始原型設計之前，先根據對象的場景，分析對象的屬性。我個人習慣是先分析對象屬性再畫詳細的原型，這樣是比較順暢的。

1）對象屬性

分析對象屬性，并不是輕松的過程，每個屬性都有針對的場景，這里用“商品”這個對象舉例。提示：一種商品下可以有多種規格，也就是一個SPU下可以有多個SKU，例如一款手機，有白、灰、黑3種顏色，手機就是SPU，三種顏色就是3個SKU。

① 商品信息

• 名稱，商品名稱；
• 商品編碼，SPU級別編碼，有唯一性要求；
• 貨號，商品的款號，常用于記錄供應商的編碼；
• 分類，商品分類，用于區分商品類別；
• 品牌名稱，商品的所屬品牌；
• 單位，商品使用的計量單位，例如件、瓶、箱等；
• 備注，使用文本記錄商品的注意事項；
• 創建時間，商品創建時間；
• 更新時間，商品信息最新修改時間；

② 規格信息

• 規格名稱，SKU的名稱，例如一款手機，有白、灰、黑3種顏色；
• 規格編碼，SKU級別編碼，精確到每個規格的組合，有唯一性要求；
• 條碼，國際標準條碼，也可以使用內部自編條碼，用于內部識別；
• 圖片，規格商品圖片；
• 標準售價，當前零售價格；
• 批發價，給批發客戶的價格；
• 參考進價，進貨時可以參考的采購價格，系統第一次采購時可以默認帶出此價格作為參考；
• 重量，寄快遞稱重時會參考商品重量；
• 體積，貨品的體積大小，用于適配合適的快遞物流及運費計算；
• 長寬高，用于適配合適的快遞；

③ 自定義屬性：可根據各自業務添加自定義屬性進行標記；

可以看出，屬性很多，靠自己想是行不通的，這也是分析行業系統的價值，把行業系統常用的對象和屬性學來，也就入門這項業務了。

其他主要對象的屬性寫在騰訊文檔，請訪問https://docs.qq.com/sheet/DQVVBR2dTd2l4cUxs。

2）原型設計

最后進行原型設計，并編寫文字標注，補充業務規則和交互規則等。做PC web網頁設計時，這里推薦Element UI組件，記住常用的組件，會提高寫標注的效率。為了體會萬里牛ERP的規則和交互，我把萬里牛的頁面進行截圖，并標注了萬里牛的幫助文檔，原型放在藍湖，請訪問 https://lanhuapp.com/url/g9n4K。

【尾巴】各位看官，由于是在現成的系統上進行分解推導，因此會存在一些上帝視角，有些用例和對象出現的邏輯沒有那么順暢，請大家見諒。另外，這些邏輯不順暢的點，可能就是此類系統的行業知識，當你見過之后，也就認識和學習了這個行業的業務知識。

本文由 @王世翔?原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議