一、前言：項(xiàng)目背景

客戶情況：一家主要通過電商平臺銷售日用清潔用品的企業(yè)，淘寶垂直品類第一，銷售模式包括自營和代理商兩種模式，平時用旺店通ERP進(jìn)行訂單管理和財務(wù)結(jié)算。并且客戶公司有小的開發(fā)團(tuán)隊(duì)，可以自行進(jìn)行運(yùn)維和準(zhǔn)備項(xiàng)目環(huán)境，需求主要和客戶開發(fā)進(jìn)行確認(rèn)。

客戶需求：需要一套能夠與原旺店通ERP系統(tǒng)打通的拓展系統(tǒng)（即供應(yīng)鏈管理平臺），將渠道創(chuàng)建的訂單同步到旺店通ERP中，其中貨品、店鋪等信息需要從旺店通ERP中同步。

項(xiàng)目周期：14個工作日（2周半）

參與人數(shù)：2人（1產(chǎn)品經(jīng)理，1全棧）

項(xiàng)目開始.....1 2 3 go！

二、第1-2天：需求調(diào)研

項(xiàng)目合同簽訂后，第一時間與客戶商定需求調(diào)研時間，地點(diǎn)，方案。然后抓緊安排調(diào)研工作。

本項(xiàng)目（供應(yīng)鏈管理平臺）由于項(xiàng)目需求其實(shí)并不會特別復(fù)雜，所以我們安排了2天的調(diào)研周期，并前往客戶現(xiàn)場進(jìn)行當(dāng)面確認(rèn)。

調(diào)研產(chǎn)出：織信低代碼中需要搭建的系統(tǒng)分為渠道端和運(yùn)營端兩個操作端口，需要與旺店通ERP進(jìn)行對接。

運(yùn)營端：由公司內(nèi)部人員參與，對渠道和訂單信息進(jìn)行管理；

渠道端：可支持渠道商登陸，并且和旺店通ERP的訂單操作行為進(jìn)行實(shí)時數(shù)據(jù)同步；

除了基礎(chǔ)的下單行為外，還需要具備渠道錢包功能，渠道發(fā)起的退貨會以渠道錢包的方式進(jìn)行退回，錢包中的金額可在后續(xù)的支付中進(jìn)行抵扣。（這是去現(xiàn)場調(diào)研到的一個額外延伸需求，但是評估下來低代碼實(shí)施并不會增加太大的工作量，就額外補(bǔ)充了一下）

下面是我們根據(jù)與相關(guān)業(yè)務(wù)人員訪談后，梳理的業(yè)務(wù)流程圖。和傳統(tǒng)開發(fā)一樣，這一步并不能節(jié)省，一個邏輯完備、步驟詳細(xì)的流程圖，將會在后續(xù)節(jié)省大量的開發(fā)時間。

三、第3-4天：模型梳理

供應(yīng)鏈管理平臺的需求調(diào)研完成后，和客戶確認(rèn)了詳細(xì)的業(yè)務(wù)流程邏輯，我們就要開始需求梳理工作。

所謂磨刀不誤砍柴工。

對于需求的梳理和分析，以及確定對應(yīng)技術(shù)方案，是開發(fā)系統(tǒng)非常重要的一步，低代碼的開發(fā)模式也不例外。

1、低代碼模型梳理：

低代碼開發(fā)前期模型梳理主要分為：“功能模塊——表模型——字段設(shè)計”

這也對應(yīng)了低代碼的“應(yīng)用——模塊（數(shù)據(jù)表）——字段的結(jié)構(gòu)”。

先整理出模塊清單：

然后再逐個模塊進(jìn)行模型梳理：

2、原型及功能設(shè)計階段

完成模型和接口的梳理工作后，進(jìn)入原型及功能設(shè)計階段。

雖然有了低代碼的快速開發(fā)和配置，我們還是采用了傳統(tǒng)的原型設(shè)計工具進(jìn)行原型繪制，這樣做的主要目的在于，能夠盡可能和客戶的需求進(jìn)行貼合匹配。而不會受到低代碼平臺的束縛（當(dāng)然這也是基于織信低代碼平臺強(qiáng)大的定制化能力才支持做到這一點(diǎn)）。

在這里，我們會讓產(chǎn)品經(jīng)理專門針對織信低代碼做了一個組件庫，可以提升交互的速度，盡量貼合低代碼交互。

對于某些頁面有特殊需求， 我們還可以完全支持定制化的設(shè)計，并且可以通過平臺的自定義頁面實(shí)現(xiàn)。

