(網(wǎng)經(jīng)社訊)談及賬號及權(quán)限的問題，更多人一開始會直接想到的是登錄注冊的交互體驗及安全性，但對于B2B電商平臺來說，會遇到更多的場景，對于功能的要求也比較重視。本文主要從B2B電商的角度，講述賬號及權(quán)限設(shè)計的問題，以及我所踩過的那些坑。
一、賬號體系
B2B電商平臺的交易角色由采購商，供應(yīng)商和平臺三方構(gòu)成。
在項目初期，由于產(chǎn)品未參與數(shù)據(jù)庫設(shè)計的過程，所以數(shù)據(jù)庫設(shè)計者更多的是憑借已知的需求及經(jīng)驗進行數(shù)據(jù)庫的設(shè)計，采購商的賬號方面主要是由兩個表組成：賬號表和采購商信息表；賬號與采購商信息之間的關(guān)系為1：n的關(guān)系。
但是隨著項目的上線及推廣，該套賬號體系被證明不能滿足業(yè)務(wù)部門的需求。在我們原來的認(rèn)知中，一個采購商（即一個企業(yè)）作為一個購買單位，如果有多個人負責(zé)采購的情況下，多個賬號共享一個采購商的信息即可。但是后來我們的采購商出現(xiàn)的連鎖店，而且連鎖店處于采購成本和管理的因素，更多的是由專門的采購人員或老板進行統(tǒng)一的采購，因此賬號與采購商的關(guān)系變成了n：n的關(guān)系
因此衍生出如下幾個問題：
1. 數(shù)據(jù)庫的設(shè)計
根據(jù)需求一個采購商可能會存在多個采購人員，同一個采購可能需要同時負責(zé)多家店的采購，因而賬號和采購商的關(guān)系變?yōu)槎鄬Χ嗟年P(guān)系；
實際上由于前期設(shè)計錯誤，導(dǎo)致重新進行數(shù)據(jù)庫的設(shè)計不再可能，只能基于之前的數(shù)據(jù)結(jié)構(gòu)進行修改，這里我們將原來的一對多關(guān)系的兩個表整體看做一個采購商表，新增一個賬號表和一個關(guān)系表即可完成設(shè)計
另外，其他業(yè)務(wù)模塊對于賬號/采購商的引用需要進行重新的檢查，在業(yè)務(wù)邏輯上，一個采購實體的性質(zhì)是采購商而不是賬號。所以和采購業(yè)務(wù)相關(guān)的業(yè)務(wù)模塊如：訂單、優(yōu)惠券、文章消息、購物車商品等均與采購商id關(guān)聯(lián)，而與賬號相關(guān)的業(yè)務(wù)需要與賬號Id關(guān)聯(lián)（與新的賬號表中的id關(guān)聯(lián)），如：昵稱、登錄賬號、密碼等。
2.業(yè)務(wù)流程設(shè)計
由于多個賬號共用一個采購商，在有員工離職或其他情況下，必須對于采購商的某個賬號進行關(guān)系的解綁，所以必須有一個賬號能夠管理該企業(yè)的其他賬號。所以對于直接創(chuàng)建新企業(yè)的賬號，將這個賬號賦予一定的權(quán)限，將其定義為管理員賬號。
對于非管理員賬號，可以由管理員賬號直接添加，這樣可以省去注冊的麻煩也可用于批量注冊賬號。同時業(yè)務(wù)設(shè)計中也需要考慮登錄同一個賬號后，在多個采購商之間進行切換使用的問題。
（1）新增賬號并綁定企業(yè)
注冊新賬號之后，可以直接繼續(xù)創(chuàng)建新的企業(yè)，創(chuàng)建新企業(yè)后，該賬號將自動成為企業(yè)的管理員。同時也可直接進入頁面瀏覽之后，再創(chuàng)建新的企業(yè)。另外，也可直接由企業(yè)管理員添加進入該企業(yè)（有點類似于社交中群成員和群主的概念）。
（2）老賬號綁定企業(yè)
已注冊的賬號，可以選擇創(chuàng)建新企業(yè)或由管理員添加進入已存在的企業(yè)。
經(jīng)驗教訓(xùn)總結(jié)：在需求的初期，一定得做好需求的邏輯模型的設(shè)計，梳理其中的角色（實體），屬性及實體之間的關(guān)系，以供數(shù)據(jù)庫設(shè)計人員進行物理模型的設(shè)計，否則在后期會花費更多的成本進行修改。
二、權(quán)限設(shè)計
現(xiàn)在市面上大多數(shù)電商網(wǎng)站對于權(quán)限的設(shè)計已日趨完善，尤其是在商品瀏覽方面，登錄與不登錄沒有什么區(qū)別，甚至在下單支付環(huán)節(jié)大多數(shù)電商網(wǎng)站已經(jīng)可以做到不用登錄即可下單，這方面不做過多說明
但是在to B端的電商網(wǎng)站中，由于對于不同地區(qū)，不同用戶等級的采購商來說，看到的價格是不一樣的。甚至有些電商網(wǎng)站為了保證自家商品的隱私性（是否有該商品，商品的價格是否有優(yōu)勢），在不登錄的情況下都不可以瀏覽商品。另外對于不同的行業(yè)，to B端的電商上的采購商必須提交相應(yīng)的資質(zhì)給平臺進行審核才能進行采購。
因此，to B端的電商網(wǎng)站需要在用戶的體驗和業(yè)務(wù)需求上進行一些權(quán)衡，什么情況下能瀏覽？什么情況下能看到價格？什么情況下能進行下單支付？
在我們前期的系統(tǒng)設(shè)計中，索性直接一刀切，用戶打開APP直接進入登錄頁面，在未登錄且關(guān)聯(lián)采購商資質(zhì)審核通過前不能進行進入商城主頁面。但隨著業(yè)務(wù)的發(fā)展，在APP的推廣過程中，如果用戶看不到商城的商品，采購商不太愿意注冊一個不了解的產(chǎn)品。
因為這中間涉及資質(zhì)的審核，需要填寫企業(yè)資料、上傳證件，會比較麻煩，所以這種矛盾變得越來越激烈。因此，在后期我們對于用戶的權(quán)限進行的重新的調(diào)整。
權(quán)限設(shè)計邏輯如下：
根據(jù)登錄狀態(tài)和采購商狀態(tài)，將權(quán)限分為以下幾層：
未登錄賬號的權(quán)限；
已登錄賬號，但未綁定采購商的權(quán)限；
已登錄賬號且已綁定采購商，但是采購商未審核通過；
已登錄賬號且已綁定采購商，采購商資質(zhì)審核已通過。
對于不同的權(quán)限等級，將頁面內(nèi)容按照不同權(quán)限等級進行歸類：
不需登錄即可看到的內(nèi)容，主要是商品列表中的商品，注冊相關(guān)頁面等；
需登錄但是不需要采購商信息的內(nèi)容，如：賬號名，昵稱等；
需要登錄且需要采購商信息，但采購商為未審核通過的狀態(tài)所看到的內(nèi)容；
需要登錄且需要賬號信息才能看到的內(nèi)容，如：商品價格，購物車等。
按照以上邏輯對于權(quán)限進行劃分之后，就可對各個頁面進行整體的設(shè)計了。在我們的實際開發(fā)過程中，由于之前是只有已登錄且關(guān)聯(lián)采購商審核通過才可進入商城主頁面。所以若需要對權(quán)限邏輯進行從新設(shè)計，那么各個頁面調(diào)取接口的邏輯必須修改（這部分地方值得深入思考）。
所以最后我們對于未登錄，采購商資質(zhì)未審核通過權(quán)限涉及的相關(guān)頁面重新設(shè)計了一套（頁面的復(fù)制粘貼，調(diào)取獨立的接口），但這樣的弊端是后續(xù)有一部分頁面的修改迭代都必須同時改兩處地方，而且頁面的體驗也會損失很大一部分。
經(jīng)驗教訓(xùn)總結(jié)：由于前面直接在登錄頁面進行一刀切，在后期對權(quán)限邏輯進行調(diào)整的時候，導(dǎo)致涉及的東西太多而不敢直接在已有的基礎(chǔ)上進行修改。所以我們在做權(quán)限架構(gòu)設(shè)計的時候，就算當(dāng)初的需求是這樣要求的，也需要考慮后續(xù)需求修改的拓展性。
三、前端展示頁面相關(guān)設(shè)計
登錄注冊流程：與C端的電商的登錄注冊模塊不同，除了賬號的申請之外還要考慮采購商企業(yè)資料的提交（也提供跳出路程的出口）。
賬號的管理：上文說到的每個采購商的管理員需要管理子賬號，所以提供添加子賬號的頁面（不存在的子賬號則直接先生成一條賬號信息），并可將該賬號從采購商中刪除。
創(chuàng)建新采購商：提供兩條路徑：一個是在注冊時，一并完成新采購商的創(chuàng)建，一個是登錄后，專門提供一個入口創(chuàng)建新采購商。
切換所屬的企業(yè)：采購商可以切換當(dāng)前所屬的企業(yè)，以方面單獨為每個企業(yè)進行采購。（來源：人人都是產(chǎn)品經(jīng)理 文/不橈 編選：電子商務(wù)研究中心）
