產(chǎn)品復(fù)盤:從0到1設(shè)計(jì)業(yè)務(wù)系統(tǒng)
從事基因檢測(cè)產(chǎn)品經(jīng)理崗位一年多,工作重心逐漸從前端產(chǎn)品設(shè)計(jì)轉(zhuǎn)移到后端的業(yè)務(wù)系統(tǒng)產(chǎn)品設(shè)計(jì)。由于行業(yè)的特殊性,很難在市面上找到符合公司實(shí)際業(yè)務(wù)需求的第三方業(yè)務(wù)管理系統(tǒng),所以公司決定自己內(nèi)部團(tuán)隊(duì)開發(fā)符合自己實(shí)際業(yè)務(wù)需求的業(yè)務(wù)系統(tǒng)。通過復(fù)盤這次的業(yè)務(wù)系統(tǒng)搭建過程,希望能沉淀出自己的一些方法論和思考。
一、為什么要由專業(yè)的PM設(shè)計(jì)業(yè)務(wù)系統(tǒng)
很多公司特別是創(chuàng)業(yè)公司都低估了系統(tǒng)架構(gòu)設(shè)計(jì)的重要性,特別是前期業(yè)務(wù)系統(tǒng)的架構(gòu)地基沒打好,業(yè)務(wù)模塊設(shè)計(jì)隨意和混亂,新增的功能隨意擺放,不僅導(dǎo)致業(yè)務(wù)人員使用系統(tǒng)時(shí)產(chǎn)生困惑,同時(shí)還會(huì)導(dǎo)致開發(fā)人員編程設(shè)計(jì)混亂。以至于隨著公司的業(yè)務(wù)發(fā)展,后期重構(gòu)系統(tǒng)時(shí)所花費(fèi)的精力和成本都是難以想象。
企業(yè)創(chuàng)新的業(yè)務(wù)模式,決定了必須要有一批業(yè)務(wù)系統(tǒng)設(shè)計(jì)人員,參與理解公司特殊的業(yè)務(wù)訴求,利用互聯(lián)網(wǎng)產(chǎn)品的開發(fā)方式和方法,快速、合理的設(shè)計(jì)系統(tǒng)支持業(yè)務(wù)。
業(yè)務(wù)系統(tǒng)的產(chǎn)品經(jīng)理,要深刻理解公司的經(jīng)營(yíng)管理、業(yè)務(wù)模式,參與制定業(yè)務(wù)決策,才能設(shè)計(jì)合理、靠譜的業(yè)務(wù)系統(tǒng)。本次分享通過復(fù)盤搭建渠道分銷平臺(tái),談一談PM如何參與設(shè)計(jì)業(yè)務(wù)系統(tǒng)的方法。
業(yè)務(wù)管理系統(tǒng)設(shè)計(jì)流程
1、業(yè)務(wù)方案設(shè)計(jì):明確業(yè)務(wù)角色和工作流
業(yè)務(wù)調(diào)研
設(shè)計(jì)業(yè)務(wù)系統(tǒng),必須要透徹理解業(yè)務(wù)現(xiàn)狀,而理解業(yè)務(wù)最好的方法:
- 第一,有機(jī)會(huì)參與輪崗到業(yè)務(wù)環(huán)節(jié),親身體會(huì)業(yè)務(wù)人員的工作狀態(tài);
- 第二,調(diào)研訪談。在調(diào)研之前,需要提前制定訪談?dòng)?jì)劃,安排好訪談的對(duì)象即參與的業(yè)務(wù)人員,明確調(diào)研目的,提前準(zhǔn)備好問題,讓訪談更加高效。
組織架構(gòu)
通過業(yè)務(wù)調(diào)研,對(duì)業(yè)務(wù)體系大體上有一定的了解之后,梳理出組織結(jié)構(gòu)圖:
組織結(jié)構(gòu)將影響業(yè)務(wù)系統(tǒng)設(shè)計(jì)的以下幾個(gè)方面:
- 組織結(jié)構(gòu)的層級(jí)決定業(yè)務(wù)系統(tǒng)的工作流,間接決定業(yè)務(wù)流程;
- 組織結(jié)構(gòu)是否清晰決定權(quán)限劃分是否正確;
業(yè)務(wù)流程
通過調(diào)研,梳理出對(duì)于渠道銷售的業(yè)務(wù)流程,例如下圖:
需要特殊說明的是:
- 如果業(yè)務(wù)部門已經(jīng)有成熟的業(yè)務(wù)流程,落地可行且執(zhí)行了一段時(shí)間后,效果不錯(cuò)。PM在前期規(guī)劃上先把這個(gè)方案搬到線上,基于目前的工作流設(shè)計(jì)功能。
- 如果業(yè)務(wù)部門還沒有落地可行的業(yè)務(wù)方案,PM就需要和業(yè)務(wù)負(fù)責(zé)人一起梳理、制定業(yè)務(wù)流程,梳理業(yè)務(wù)中有哪些業(yè)務(wù)角色參與工作?各個(gè)角色參與了哪些工作階段?業(yè)務(wù)角色是否跨部門協(xié)作?業(yè)務(wù)環(huán)節(jié)是否可以通過部門進(jìn)行拆分?
- 如果涉及多個(gè)部門協(xié)同及分工,那么在確定業(yè)務(wù)流程時(shí)及時(shí)與多部門業(yè)務(wù)負(fù)責(zé)人溝通確認(rèn)
業(yè)務(wù)訴求分析
基于目前的業(yè)務(wù)流程,需要和業(yè)務(wù)負(fù)責(zé)人確定業(yè)務(wù)系統(tǒng)現(xiàn)階段需要解決的問題,實(shí)現(xiàn)對(duì)應(yīng)的功能,如下:
- 支持將渠道信息從線下紙質(zhì)合同錄入到線上系統(tǒng)中,優(yōu)先級(jí):高;
- 支持二級(jí)分銷模式,優(yōu)先級(jí):高;
- 支持對(duì)賬報(bào)表,優(yōu)先級(jí):高;
- 支持賬期提醒和預(yù)付款模式,優(yōu)先級(jí):低;
- 處于業(yè)務(wù)流程中必不可少的環(huán)節(jié)定為較高優(yōu)先級(jí),擴(kuò)展功能和針對(duì)部分客戶的小眾功能,定為較低的優(yōu)先級(jí)。
經(jīng)驗(yàn)總結(jié)
- 必須要有標(biāo)準(zhǔn)化的業(yè)務(wù)流程,明確系統(tǒng)邊界,這一點(diǎn)一定要和業(yè)務(wù)負(fù)責(zé)人確定清楚。標(biāo)準(zhǔn)化=高效率。
- 了解業(yè)務(wù)中參與的角色、包含哪些關(guān)鍵工作節(jié)點(diǎn),工作流程是怎樣的?
- 如果有必要,在最終與業(yè)務(wù)負(fù)責(zé)人敲定業(yè)務(wù)方案時(shí),最好拉上技術(shù)負(fù)責(zé)人,一方面,有利于技術(shù)人員提前理解業(yè)務(wù),另一方面,技術(shù)負(fù)責(zé)人可以站在技術(shù)角度為技術(shù)選型做好準(zhǔn)備。
- 業(yè)務(wù)人員作為系統(tǒng)的用戶,相對(duì)來說,更能明確自己的需求,但是在溝通交流中,業(yè)務(wù)負(fù)責(zé)人可能會(huì)提出較為復(fù)雜,認(rèn)為“完美”的系統(tǒng),這個(gè)時(shí)候PM要過濾出重要的需求通過MVP等方法排出需求優(yōu)先級(jí),縮短研發(fā)周期。
- 不要依賴業(yè)務(wù)方提需求,要幫業(yè)務(wù)方想方案,由于角色的不同、思維方式的不同,業(yè)務(wù)方同學(xué)只能提出自己最終想要的功能,提出模糊的功能需求,并不一定能提出自己真正的需求,產(chǎn)品經(jīng)理需要主動(dòng)思考業(yè)務(wù)中的問題,并形成業(yè)務(wù)需求。
- 擴(kuò)展性和效率之間需要做權(quán)衡,有的時(shí)候想得太多容易給自己和團(tuán)隊(duì)挖坑,所以平衡擴(kuò)展性和效率是門藝術(shù)
2、系統(tǒng)架構(gòu)設(shè)計(jì):業(yè)務(wù)模塊拆分和權(quán)限劃分
業(yè)務(wù)模塊
通過調(diào)研對(duì)業(yè)務(wù)有了整體的認(rèn)識(shí),與相關(guān)的業(yè)務(wù)人員確定了業(yè)務(wù)方案,接下來就是結(jié)合業(yè)務(wù)訴求與目標(biāo),梳理出整體的業(yè)務(wù)系統(tǒng)的架構(gòu)圖,如下:
經(jīng)過分析,這次業(yè)務(wù)系統(tǒng)迭代主要的目的是為了支持渠道銷售的業(yè)務(wù)訴求,系統(tǒng)已經(jīng)有底層的業(yè)務(wù)模塊可以直接復(fù)用,減輕了新平臺(tái)的實(shí)現(xiàn)難度和開發(fā)工作量,渠道銷售模塊只需要聚焦業(yè)務(wù)特殊獨(dú)立的地方,渠道銷售業(yè)務(wù)的獨(dú)特性在于前置的渠道管理維護(hù)和后置的賬單管理。
電商業(yè)務(wù)是系統(tǒng)主要的業(yè)務(wù)流程,也是最底層的業(yè)務(wù)邏輯,有完善的訂單管理和出庫(kù)管理。渠道下單后,產(chǎn)品的出庫(kù)配送直接復(fù)用已有的出庫(kù)管理,后續(xù)為客戶提供的服務(wù)。
如:樣本檢測(cè)和出具報(bào)告,業(yè)務(wù)流程完全一樣。只需要對(duì)訂單管理的數(shù)據(jù)結(jié)構(gòu)稍加拓展即可支持(訂單管理中的客戶信息與渠道管理的渠道信息關(guān)聯(lián)性),這樣就可以保證訂單、倉(cāng)儲(chǔ)、樣本、報(bào)告等模塊業(yè)務(wù)邏輯不需要重寫或改造。
需要特殊說明的是,渠道銷售的商品可以直接復(fù)用已有的商品SKU,但每個(gè)渠道對(duì)應(yīng)的商品價(jià)格都不同,因此需要將商品價(jià)格維護(hù)在渠道管理模塊中,以支持財(cái)務(wù)和賬單管理。
業(yè)務(wù)模塊要做到“高內(nèi)聚、低耦合”。
內(nèi)聚描述的是模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度,越緊密,內(nèi)聚性越高,單一責(zé)任原則越強(qiáng),單一責(zé)任指一個(gè)模塊負(fù)責(zé)一項(xiàng)任務(wù)。
耦合描述的是模塊外部各個(gè)模塊彼此結(jié)合的緊密程度,越緊密,耦合性越強(qiáng),模塊的獨(dú)立性越差。
權(quán)限劃分:RBAC權(quán)限設(shè)計(jì)模型
權(quán)限管理三要素:賬號(hào)、角色、權(quán)限
賬號(hào):業(yè)務(wù)系統(tǒng)的用戶就是業(yè)務(wù)人員,每個(gè)業(yè)務(wù)人員分配一個(gè)賬號(hào),通過給業(yè)務(wù)人員分配賬號(hào)驗(yàn)證身份登錄業(yè)務(wù)管理系統(tǒng)進(jìn)行操作。新增賬號(hào)時(shí)需要設(shè)定:用戶名、密碼和角色,如下:
角色:角色用來控制賬號(hào)的查看和操作范圍,在系統(tǒng)中由于權(quán)限較多,不可能每個(gè)每個(gè)賬號(hào)都分別設(shè)置權(quán)限,且由于賬號(hào)對(duì)應(yīng)的業(yè)務(wù)人員從屬同一崗位和部門,工作內(nèi)容多有重合。在創(chuàng)建賬號(hào)時(shí),就可以直接賦予賬號(hào)不同的角色,從而將權(quán)限通過角色給到這個(gè)賬號(hào)。一個(gè)賬號(hào)可以綁定多個(gè)角色,一個(gè)角色又擁有多個(gè)權(quán)限。
權(quán)限內(nèi)容包括:操作權(quán)限、查看權(quán)限、數(shù)據(jù)權(quán)限
數(shù)據(jù)權(quán)限:即角色能看到的數(shù)據(jù)范圍。比如銷售總監(jiān)能看到銷售部門下所有銷售員的銷售數(shù)據(jù),而銷售員則只能看到自己的銷售數(shù)據(jù)。
頁(yè)面權(quán)限:即角色在業(yè)務(wù)系統(tǒng)中看到的頁(yè)面內(nèi)容和元素。比如對(duì)于訂單管理,客服人員可以看到訂單的基礎(chǔ)信息和詳情等所有信息,而倉(cāng)儲(chǔ)人員只能看到訂單的基礎(chǔ)信息。
操作權(quán)限:即角色可以進(jìn)行的操作,如增刪改查。同樣拿訂單管理舉例,客服人員可以對(duì)訂單進(jìn)行刪改,而倉(cāng)儲(chǔ)人員卻無法對(duì)訂單進(jìn)行刪改,可以查詢。
對(duì)于母子賬號(hào)管理,在創(chuàng)建角色時(shí),就已經(jīng)限定了數(shù)據(jù)權(quán)限。在給角色選擇權(quán)限分配時(shí),需要選擇該角色的對(duì)應(yīng)的頁(yè)面權(quán)限(如,列表信息:渠道商)和操作權(quán)限(如,查看詳情)。
Tips:
- 一個(gè)賬號(hào)對(duì)應(yīng)多個(gè)角色時(shí),當(dāng)該用戶登錄系統(tǒng)時(shí),他在系統(tǒng)中的權(quán)限是所有角色權(quán)限的并集。
- 創(chuàng)建角色之前,需要明確各個(gè)部門之間的業(yè)務(wù)范圍和工作職責(zé),根據(jù)這些業(yè)務(wù)人員劃分權(quán)限。隨著公司的業(yè)務(wù)和后臺(tái)系統(tǒng)功能的改變,各個(gè)角色的權(quán)限是需要不斷完善和調(diào)整的。
- 如果公司管理比較扁平化時(shí),同一部門的業(yè)務(wù)人員會(huì)共同使用同一角色,數(shù)據(jù)權(quán)限相同。但如果部門的職級(jí)關(guān)系需要映射到業(yè)務(wù)系統(tǒng)中,那么在創(chuàng)建角色時(shí)需要增加一個(gè)拓展的功能點(diǎn)-母子賬號(hào)管理,以此來劃分?jǐn)?shù)據(jù)權(quán)限。
3、產(chǎn)品原型設(shè)計(jì)及PRD
PM在繪制原型時(shí)需要跟開發(fā)部門確定開發(fā)系統(tǒng)時(shí)使用什么樣式的前端框架,這樣就不需要UI設(shè)計(jì)師參與到業(yè)務(wù)系統(tǒng)的工作中,交互也可以直接引用開源的前端框架,提高效率。
原型盡量使用高保真制作,一方面排版舒適,良好的體驗(yàn)是團(tuán)隊(duì)的潤(rùn)滑劑,另一方面,將數(shù)據(jù)項(xiàng)、列表項(xiàng)等細(xì)節(jié)信息已經(jīng)繪制在原型中,不需要在文檔中特殊說明。
基本信息
基本信息即本次迭代產(chǎn)品說明書的總覽,包含:
修訂歷史:包括修訂時(shí)間、版本號(hào),修訂歷史的作用是為了產(chǎn)品人員方便后期查閱,一旦產(chǎn)品人員變動(dòng)或工作交接給新員工,讓新的產(chǎn)品負(fù)責(zé)人查看產(chǎn)品迭代歷史
版本說明:即本次產(chǎn)品改動(dòng)修改了什么(功能),新增了什么(功能),優(yōu)化了哪些(功能),
業(yè)務(wù)背景&需求分析:在產(chǎn)品評(píng)審的時(shí)候,一定要和技術(shù)的同事交代清楚這次開發(fā)背后的目的是什么?誰提出來的需求?需求分析的結(jié)果什么?要不然技術(shù)同事會(huì)聽著很懵,評(píng)審時(shí)如果技術(shù)同事很少和你互動(dòng),那么技術(shù)的同事就只能低頭敲自己的代碼,完全不知道自己設(shè)計(jì)的這個(gè)功能是干什么的。
業(yè)務(wù)流程圖
PRD的靈魂,重中之重,不多說,PRD可以什么都不寫,但是流程圖必須要有。
權(quán)限說明
如果這次產(chǎn)品迭代是新增業(yè)務(wù)模塊和業(yè)務(wù)邏輯,那么可能在系統(tǒng)中新增了一個(gè)角色,需要在文檔中說明新增的角色名稱和該角色下分配的具體有哪些權(quán)限,同時(shí)還需要說明業(yè)務(wù)人員的賬號(hào)增刪改了哪些角色。
如果是優(yōu)化了業(yè)務(wù)模塊或業(yè)務(wù)邏輯,調(diào)整業(yè)務(wù)流程,那么可能需要在文檔說明系統(tǒng)角色中調(diào)整的權(quán)限。
數(shù)據(jù)說明
數(shù)據(jù)類型是什么?是否必填?長(zhǎng)度是否有限制?是否校驗(yàn)唯一性?(如用戶名,是否唯一?)有無特殊說明?(如密碼以星號(hào)展示)是否有默認(rèn)值?刷新數(shù)據(jù)是否還在?空數(shù)據(jù)展示什么?
交互說明
模態(tài)框,彈出框、提示框等的樣式,按鈕、篩選項(xiàng)的狀態(tài)和位置區(qū)域,頁(yè)面切換樣式,提示樣式?(成功提示、失敗提示、異常提示),操作反饋(點(diǎn)擊、滑動(dòng)、縮放等等)。
頁(yè)面規(guī)則:是否需要使用面包屑,列表頁(yè)的數(shù)據(jù)條數(shù),排序規(guī)則等,空數(shù)據(jù)、頁(yè)面報(bào)錯(cuò)等頁(yè)面。
操作說明
操作是否可以撤回?(如回滾功能,回收站功能)?關(guān)鍵操作之前是否需要給予提示/警告(如刪除操作)?是否需要為某些操作添加特殊說明(如后臺(tái)產(chǎn)品,有些操作并不是所有用戶都了解的,有必要給出特殊文字說明)?操作如果異常/失敗/強(qiáng)制中斷,如何處理?是否有備份?操作中是否允許中斷?
權(quán)限說明
如果這次產(chǎn)品迭代是新增業(yè)務(wù)模塊和業(yè)務(wù)邏輯,那么可能在系統(tǒng)中新增了一個(gè)角色,需要在文檔中說明新增的角色名稱和該角色下分配的具體有哪些權(quán)限,同時(shí)還需要說明業(yè)務(wù)人員的賬號(hào)增刪改了哪些角色。
如果是優(yōu)化了業(yè)務(wù)模塊或業(yè)務(wù)邏輯,調(diào)整業(yè)務(wù)流程,那么可能需要在文檔說明系統(tǒng)角色中調(diào)整的權(quán)限。
業(yè)務(wù)系統(tǒng)產(chǎn)品設(shè)計(jì)的特點(diǎn)
更關(guān)注業(yè)務(wù)流程與業(yè)務(wù)邏輯
前臺(tái)產(chǎn)品注重用戶體驗(yàn),站在用戶角度設(shè)計(jì)產(chǎn)品,考慮用戶使用場(chǎng)景,打磨產(chǎn)品細(xì)節(jié),讓用戶用著爽。相比較而言,后臺(tái)產(chǎn)品更注重實(shí)際的業(yè)務(wù)邏輯,用戶在前臺(tái)產(chǎn)品的每一個(gè)觸發(fā)操作行為,產(chǎn)品如何應(yīng)答,需要處理那些數(shù)據(jù),如何處理數(shù)據(jù),如何傳輸數(shù)據(jù),傳輸哪些數(shù)據(jù)給前臺(tái)產(chǎn)品與用戶交互互動(dòng)。
后臺(tái)產(chǎn)品設(shè)計(jì)更注重功能實(shí)現(xiàn),后臺(tái)產(chǎn)品設(shè)計(jì)時(shí)更貼合產(chǎn)品MVP設(shè)計(jì)的理念,對(duì)于后臺(tái)業(yè)務(wù)系統(tǒng)來說,很多功能模塊可以采用開發(fā)成本更低的臨時(shí)方案,即使體驗(yàn)不好,業(yè)務(wù)人員操作效率不高,只要能保障功能可以實(shí)現(xiàn),業(yè)務(wù)邏輯處理正常,業(yè)務(wù)可以正常運(yùn)轉(zhuǎn)即可。
需求更為明確
用戶端的產(chǎn)品需要通過不斷的調(diào)研分析、需求挖掘,測(cè)試驗(yàn)證,提升產(chǎn)品價(jià)值。而業(yè)務(wù)系統(tǒng)的用戶是內(nèi)部的業(yè)務(wù)人員,業(yè)務(wù)方往往都是主動(dòng)推進(jìn)需求。
但是,對(duì)于業(yè)務(wù)人員的需求仍然需要判斷其真實(shí)性及目的。由于業(yè)務(wù)系統(tǒng)的業(yè)務(wù)邏輯的復(fù)雜性,業(yè)務(wù)主流程之外的異常流程也較多,如果沒有正確理解需求的真實(shí)意圖,就會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)的功能疊加,系統(tǒng)愈發(fā)混亂。
高效率、靈活性、可拓展
而內(nèi)部業(yè)務(wù)人員在使用后臺(tái)系統(tǒng)時(shí),一般都屬于工作范疇,所以要講究高效率,如此才能快速高效的完成相應(yīng)任務(wù),說的更宏觀一些,能否提高業(yè)務(wù)人員的工作效率是衡量業(yè)務(wù)系統(tǒng)好壞的標(biāo)尺。
高效率:比如,在設(shè)計(jì)報(bào)告打印管理時(shí),業(yè)務(wù)人員需要接收從打印廠中打印完成的報(bào)告然后交付給下一個(gè)部門,報(bào)告就在多個(gè)部門中流轉(zhuǎn)產(chǎn)生多個(gè)狀態(tài)變更。相應(yīng)的業(yè)務(wù)人員需要標(biāo)記每個(gè)報(bào)告的狀態(tài)變更。為了嚴(yán)謹(jǐn)防止實(shí)際操作中業(yè)務(wù)人員出現(xiàn)操作失誤,業(yè)務(wù)人員需要一個(gè)個(gè)確認(rèn)報(bào)告的狀態(tài)變更。如下圖:
但在實(shí)際使用場(chǎng)景中,業(yè)務(wù)人員經(jīng)常從打印廠接收一批報(bào)告,報(bào)告數(shù)量較大。業(yè)務(wù)人員可能要重復(fù)性的操作標(biāo)記每一個(gè)報(bào)告的狀態(tài)變更,這個(gè)時(shí)候,“批量操作”、“全選”功能就解決了業(yè)務(wù)人員重復(fù)性的操作,效率較低的情況。
再比如在下載excel表格時(shí),狀態(tài)自動(dòng)變更,而不需要業(yè)務(wù)人員手動(dòng)調(diào)整狀態(tài)。
靈活性:靈活性處理的是同一業(yè)務(wù)場(chǎng)景下,某個(gè)環(huán)節(jié)一但出現(xiàn)異常,系統(tǒng)可以進(jìn)行補(bǔ)救,從而使該業(yè)務(wù)場(chǎng)景下異常狀態(tài)回歸正常業(yè)務(wù)邏輯,跑通業(yè)務(wù)流程。正常業(yè)務(wù)場(chǎng)景是,用戶購(gòu)買基因檢測(cè)產(chǎn)品后,我們將采樣盒郵寄給用戶,用戶自助將采樣盒綁定到自己的賬號(hào)下,并完成樣本采集,后期才能查看報(bào)告。
有個(gè)異常的業(yè)務(wù)場(chǎng)景是,用戶忘記綁定樣本并郵寄回來,用戶沒有任何補(bǔ)綁的機(jī)會(huì)怎么辦?也就是說在前臺(tái)的用戶端產(chǎn)品,對(duì)于這個(gè)樣本沒有任何補(bǔ)救的機(jī)會(huì),最后考慮只能從業(yè)務(wù)系統(tǒng)進(jìn)行優(yōu)化,調(diào)整系統(tǒng)的靈活性。即使用戶沒有綁定自己的樣本,客服人員可以在后臺(tái)幫助用戶填寫信息完成綁定,用戶可以在后期通過手機(jī)號(hào)索取到自己的樣本。如下圖:
拓展性:拓展性是指業(yè)務(wù)系統(tǒng)可以處理不同的業(yè)務(wù)場(chǎng)景,讓不同的業(yè)務(wù)場(chǎng)景可以兼并符合同一業(yè)務(wù)邏輯。
上一點(diǎn)提到的業(yè)務(wù)系統(tǒng)的靈活性主要符合的場(chǎng)景是單一用戶完成樣本綁定,屬于2C業(yè)務(wù)。如果是2B業(yè)務(wù)怎么辦呢?通過調(diào)研之后,我們了解到2B的業(yè)務(wù)場(chǎng)景完全不同于2C的業(yè)務(wù)場(chǎng)景,2B大企業(yè)是通過召集大批量的客戶集中在一個(gè)會(huì)場(chǎng)中完成樣本采集。
對(duì)于2B的客戶來說,不需要用戶自己?jiǎn)为?dú)進(jìn)行綁定采樣盒,因?yàn)?B的大企業(yè)已經(jīng)有了客戶的個(gè)人信息。對(duì)于這種業(yè)務(wù)場(chǎng)景,設(shè)計(jì)一個(gè)“批量導(dǎo)入樣本”的功能,2B銷售員只需要通過Excel表格將客戶信息錄入到系統(tǒng)中就可以完成采樣盒綁定。如下圖:
以上,本次的 《產(chǎn)品復(fù)盤:從0到1設(shè)計(jì)業(yè)務(wù)系統(tǒng)?分享結(jié)束》,希望對(duì)你有所幫助!
本文由 @獨(dú)貓X 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自PEXELS,基于CC0協(xié)議
最近才做了一個(gè)渠道分銷系統(tǒng),挺有同感的,除了理清本身的業(yè)務(wù)邏輯外,也需要具體一定的企業(yè)經(jīng)營(yíng)、財(cái)務(wù)風(fēng)控方面的意識(shí),考慮得才能更全面
想問下財(cái)務(wù)管理和賬單管理為啥在業(yè)務(wù)系統(tǒng)里面?
感謝,準(zhǔn)備照著復(fù)盤自己接觸的新業(yè)務(wù)
寫的專業(yè)
哈哈哈哈哈,報(bào)上大名!
小名行不?
不是和我一個(gè)公司把?
目前我也在做業(yè)務(wù)系統(tǒng),基本都是后臺(tái)操作系統(tǒng),不曉得只做后臺(tái)產(chǎn)品之后的路子會(huì)不會(huì)太窄。
會(huì)
恩,看樣子得做做別的app類的了
額,不是做APP路子就寬了,而是業(yè)務(wù)系統(tǒng)比較看重業(yè)務(wù)流的梳理,工作效率的提升,對(duì)于用戶體驗(yàn)等TO C產(chǎn)品的技能點(diǎn)比較薄弱,,想讓路子寬,要么你做的業(yè)務(wù)系統(tǒng)行業(yè)好,比如支付業(yè)務(wù),而且業(yè)務(wù)系統(tǒng)做到后面,你基本上就是個(gè)行業(yè)專家了