批量導入是B端後台産品中常用的一大功能，看起來簡單但是實際上做起來卻能夠發現裡面的坑有很多。作者結合自己的實戰經驗，與大家分享自己當時從0到1的設計過程，希望對你有所幫助。

批量導入是B端後台産品中非常常見的功能，乍看簡單，但實際做起來才發現裡面的坑着實不少。筆者根據自己的工作經曆，記錄整理了當時從0到1的設計過程。内容較長，耐心看完，相信你一定會有所收獲！

一、業務分析

在開始任何B端産品的功能設計前，都需要先分析這個功能對應的業務場景以及想解決的業務問題。

批量導入也不例外，一般導入功能都出現在需要單次錄入大批量數據的後台産品中。根據不同的場景會有不同的應用，需要結合用戶特征來一起分析，它們共同決定了導入功能的軟件功能流程和基本邏輯，例如：

1. 導入的數據是“新增”還是“覆蓋”？（即系統中已有數據的情況下，本次導入是在其後添加數據，還是完全覆蓋系統已有的數據）
2. 存在錯誤數據時，是忽略錯誤數據允許正常數據導入，還是全部打回重新導入？
3. 錯誤數據如何提示和處理，是在線修改，還是導出excel讓客戶修改後重新導入？
4. ······

這些都是在業務分析階段就需要思考的事情！

二、導入流程

導入功能大緻可以分為3個環節

1. 導入指引：讓用戶了解怎樣使用導入功能，并給出一份模闆文件；
2. 導入文件：上傳文件，并校驗錯誤數據；
3. 結果反饋：讓用戶知道本次導入的結果&影響。

其中2是最麻煩最複雜的一環，因為除了常規的文件類型和數據格式校驗外，部分B端産品可能還會有一些業務上的限制，需要考慮到導入的數據與現有的業務規則是否沖突，如果存在沖突，要以何種形式告知用戶哪些數據異常、要如何處理。

三、功能設計

3.1導入指引

3.1.1導入指引

如果導入過程并不複雜，隻需要給出下載模闆和上傳文件的入口即可；如果流程比較長，需要給出一條明确的步驟指引。

3.1.2模闆說明

對于一些重要的系統要求或者是不易察覺的設置，需要在表頭上進行說明，引導用戶正确的填寫數據。

3.2導入文件

3.2.1 導入進度

根據導入數據的規模和校驗規則的複雜程度，需要考慮不同的上傳進度提示。（這些最好提前與研發人員溝通好）

• 如果一般情況下上傳數據少，校驗規則也比較簡單，耗時短，可以給一個輕量的加載圖标；
• 如果單次導入的數據量大，或者校驗規則比較複雜，需要較長的時間，可以給一個上傳進度條。在這種情況下，導入任務可以設置成異步處理，即允許用戶關閉當前導入窗口，使用軟件的其他功能模塊。

3.2.2 文件解析和數據逐行校驗

一般導入文件的校驗分為兩個過程：

1）文件格式校驗

在寫入數據前，首先會校驗文件的基本格式是否符合規範，如果不符合則需提示用戶檢查上傳的文件并重新上傳。一般會有如下規則：

• 文件類型：支持的文件類型，如excel文件；
• 文件大小：是否超出規定的文件大小，如2M；
• 表頭：是否與模闆一緻；
• 行數：是否超過規定的上傳上限，比如最多允許導入1000行記錄，但上傳的文件有2000條記錄

2）數據内容校驗

文件校驗通過後，就開始校驗逐行表格中的數據内容，一般包括數據格式和業務規則的檢驗：

• 數據格式：字段的數據類型、長度，比如某個數量字段，用戶填了文字；
• 業務規則：記錄重複、不同字段之間的運算關系、主從邏輯判斷等；（比較複雜，會在文章末尾中的案例中提供示例參考）

3.3 導入結果反饋

1）導入結果

反饋用戶本次導入的結果狀态。

• 一般“覆蓋”導入（即導入的數據會覆蓋系統原有數據），對于錯誤數據，都是全部攔截并進行報錯提示；
• “新增”導入（即導入的數據會在系統原有數據基礎上進行新增），一般都隻允許正常數據導入，錯誤數據到出修改，這樣可以方便用戶快速定位到錯誤的字段上。

2）錯誤數據修改

導入失敗的數據可以支持單獨導出，并在excel中對異常字段進行特别标注，也需附上“錯誤原因”。（也有文章提過部分情況下可以讓用戶在線修改，但個人認為這種方式并不好，因為對于由同一個錯誤引起的大量異常數據，修改效率很低。如果考慮批量編輯功能，開發成本又會變得很高）

3）導入曆史（非必須）

部分特殊情況還需要記錄導入曆史，方便後續查看。

四、分析案例