最后，很關(guān)鍵的一步，將所有的模型和原型與用戶進(jìn)行確認(rèn)。一旦確認(rèn)完畢，就可以開始我們的低代碼技術(shù)評審階段，確定本次開發(fā)技術(shù)實(shí)現(xiàn)方案。

四、第5天：技術(shù)評審

難點(diǎn)一：旺店通ERP數(shù)據(jù)對接方案

在織信低代碼中建立了ERP訂單和訂單兩個模塊。其中ERP訂單調(diào)用旺店通ERP的查詢訂單接口，定時增量獲取旺店通ERP的訂單信息，其表結(jié)構(gòu)與查詢訂單接口的返回參數(shù)保持一致。

訂單表存儲的是在織信低代碼中創(chuàng)建的訂單信息，完成創(chuàng)建后會調(diào)用旺店通ERP的創(chuàng)建訂單接口將訂單信息傳到旺店通ERP中，在訂單表里可以根據(jù)客戶需要自行定義表結(jié)構(gòu)，只需要保證創(chuàng)建訂單接口中傳入?yún)?shù)的必填字段都能正確傳入即可。因?yàn)樵谟唵魏虴RP訂單中，都有原始訂單號，該字段可作為唯一標(biāo)識符，將ERP訂單的信息同步到訂單當(dāng)中，例如訂單狀態(tài)、物流單號等，滿足數(shù)據(jù)同步需求。

在實(shí)際使用時，用戶只需要操作訂單表，就能完成下單和同步訂單狀態(tài)的操作。

難點(diǎn)二：各模塊數(shù)據(jù)隔離方案

渠道商管理系統(tǒng)分為渠道端和運(yùn)營端兩個操作端口，作為運(yùn)營端可查看到自己管理渠道的所有信息，作為渠道端只能查看到自己渠道的所有信息。

基于上述需求，我們首先使用視圖的方式建立渠道的操作模塊。并且通過自動化設(shè)置用戶的擴(kuò)展參數(shù)，將渠道用戶的渠道id綁定在用戶信息中，后續(xù)只需要在渠道操作的模塊中加入統(tǒng)一的數(shù)據(jù)過濾即可實(shí)現(xiàn)渠道端的數(shù)據(jù)隔離。

對于運(yùn)營端，我們同樣將運(yùn)營可查看的渠道信息通過自動化設(shè)置到用戶擴(kuò)展信息當(dāng)中，在各個可操作模塊中加入數(shù)據(jù)過濾即可實(shí)現(xiàn)運(yùn)營端的數(shù)據(jù)隔離。

難點(diǎn)三：渠道信息創(chuàng)建/修改審核

客戶希望能發(fā)起修改時，其基礎(chǔ)信息、組合裝和合同可以整體進(jìn)行編輯和報錯，發(fā)起后由財務(wù)統(tǒng)一審核，審核通過后可將修改內(nèi)容同步到渠道信息中。

基于該需求，我們重新做了一套渠道信息表用于存儲修改內(nèi)容，并且通過工作流實(shí)現(xiàn)審批功能，審批通過后才將修改后的數(shù)據(jù)復(fù)制到渠道信息中。

難點(diǎn)四：下單頁面特殊交互的調(diào)整

客戶希望在下單時選擇商品的時候，是以卡片的形式展示商品內(nèi)容，并且整個下單過程分為兩步，先選擇商品再輸入收貨地址。

以卡片的形式展示商品：我們將原本的查找列表以表單的形式進(jìn)行了展示，同時默認(rèn)加載出客戶可下單的商品，客戶填入了數(shù)量的才是需要下單的物品。

下單分步：下單的動作是創(chuàng)建數(shù)據(jù)，所以將貨品和選擇收貨地址進(jìn)行分組，然后開啟在創(chuàng)建時分步展示即可。

至此，基于客戶供應(yīng)鏈管理業(yè)務(wù)的需求梳理部分已全部完成，下一階段正式進(jìn)入織信低代碼的開發(fā)環(huán)節(jié)。

因篇幅有限，請關(guān)注我們，下篇內(nèi)容將持續(xù)給大家分享項(xiàng)目實(shí)戰(zhàn)的第二階段：低代碼功能開發(fā)。

織信低代碼已經(jīng)累計為20多個行業(yè)，30000+企業(yè)用戶提供低代碼技術(shù)支持。在不同的行業(yè)，提出深度場景解決方案，致力于成為企業(yè)數(shù)字化轉(zhuǎn)型首選方案。