起點(diǎn)課堂會(huì)員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會(huì)特權(quán)
個(gè)人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場(chǎng)職場(chǎng)軟技能直播
12場(chǎng)求職輔導(dǎo)直播
12場(chǎng)專業(yè)技能直播
會(huì)員專屬社群
榮耀標(biāo)識(shí)實(shí)例解析業(yè)務(wù)流程圖與產(chǎn)品流程圖
這篇文章的目的很簡(jiǎn)單：通過電商的實(shí)例，將業(yè)務(wù)流程圖和任務(wù)流程圖之間的關(guān)聯(lián)和區(qū)別以及在產(chǎn)品中的應(yīng)用，講解清楚。
流程和流程圖
首先來看流程的定義：
《牛津詞典》里，流程是指一個(gè)或一系列連續(xù)有規(guī)律的行動(dòng)，這些行動(dòng)以確定的方式發(fā)生或執(zhí)行，促使特定結(jié)果的實(shí)現(xiàn)； 而國際標(biāo)準(zhǔn)化組織在ISO9001：2000質(zhì)量管理體系標(biāo)準(zhǔn)中給出的定義是：“流程是一組將輸入轉(zhuǎn)化為輸出的相互關(guān)聯(lián)或相互作用的活動(dòng)”。
由上面的兩個(gè)定義，我們可以提煉出流程不可或缺的因素：對(duì)象、輸入、動(dòng)作、輸出。
- 對(duì)象就是執(zhí)行人，也就是產(chǎn)品中的用戶；
- 輸入可以理解為前提、前置條件；
- 動(dòng)作，就是產(chǎn)品中的操作，可以是點(diǎn)擊、輸入，等等；
- 輸出，可以理解為結(jié)果、動(dòng)作的目的。
需要說明的是：
- 產(chǎn)品工作中，輸入和輸出的形式并不局限，可以是事件，也可以是動(dòng)作；
- 在思考輸出時(shí)，也不能僅僅考慮用戶端的輸出結(jié)果，同時(shí)要思考后臺(tái)可能產(chǎn)生的輸出（比如數(shù)據(jù)的變化）；
- 在相連的環(huán)節(jié)中，通常上一個(gè)環(huán)節(jié)的輸出即為下一個(gè)環(huán)節(jié)的輸入。
明確了流程的定義和要素之后，顧名思義，流程圖就是將流程表達(dá)清楚的圖形，流程圖只要表達(dá)清楚一件事：什么對(duì)象在什么前置條件下執(zhí)行了什么操作，產(chǎn)生了什么結(jié)果。
流程圖的制作方法和工具，已經(jīng)有很多的介紹，這里不贅述。產(chǎn)品工作中常用到業(yè)務(wù)流程圖和任務(wù)流程圖，下面將通過實(shí)例講述我所理解的兩種流程圖的聯(lián)系和區(qū)別。
業(yè)務(wù)流程圖
業(yè)務(wù)流程圖的作用是表達(dá)清楚業(yè)務(wù)需求在產(chǎn)品線的各個(gè)階段中在各個(gè)功能模塊之間的輪轉(zhuǎn)。
通常情況下，一個(gè)業(yè)務(wù)需求不僅僅對(duì)應(yīng)一個(gè)功能需求，而是由多個(gè)功能需求組成的，舉例來說：業(yè)務(wù)需求是注冊(cè)，那么功能需求就包括填寫信息的正則校驗(yàn)，驗(yàn)證碼的生成與校驗(yàn)，注冊(cè)協(xié)議查看（和勾選），此外，后臺(tái)還要有賬戶生成與信息記錄的功能，需要手機(jī)注冊(cè)的還要有短信的發(fā)送與驗(yàn)證功能（郵箱注冊(cè)同理）。
可見，業(yè)務(wù)需求要求概括精煉，功能需求要求詳細(xì)具體。一個(gè)業(yè)務(wù)需求通常涵蓋多個(gè)功能需求，涉及前端展示、后臺(tái)記錄等多個(gè)部分，所以業(yè)務(wù)流程圖通常復(fù)雜詳細(xì)，盡量能夠涵蓋各種異常情況（每種異常情況都有相應(yīng)的前、后臺(tái)解決方案）。
業(yè)務(wù)流程圖的繪制思路一般是：
- 首先將業(yè)務(wù)按階段劃分，比如電商類可以分為下單和支付，單車類可以分為提車、騎行和停車；
- 然后列出每個(gè)階段參與的功能模塊，比如下單階段，就有商品查看、登錄/注冊(cè)、信息記錄、個(gè)人中心等功能。
- 最后按照時(shí)間順序，畫出業(yè)務(wù)需求在各個(gè)功能模塊之間的流轉(zhuǎn)情況。
為了輸出一份完整的業(yè)務(wù)流程圖，一般有兩個(gè)原則：
- 先思考主干流程，再思考分支流程，主干流程邏輯準(zhǔn)確，分支流程全面無遺漏；
- 表達(dá)清楚后臺(tái)產(chǎn)生的各種判斷及相應(yīng)的前端展示,這將作為接口設(shè)計(jì)的重要根據(jù)。
下面以電商購物的實(shí)例，繪制一份業(yè)務(wù)流程圖
一個(gè)完整的電商購物流程，通常包含兩個(gè)階段，五個(gè)部分，兩個(gè)階段就是下單和支付，五個(gè)部分是用戶、交易、賬號(hào)系統(tǒng)&個(gè)人中心、支付系統(tǒng)和CRM系統(tǒng)，如果僅僅從用戶角度出發(fā)，很難考慮到后臺(tái)各種判斷和操作，那樣就變成了任務(wù)流程圖，而這個(gè)圖中包含了購物流程的用戶操作、前端展示和后臺(tái)判斷，體現(xiàn)了實(shí)現(xiàn)購物業(yè)務(wù)所需要提供的功能和各部門的支持，在這個(gè)圖中也能看出所需要的接口和數(shù)據(jù)。
業(yè)務(wù)流程圖應(yīng)該是拿到業(yè)務(wù)需求（或BRD）后，首先輸出的文檔，而且并不是一成不變的，會(huì)在對(duì)業(yè)務(wù)需求或者BRD的多次討論中不斷補(bǔ)充完善，最后成為整個(gè)項(xiàng)目的標(biāo)桿文件，在構(gòu)建技術(shù)架構(gòu)和技術(shù)分工時(shí)，將其作為主要參考。所以，繪制業(yè)務(wù)流程圖時(shí)，一定要邏輯清晰，不能遺漏任何一個(gè)重要部分。
任務(wù)流程圖
任務(wù)流程圖表達(dá)的是用戶在執(zhí)行某個(gè)具體的任務(wù)時(shí)的工作流程。任務(wù)流程圖可以理解為一個(gè)簡(jiǎn)化版的業(yè)務(wù)流程圖，只有主要的操作步驟，通常在寫用戶體驗(yàn)報(bào)告時(shí)，利用任務(wù)流程圖表達(dá)頁面流轉(zhuǎn)和主要操作，同樣以電商購物為例：
由上可見，相比于業(yè)務(wù)流程圖，任務(wù)流程圖的特點(diǎn)是：
- 只展現(xiàn)用戶的操作，不展現(xiàn)后臺(tái)的判斷；
- 只展現(xiàn)正常流程，不展現(xiàn)異常流程；
- 只可查看用戶的工作流程，無法作為開發(fā)的參考。
不管是繪制業(yè)務(wù)流程圖還是任務(wù)流程圖，重點(diǎn)都應(yīng)放在邏輯關(guān)系上，而不是圖形本身的細(xì)節(jié)。說到底，流程圖只是幫助我們更好地進(jìn)行分析思考的工具，能夠畫出邏輯清晰的流程圖，不一定對(duì)每個(gè)模塊都了如指掌，但如果流程圖邏輯混亂、含糊不清，那么肯定要反思是不是對(duì)業(yè)務(wù)需求或者功能需求的理解不清晰。作為剛?cè)腴T的新手，結(jié)合思維導(dǎo)圖，經(jīng)常分析產(chǎn)品的業(yè)務(wù)流程和任務(wù)流程，對(duì)提高邏輯感和產(chǎn)品思維，還是很有幫助的。
本文由 @LeeJX 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
產(chǎn)品流程圖呢
體驗(yàn)地圖
我的Mac貌似用不了Visio
visio在Mac上面不能使用，只能用其他軟件了
一個(gè)Axure幾乎全部解決
mac使用億圖圖示
可以使用 簡(jiǎn)圖創(chuàng)作，不需要下載軟件，價(jià)格比較親民
請(qǐng)問交易什么什么鬼？屬于角色嗎？
是個(gè)動(dòng)作 可能作者想表達(dá)的是交易系統(tǒng)或者平臺(tái)吧
萌新問下一下，做流程圖什么軟件好用(?▽?)
Visio
個(gè)人感覺Axure可以解決一切
在線工具process-on
感謝分享，我認(rèn)為這篇文章的核心是，業(yè)務(wù)流程圖是完成一項(xiàng)業(yè)務(wù)所涉及到的所有動(dòng)作，任務(wù)流程圖是完成一項(xiàng)任務(wù)的用戶所需要設(shè)計(jì)的動(dòng)作。就這就對(duì)小白來說挺有啟發(fā)的，至于文章細(xì)節(jié)方面有錯(cuò)誤倒無傷大雅。不過看評(píng)論里的大佬爭(zhēng)論各種細(xì)節(jié)倒是開闊了一些視野。
非常感謝分享，受益匪淺
感謝分享，很有啟發(fā)。終于搞清楚了業(yè)務(wù)流程圖和任務(wù)流程圖
感謝分享，有所啟發(fā)，但是少部分地方不能茍同。crm系統(tǒng)不包括庫存的減少吧
你好，流程圖中的“是否支付超時(shí)”的判斷是不是寫反了？往下的是“否”哦
業(yè)務(wù)流程圖和系統(tǒng)流程圖結(jié)合在一起了，然后一個(gè)流程圖中不能有多個(gè)結(jié)束吧
標(biāo)題中說的產(chǎn)品流程圖呢
這里是標(biāo)題寫錯(cuò)了，抱歉，應(yīng)該是任務(wù)流程圖
而且你的這個(gè)業(yè)務(wù)流程圖有點(diǎn)像我們業(yè)務(wù)流程圖和系統(tǒng)流程圖的結(jié)合
可以微信交流不？學(xué)習(xí)下
微信號(hào) Leejx12138
知道了任務(wù)流程的概念，受教了。不過業(yè)務(wù)流程圖不是只能串行么？你的流程圖里有并行線，有點(diǎn)像UML里的活動(dòng)圖。
有啟發(fā)。很多部分活動(dòng)和判斷是不是可以合并呢？
貌似你并沒有接觸過太多關(guān)于CRM的東西，你的圖里面CRM部分的流程實(shí)際是OMS或者WMS負(fù)責(zé)的，CRM是不負(fù)責(zé)訂單狀態(tài)的。
CRM既不負(fù)責(zé)訂單狀態(tài)，也不負(fù)責(zé)庫存管理。庫存這塊應(yīng)該類似于WMS。OMS在不同行業(yè)的叫法不一樣。
挺好的。學(xué)習(xí)了。
一般
感謝分享，挺實(shí)用的
有個(gè)疑問，業(yè)務(wù)流程是對(duì)整個(gè)需求的概括，沒有提到異常流程；那么在任務(wù)流程中如果不體現(xiàn)異常流程的話，請(qǐng)問異常流程該如何說明，難道在PRD中嗎？
異常情況應(yīng)該表現(xiàn)在業(yè)務(wù)流程圖中的呀，任務(wù)流程圖其實(shí)不太常用的，其中也不需要表現(xiàn)異常流程。此外，prd和原型中也應(yīng)該相應(yīng)地體現(xiàn)出異常流程
我也有同樣的疑惑，業(yè)務(wù)流程本來就涉及各主體，如果加上異常情況，那流程圖就很復(fù)雜了，而任務(wù)流程更簡(jiǎn)單，更詳細(xì)，卻不寫異常流程，為什么？
我的理解是，既然叫業(yè)務(wù)流程圖，那么流程圖里必然包含整個(gè)業(yè)務(wù)從頭到尾的信息、數(shù)據(jù)的流轉(zhuǎn)，保證業(yè)務(wù)能走通，包含各種分支。異常處理也應(yīng)包含在內(nèi)，這樣才是邏輯嚴(yán)謹(jǐn)、面面俱到，有說服力的。
業(yè)務(wù)流程圖只是讓你梳理業(yè)務(wù)的大體流轉(zhuǎn)，知曉業(yè)務(wù)是什么的。
作者看來要么是哪家電商的實(shí)習(xí)生，要么是其他行業(yè)的在yy電商后臺(tái)流程。。。
對(duì)啊，是實(shí)習(xí)生啊，但是并不是哪家電商的，只是對(duì)這方面感興趣點(diǎn)，如不嫌棄，留微信詳細(xì)交流可否?
能指出問題嘛，新人看不懂。。。。
文章標(biāo)題是“實(shí)例解析業(yè)務(wù)流程圖與產(chǎn)品流程圖”，文章第一段“通過電商的實(shí)例，將業(yè)務(wù)流程圖和任務(wù)流程圖之間的關(guān)聯(lián)和區(qū)別以及在產(chǎn)品中的應(yīng)用，講解清楚。”
你講明白你要講的是業(yè)務(wù)和產(chǎn)品流程圖的區(qū)別 還是 業(yè)務(wù)和任務(wù)流程圖的區(qū)別。本來概念就混淆，這不更混淆了嘛
講解的是業(yè)務(wù)流程圖和任務(wù)流程圖，這里是標(biāo)題筆誤了，抱歉
可以采用虛擬庫存，然后一段時(shí)間后，未支付就自動(dòng)按照實(shí)際內(nèi)容恢復(fù)虛擬庫存的方法？
不知道你所說的虛擬庫存，和流程圖中的庫存的區(qū)別。我的理解，這兩者應(yīng)該是同一個(gè)概念，即使另開一個(gè)空間存虛擬庫存，那虛擬庫存的數(shù)據(jù)也是要和實(shí)際庫存的數(shù)據(jù)完全打通的啊，其實(shí)也就成了一碼事了
而且這里也沒體現(xiàn)物流、運(yùn)能、ERP流程，也沒有完整逆向流程，缺失了很多環(huán)節(jié)的判斷…
您好，小生剛?cè)氘a(chǎn)品不久，對(duì)于這個(gè)電商購物這方面的流程等相關(guān)可否指點(diǎn)一二？
這個(gè)電商流程是有問題的，你這購物車要在訂單的前面，校驗(yàn)庫存和鎖庫存都要在提交訂單之前，否則會(huì)造成大量逆向訂單出現(xiàn)…
上面那個(gè)業(yè)務(wù)流程，是忽略了購物車的，里面沒有購物車的功能；至于校驗(yàn)庫存和鎖庫存的問題，是在用戶發(fā)起下單動(dòng)作之后，到確定生成訂單之前的，不應(yīng)是用戶“提交訂單”動(dòng)作之前的吧
按照你的流程，我填寫配送信息之后，提交訂單，校驗(yàn)庫存，庫存為0，然后訂單提交失敗，你覺得用戶體驗(yàn)合理么？并且高并發(fā)怎么處理？提交訂單，讓用戶一直在訂單提交中異步等待么？
再換個(gè)角度，按照你這流程，提交訂單成功了，這時(shí)候是直接操作減庫存了，相當(dāng)于你根本沒鎖庫存，商品售賣沒有鎖庫存，ok么？
希望對(duì)你有幫助:)
我理解您的意思了，非常感謝您解釋的這么清晰。
我這個(gè)圖中將鎖庫存和減庫存當(dāng)成了一回事，確實(shí)不正確；也沒有考慮到配送信息填寫頁之前要進(jìn)行庫存檢驗(yàn)的步驟。
我認(rèn)為并不是在進(jìn)入配送信息填寫頁時(shí)鎖庫存，而是在下單后（支付頁之前）時(shí)鎖庫存，這里參考了淘寶雙十一，在雙十一中，也確實(shí)存在填寫配送信息成功后，訂單提交失敗的情況，用戶體驗(yàn)確實(shí)很糟糕。而減庫存是在支付成功后進(jìn)行的。當(dāng)然您說的，在確認(rèn)訂單信息（包括填寫配送信息）頁鎖庫存確實(shí)也是可行的，但是這樣，好像和加入購物車時(shí)減庫存差別不大，都是在生成訂單之前。還希望能繼續(xù)討論。
不聊了，順便說一下，淘寶是在加入購物車鎖庫存的。
你好，想順便問下，淘寶如果是在加入購物車鎖庫存的話，拿很多人不都是加入購物車不購買占庫存么？
感覺你們這里應(yīng)該有兩個(gè)概念，一個(gè)是鎖庫存，一個(gè)是減庫存。一般電商是有兩種減庫存的方案的，支付減庫存和下單減庫存，主要目的是防止惡意刷單和超賣的情況出現(xiàn)。而庫存鎖定是指在某段時(shí)間內(nèi)用戶可以通過下單或加購物車行為將某件商品凍結(jié)，用戶有一段時(shí)間的商品擁有權(quán)，不過這一般都不會(huì)是長期的，通常會(huì)有一個(gè)鎖定庫存釋放時(shí)間，避免某些用戶長時(shí)間占用，如：未支付訂單或者長期存放購物車的商品，這就說明為何我們?cè)谫徫镘嚨纳唐窌?huì)出現(xiàn)失效的現(xiàn)象。
親自測(cè)試，加入購物車并沒有鎖庫存
據(jù)我了解，淘寶是提交訂單鎖庫存，支付減庫存的，叫鎖單/鎖貨，跟京東一樣，訂單取消或超時(shí)取消才釋放庫存，國外有些電商是沒有提交訂單再支付這種做法的，一般是提交訂單-支付同時(shí)進(jìn)行的，所以加入購物車就鎖庫存這種方案比較適合國外的電商。國內(nèi)的話，唯品會(huì)就是加入購物車就鎖庫存，不過十幾分鐘就要提交訂單，否則釋放，提交后一定時(shí)間要支付，否則也釋放。
現(xiàn)在淘寶提交訂單也不鎖庫存了。。。放著沒付款，第二天沒庫存了直接無法付款
能否加一下您。我的微信shaowenbin0917
可以加的，我的微信號(hào)：LeeJX12138（PS：這篇忘記在末尾加微信號(hào)了……尷尬）
判斷庫存不應(yīng)該放在提交訂單等前面嗎？沒有尊重用戶勞動(dòng)成果呀
你說的是對(duì)的，用戶進(jìn)入訂單確認(rèn)頁之前應(yīng)該判斷是否超出限購要求、活動(dòng)是否結(jié)束和是否有庫存的，這里是我遺漏了，感謝提醒