4.1 産品介紹

一款面向小微企業&個體工商戶的ERP進銷存管理軟件，幫助他們實現業務的數字化管理。（說人話就是，倒買倒賣的中間商每天向哪個供應商買了哪些商品？又向哪個客戶賣了哪些商品？倉庫裡現在又還有哪些貨、數量多少？······

成千上萬個商品在不同時間、不同客戶、不同供應商中積累的價格、數量、金額等信息是海量的，光靠腦子不可能記得住，更不用說去分析一個周期内的銷售額、利潤！因此軟件就是幫助這些中間商記錄商品流通過程中的信息數據，更好地掌握生意狀況）

4.2 需求背景

我是一名批發商，上次向某個供應商訂了一批貨，這次供應商把貨送了過來，還附了一張單據（可能是電子單據，也可能是紙質單據，不同供應商給的單據格式也不一樣，如下圖所示），你确認沒問題後，把這批貨搬進倉庫，然後把這個單據錄到系統中，一個個選擇商品肯定太麻煩了，于是你希望有一個導入功能，幫你把這些數據批量處理掉。

4.3 業務背景

這裡提兩個比較重要的概念，方便讀者更好的理解下面的分析過程。

1）商品唯一性标識

商品條碼一般是商品的唯一标識，由商品國際物品編碼協會賦予，包含該物品的生産國、制造廠家、商品名稱、生産日期、類别、日期等許多信息，在商品流通有廣泛的應用。（簡單來說就是你去便利店買東西結賬，店員用掃碼槍“嘀”的那塊地方，如下圖）

但是對于部分行業，流通的商品大多是非标品，例如茶葉、部分食品、五金件等，也沒有條碼的概念，隻能通過一定的規則（通常是商品名稱）去标識一個唯一的商品。

而我們軟件定位是泛行業的軟件，所以商品條碼是商品最高級的唯一标識，卻又不是一個必要信息。除此之外，商品名稱&規格組合也是一個商品的唯一标識，不可重複。

2）單位

商品單位容易理解，計量商品的标準量，如個、件、箱、米等。值得注意的是，部分商品在實際業務中可能同時存在多個單位，例如300ml罐裝的可樂，1“瓶”3元，論“箱”（1箱=24瓶）銷售時，1“箱”70元，即同一商品不同單位之間存在換算關系，所以這些商品在商品管理上略微複雜，導入功能設計上也需要考慮到這種情況。

4.4 分析過程

1）用戶分析

在過往的用戶調研中，我們發現用戶大多是四十左右的中年人，文化水平普遍偏低，對于大篇幅的文字說明都不太敏感，可能導入出錯的概率會比較高。因此除了功能框架層設計上要簡單清晰，還要強化對異常情況的處理提示，讓用戶一眼就知道導入失敗原因在哪以及如何處理。

2）業務場景分析

進貨場景下，可能同時會進一些新商品和舊商品（即軟件中沒有/已有的商品資料），進新商品會新建商品資料，進舊商品會更新庫存數量，綜合考慮決定“商品名稱”和“數量”為必填字段，其他為非必填字段；另外導入數據規模上，産品介紹有提到軟件面向的是小微企業主，他們的進貨規模根據調研結果，單次大多不超過100個sku，所以導入限制在200~1000行數據就足夠了。

3）可能出錯情況

由于新舊商品同時存在，因此要考慮的難點除了舊商品與已有商品資料的沖突，還有建立新商品資料的業務規則沖突。需要分别窮盡所有的出錯情況，并根據出錯場景，來決定哪些需要軟件自動處理這些錯誤，哪些需要導出讓用戶确認修改這些錯誤。

分析到這裡，差不多一個完整的導入功能流程就呼之欲出了。

4.6 功能流程圖

4.7 原型設計&說明

這裡就不貼原型了，網上資源多的是。主要講講其中的核心部分：數據内容的逐行校驗與提示。

由于公司保密制度規定非常嚴格，無法把PRD全部貼上來，這裡簡單提幾個可能的業務規則校驗供大家參考：

• 不同供應商品名：系統商品資料存在這個條碼，但對應的商品名稱不同（比如一罐可口可樂，供應商A叫“可口可樂”，你錄到系統裡也命名為“可口可樂”，但你這次又從供應商B那裡進了這個商品，他給你的單據上顯示名稱為“可口可樂300ml”）
• 舊商品新單位：商品條碼、名稱與系統一緻，但該商品沒有此單位
• 運算關系沖突：多個字段之間存在運算關系，但用戶上傳的數據不符合計算邏輯，比如單價*數量≠金額
• ······

值得注意的是，上面提到的業務規則校驗，并不是所有都要當錯誤處理，有些可以讓程序自動處理，提高用戶的産品體驗。

本文由 @飛魚 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部