實例解析業(yè)務(wù)流程圖與產(chǎn)品流程圖

59 評論 224305 瀏覽 1391 收藏 8 分鐘

這篇文章的目的很簡單:通過電商的實例,將業(yè)務(wù)流程圖和任務(wù)流程圖之間的關(guān)聯(lián)和區(qū)別以及在產(chǎn)品中的應(yīng)用,講解清楚。

流程和流程圖

首先來看流程的定義:

《牛津詞典》里,流程是指一個或一系列連續(xù)有規(guī)律的行動,這些行動以確定的方式發(fā)生或執(zhí)行,促使特定結(jié)果的實現(xiàn); 而國際標(biāo)準(zhǔn)化組織在ISO9001:2000質(zhì)量管理體系標(biāo)準(zhǔn)中給出的定義是:“流程是一組將輸入轉(zhuǎn)化為輸出的相互關(guān)聯(lián)或相互作用的活動”。

由上面的兩個定義,我們可以提煉出流程不可或缺的因素:對象、輸入、動作、輸出。

  • 對象就是執(zhí)行人,也就是產(chǎn)品中的用戶;
  • 輸入可以理解為前提、前置條件;
  • 動作,就是產(chǎn)品中的操作,可以是點擊、輸入,等等;
  • 輸出,可以理解為結(jié)果、動作的目的。

需要說明的是:

  1. 產(chǎn)品工作中,輸入和輸出的形式并不局限,可以是事件,也可以是動作;
  2. 在思考輸出時,也不能僅僅考慮用戶端的輸出結(jié)果,同時要思考后臺可能產(chǎn)生的輸出(比如數(shù)據(jù)的變化);
  3. 在相連的環(huán)節(jié)中,通常上一個環(huán)節(jié)的輸出即為下一個環(huán)節(jié)的輸入。

明確了流程的定義和要素之后,顧名思義,流程圖就是將流程表達清楚的圖形,流程圖只要表達清楚一件事:什么對象在什么前置條件下執(zhí)行了什么操作,產(chǎn)生了什么結(jié)果。

流程圖的制作方法和工具,已經(jīng)有很多的介紹,這里不贅述。產(chǎn)品工作中常用到業(yè)務(wù)流程圖和任務(wù)流程圖,下面將通過實例講述我所理解的兩種流程圖的聯(lián)系和區(qū)別。

業(yè)務(wù)流程圖

業(yè)務(wù)流程圖的作用是表達清楚業(yè)務(wù)需求在產(chǎn)品線的各個階段中在各個功能模塊之間的輪轉(zhuǎn)。

通常情況下,一個業(yè)務(wù)需求不僅僅對應(yīng)一個功能需求,而是由多個功能需求組成的,舉例來說:業(yè)務(wù)需求是注冊,那么功能需求就包括填寫信息的正則校驗,驗證碼的生成與校驗,注冊協(xié)議查看(和勾選),此外,后臺還要有賬戶生成與信息記錄的功能,需要手機注冊的還要有短信的發(fā)送與驗證功能(郵箱注冊同理)。

可見,業(yè)務(wù)需求要求概括精煉,功能需求要求詳細(xì)具體。一個業(yè)務(wù)需求通常涵蓋多個功能需求,涉及前端展示、后臺記錄等多個部分,所以業(yè)務(wù)流程圖通常復(fù)雜詳細(xì),盡量能夠涵蓋各種異常情況(每種異常情況都有相應(yīng)的前、后臺解決方案)。

業(yè)務(wù)流程圖的繪制思路一般是:

  • 首先將業(yè)務(wù)按階段劃分,比如電商類可以分為下單和支付,單車類可以分為提車、騎行和停車;
  • 然后列出每個階段參與的功能模塊,比如下單階段,就有商品查看、登錄/注冊、信息記錄、個人中心等功能。
  • 最后按照時間順序,畫出業(yè)務(wù)需求在各個功能模塊之間的流轉(zhuǎn)情況。

為了輸出一份完整的業(yè)務(wù)流程圖,一般有兩個原則:

  • 先思考主干流程,再思考分支流程,主干流程邏輯準(zhǔn)確,分支流程全面無遺漏;
  • 表達清楚后臺產(chǎn)生的各種判斷及相應(yīng)的前端展示,這將作為接口設(shè)計的重要根據(jù)。

下面以電商購物的實例,繪制一份業(yè)務(wù)流程圖

一個完整的電商購物流程,通常包含兩個階段,五個部分,兩個階段就是下單和支付,五個部分是用戶、交易、賬號系統(tǒng)&個人中心、支付系統(tǒng)和CRM系統(tǒng),如果僅僅從用戶角度出發(fā),很難考慮到后臺各種判斷和操作,那樣就變成了任務(wù)流程圖,而這個圖中包含了購物流程的用戶操作、前端展示和后臺判斷,體現(xiàn)了實現(xiàn)購物業(yè)務(wù)所需要提供的功能和各部門的支持,在這個圖中也能看出所需要的接口和數(shù)據(jù)。

業(yè)務(wù)流程圖應(yīng)該是拿到業(yè)務(wù)需求(或BRD)后,首先輸出的文檔,而且并不是一成不變的,會在對業(yè)務(wù)需求或者BRD的多次討論中不斷補充完善,最后成為整個項目的標(biāo)桿文件,在構(gòu)建技術(shù)架構(gòu)和技術(shù)分工時,將其作為主要參考。所以,繪制業(yè)務(wù)流程圖時,一定要邏輯清晰,不能遺漏任何一個重要部分。

任務(wù)流程圖

任務(wù)流程圖表達的是用戶在執(zhí)行某個具體的任務(wù)時的工作流程。任務(wù)流程圖可以理解為一個簡化版的業(yè)務(wù)流程圖,只有主要的操作步驟,通常在寫用戶體驗報告時,利用任務(wù)流程圖表達頁面流轉(zhuǎn)和主要操作,同樣以電商購物為例:

由上可見,相比于業(yè)務(wù)流程圖,任務(wù)流程圖的特點是:

  • 只展現(xiàn)用戶的操作,不展現(xiàn)后臺的判斷;
  • 只展現(xiàn)正常流程,不展現(xiàn)異常流程;
  • 只可查看用戶的工作流程,無法作為開發(fā)的參考。

不管是繪制業(yè)務(wù)流程圖還是任務(wù)流程圖,重點都應(yīng)放在邏輯關(guān)系上,而不是圖形本身的細(xì)節(jié)。說到底,流程圖只是幫助我們更好地進行分析思考的工具,能夠畫出邏輯清晰的流程圖,不一定對每個模塊都了如指掌,但如果流程圖邏輯混亂、含糊不清,那么肯定要反思是不是對業(yè)務(wù)需求或者功能需求的理解不清晰。作為剛?cè)腴T的新手,結(jié)合思維導(dǎo)圖,經(jīng)常分析產(chǎn)品的業(yè)務(wù)流程和任務(wù)流程,對提高邏輯感和產(chǎn)品思維,還是很有幫助的。

 

本文由 @LeeJX 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 產(chǎn)品流程圖呢

    來自北京 回復(fù)
  2. 體驗地圖

    回復(fù)
  3. 我的Mac貌似用不了Visio

    回復(fù)
    1. visio在Mac上面不能使用,只能用其他軟件了

      來自寧夏 回復(fù)
    2. 一個Axure幾乎全部解決

      來自遼寧 回復(fù)
    3. mac使用億圖圖示

      來自廣東 回復(fù)
    4. 可以使用 簡圖創(chuàng)作,不需要下載軟件,價格比較親民

      來自北京 回復(fù)
  4. 請問交易什么什么鬼?屬于角色嗎?

    來自河南 回復(fù)
    1. 是個動作 可能作者想表達的是交易系統(tǒng)或者平臺吧

      來自廣東 回復(fù)
  5. 萌新問下一下,做流程圖什么軟件好用(?▽?)

    回復(fù)
    1. Visio

      回復(fù)
    2. 個人感覺Axure可以解決一切

      來自遼寧 回復(fù)
    3. 在線工具process-on

      來自云南 回復(fù)
  6. 感謝分享,我認(rèn)為這篇文章的核心是,業(yè)務(wù)流程圖是完成一項業(yè)務(wù)所涉及到的所有動作,任務(wù)流程圖是完成一項任務(wù)的用戶所需要設(shè)計的動作。就這就對小白來說挺有啟發(fā)的,至于文章細(xì)節(jié)方面有錯誤倒無傷大雅。不過看評論里的大佬爭論各種細(xì)節(jié)倒是開闊了一些視野。

    回復(fù)
  7. 非常感謝分享,受益匪淺

    回復(fù)
  8. 感謝分享,很有啟發(fā)。終于搞清楚了業(yè)務(wù)流程圖和任務(wù)流程圖

    來自重慶 回復(fù)
  9. 感謝分享,有所啟發(fā),但是少部分地方不能茍同。crm系統(tǒng)不包括庫存的減少吧

    來自重慶 回復(fù)
  10. 你好,流程圖中的“是否支付超時”的判斷是不是寫反了?往下的是“否”哦

    來自廣東 回復(fù)
  11. 業(yè)務(wù)流程圖和系統(tǒng)流程圖結(jié)合在一起了,然后一個流程圖中不能有多個結(jié)束吧

    來自浙江 回復(fù)
  12. 標(biāo)題中說的產(chǎn)品流程圖呢

    來自江蘇 回復(fù)
    1. 這里是標(biāo)題寫錯了,抱歉,應(yīng)該是任務(wù)流程圖

      來自北京 回復(fù)
    2. 而且你的這個業(yè)務(wù)流程圖有點像我們業(yè)務(wù)流程圖和系統(tǒng)流程圖的結(jié)合

      來自江蘇 回復(fù)
    3. 可以微信交流不?學(xué)習(xí)下

      來自湖北 回復(fù)
    4. 微信號 Leejx12138

      來自廣東 回復(fù)
  13. 知道了任務(wù)流程的概念,受教了。不過業(yè)務(wù)流程圖不是只能串行么?你的流程圖里有并行線,有點像UML里的活動圖。

    來自北京 回復(fù)
  14. 有啟發(fā)。很多部分活動和判斷是不是可以合并呢?

    來自山東 回復(fù)
  15. 貌似你并沒有接觸過太多關(guān)于CRM的東西,你的圖里面CRM部分的流程實際是OMS或者WMS負(fù)責(zé)的,CRM是不負(fù)責(zé)訂單狀態(tài)的。

    來自上海 回復(fù)
    1. CRM既不負(fù)責(zé)訂單狀態(tài),也不負(fù)責(zé)庫存管理。庫存這塊應(yīng)該類似于WMS。OMS在不同行業(yè)的叫法不一樣。

      來自浙江 回復(fù)
  16. 挺好的。學(xué)習(xí)了。

    來自四川 回復(fù)
  17. 一般

    來自廣東 回復(fù)
  18. 感謝分享,挺實用的

    來自廣東 回復(fù)
  19. 有個疑問,業(yè)務(wù)流程是對整個需求的概括,沒有提到異常流程;那么在任務(wù)流程中如果不體現(xiàn)異常流程的話,請問異常流程該如何說明,難道在PRD中嗎?

    來自廣東 回復(fù)
    1. 異常情況應(yīng)該表現(xiàn)在業(yè)務(wù)流程圖中的呀,任務(wù)流程圖其實不太常用的,其中也不需要表現(xiàn)異常流程。此外,prd和原型中也應(yīng)該相應(yīng)地體現(xiàn)出異常流程

      來自黑龍江 回復(fù)
    2. 我也有同樣的疑惑,業(yè)務(wù)流程本來就涉及各主體,如果加上異常情況,那流程圖就很復(fù)雜了,而任務(wù)流程更簡單,更詳細(xì),卻不寫異常流程,為什么?

      來自四川 回復(fù)
    3. 我的理解是,既然叫業(yè)務(wù)流程圖,那么流程圖里必然包含整個業(yè)務(wù)從頭到尾的信息、數(shù)據(jù)的流轉(zhuǎn),保證業(yè)務(wù)能走通,包含各種分支。異常處理也應(yīng)包含在內(nèi),這樣才是邏輯嚴(yán)謹(jǐn)、面面俱到,有說服力的。

      來自浙江 回復(fù)
    4. 業(yè)務(wù)流程圖只是讓你梳理業(yè)務(wù)的大體流轉(zhuǎn),知曉業(yè)務(wù)是什么的。

      來自河南 回復(fù)
  20. 作者看來要么是哪家電商的實習(xí)生,要么是其他行業(yè)的在yy電商后臺流程。。。

    來自上海 回復(fù)
    1. 對啊,是實習(xí)生啊,但是并不是哪家電商的,只是對這方面感興趣點,如不嫌棄,留微信詳細(xì)交流可否?

      回復(fù)
    2. 能指出問題嘛,新人看不懂。。。。

      來自浙江 回復(fù)
  21. 文章標(biāo)題是“實例解析業(yè)務(wù)流程圖與產(chǎn)品流程圖”,文章第一段“通過電商的實例,將業(yè)務(wù)流程圖和任務(wù)流程圖之間的關(guān)聯(lián)和區(qū)別以及在產(chǎn)品中的應(yīng)用,講解清楚?!?br /> 你講明白你要講的是業(yè)務(wù)和產(chǎn)品流程圖的區(qū)別 還是 業(yè)務(wù)和任務(wù)流程圖的區(qū)別。本來概念就混淆,這不更混淆了嘛

    來自北京 回復(fù)
    1. 講解的是業(yè)務(wù)流程圖和任務(wù)流程圖,這里是標(biāo)題筆誤了,抱歉

      回復(fù)
  22. 可以采用虛擬庫存,然后一段時間后,未支付就自動按照實際內(nèi)容恢復(fù)虛擬庫存的方法?

    來自北京 回復(fù)
    1. 不知道你所說的虛擬庫存,和流程圖中的庫存的區(qū)別。我的理解,這兩者應(yīng)該是同一個概念,即使另開一個空間存虛擬庫存,那虛擬庫存的數(shù)據(jù)也是要和實際庫存的數(shù)據(jù)完全打通的啊,其實也就成了一碼事了

      來自黑龍江 回復(fù)
  23. 而且這里也沒體現(xiàn)物流、運能、ERP流程,也沒有完整逆向流程,缺失了很多環(huán)節(jié)的判斷…

    來自北京 回復(fù)
    1. 您好,小生剛?cè)氘a(chǎn)品不久,對于這個電商購物這方面的流程等相關(guān)可否指點一二?

      來自廣東 回復(fù)
  24. 這個電商流程是有問題的,你這購物車要在訂單的前面,校驗庫存和鎖庫存都要在提交訂單之前,否則會造成大量逆向訂單出現(xiàn)…

    來自北京 回復(fù)
    1. 上面那個業(yè)務(wù)流程,是忽略了購物車的,里面沒有購物車的功能;至于校驗庫存和鎖庫存的問題,是在用戶發(fā)起下單動作之后,到確定生成訂單之前的,不應(yīng)是用戶“提交訂單”動作之前的吧

      來自黑龍江 回復(fù)
    2. 按照你的流程,我填寫配送信息之后,提交訂單,校驗庫存,庫存為0,然后訂單提交失敗,你覺得用戶體驗合理么?并且高并發(fā)怎么處理?提交訂單,讓用戶一直在訂單提交中異步等待么?
      再換個角度,按照你這流程,提交訂單成功了,這時候是直接操作減庫存了,相當(dāng)于你根本沒鎖庫存,商品售賣沒有鎖庫存,ok么?
      希望對你有幫助:)

      來自北京 回復(fù)
    3. 我理解您的意思了,非常感謝您解釋的這么清晰。
      我這個圖中將鎖庫存和減庫存當(dāng)成了一回事,確實不正確;也沒有考慮到配送信息填寫頁之前要進行庫存檢驗的步驟。
      我認(rèn)為并不是在進入配送信息填寫頁時鎖庫存,而是在下單后(支付頁之前)時鎖庫存,這里參考了淘寶雙十一,在雙十一中,也確實存在填寫配送信息成功后,訂單提交失敗的情況,用戶體驗確實很糟糕。而減庫存是在支付成功后進行的。當(dāng)然您說的,在確認(rèn)訂單信息(包括填寫配送信息)頁鎖庫存確實也是可行的,但是這樣,好像和加入購物車時減庫存差別不大,都是在生成訂單之前。還希望能繼續(xù)討論。

      來自黑龍江 回復(fù)
    4. 不聊了,順便說一下,淘寶是在加入購物車鎖庫存的。

      來自北京 回復(fù)
    5. 你好,想順便問下,淘寶如果是在加入購物車鎖庫存的話,拿很多人不都是加入購物車不購買占庫存么?

      來自美國 回復(fù)
    6. 感覺你們這里應(yīng)該有兩個概念,一個是鎖庫存,一個是減庫存。一般電商是有兩種減庫存的方案的,支付減庫存和下單減庫存,主要目的是防止惡意刷單和超賣的情況出現(xiàn)。而庫存鎖定是指在某段時間內(nèi)用戶可以通過下單或加購物車行為將某件商品凍結(jié),用戶有一段時間的商品擁有權(quán),不過這一般都不會是長期的,通常會有一個鎖定庫存釋放時間,避免某些用戶長時間占用,如:未支付訂單或者長期存放購物車的商品,這就說明為何我們在購物車的商品會出現(xiàn)失效的現(xiàn)象。

      來自廣東 回復(fù)
    7. 親自測試,加入購物車并沒有鎖庫存

      來自廣東 回復(fù)
    8. 據(jù)我了解,淘寶是提交訂單鎖庫存,支付減庫存的,叫鎖單/鎖貨,跟京東一樣,訂單取消或超時取消才釋放庫存,國外有些電商是沒有提交訂單再支付這種做法的,一般是提交訂單-支付同時進行的,所以加入購物車就鎖庫存這種方案比較適合國外的電商。國內(nèi)的話,唯品會就是加入購物車就鎖庫存,不過十幾分鐘就要提交訂單,否則釋放,提交后一定時間要支付,否則也釋放。

      來自廣東 回復(fù)
    9. 現(xiàn)在淘寶提交訂單也不鎖庫存了。。。放著沒付款,第二天沒庫存了直接無法付款

      來自福建 回復(fù)
  25. 能否加一下您。我的微信shaowenbin0917

    來自上海 回復(fù)
    1. 可以加的,我的微信號:LeeJX12138(PS:這篇忘記在末尾加微信號了……尷尬)

      來自黑龍江 回復(fù)
  26. 判斷庫存不應(yīng)該放在提交訂單等前面嗎?沒有尊重用戶勞動成果呀

    回復(fù)
    1. 你說的是對的,用戶進入訂單確認(rèn)頁之前應(yīng)該判斷是否超出限購要求、活動是否結(jié)束和是否有庫存的,這里是我遺漏了,感謝提醒

      來自北京 回復(fù)