教你如何做好工作流程梳理「業務流程梳理方法和價值」

1、業務流程的梳理

a：流程圖的基本認知；

1、流程圖=流程+圖，流程是一系列的邏輯關係（包含因果關係、時間先後、必要條件、輸入輸出）產品經理做需求前一定要先把這些邏輯關係理清楚，如果非要用一句話概括的話「流程就是在特定的情境下滿足用戶特定需要的總結」。

圖就是將你頭腦中的邏輯關係以圖形化的形式呈現出來，具有圖形化、可視化的特點，因為是圖，你可以像你的版本迭代一樣，當你的邏輯需要修改的時候拿出來迭代一下，同時因為有圖，你還可以更好的給項目成員進行宣講。

b：為什麼要畫流程圖；

1、幫助梳理邏輯

我們每個人想一個邏輯的時候，不一定能把這個邏輯的細枝末節都想到，如果我們貿然的畫原型就有可能做許多無用功，這個時候畫流程圖可以幫助我們梳理清楚我們的邏輯。建議剛開始梳理邏輯的時候可以在紙上畫畫這種流程圖，因為這樣的好處是你可以快速的把你腦中的邏輯呈現在紙上，修改起來也方便，當你畫好以後然後再用專業的工具畫出來保存。

2、便於宣講和傳播

產品經理需要開評審會和寫PRD文檔的，這個時候如果你有一張清晰的流程圖，不僅便於你講解，也便於技術理解，同時把你的流程圖插入PRD文檔中也方便傳播，當技術忘記流程的時候，查看一下文檔里的流程就知道流程是啥樣了，不用反覆來找你確認。

3、優化迭代

對於拿到一個邏輯，我們不一定能考慮的那麼周全，這個時候有一個清晰的流程圖也方便做記錄以及修改。

同時每個版本迭代的流程圖可能會有相應的變化，通過對每個版本流程圖的對比分析，可以知道流程優化在什麼地方，產品優化了什麼地方。

c：流程圖元素定義；

流程圖是符號化的圖形語言，有自己的規範，菱形代表判斷，距形代表具體的操作行為、開始和結束用圓角表示…

eg：–流程圖代練；

d：產品中設計的流程圖主要有3種，業務流程圖、任務流程圖、頁面流程圖；

1、業務流程圖就是描述那些個體在什麼條件下做了什麼事情，他們之間有何關聯。主要分三個方面：①涉及到哪些主體？②每個主體都有哪些任務？③各個主體之間怎麼聯繫的？

主要包括流程所涉及到的系統或角色模塊有哪些、確定用戶使用的階段有哪些、最後按照用戶的操作流程來補充。

以滴滴出行為例：

系統模塊：包含前端和後台系統；用戶角色：包含了用戶和司機兩大類角色。

使用階段：可以大體劃分為用戶下單階段、滴滴派單階段、行程開始——結束階段。

eg-登陸註冊：

eg：億圖軟體—用戶下單-平台處理並派發–司機接單；

2、任務流程圖通常指的是確定了業務流程圖中某一固定主體的具體操作流程圖，通常是業務流程圖的簡化版。

3、頁面流程圖

總結：任務流程圖注重不同系統之間的交互和邏輯關係；任務流程圖注重某一個具體的任務操作流程。對於一個產品來說，發現已有流程中的問題，或者是創造一個邏輯嚴謹、操作簡便的流程圖尤為重要，業務流程圖示根據任務流程圖梳理出不同角色和不同狀態下的呈現效果，頁面流程圖是對業務流程圖的聚象化體現。

2、許可權劃分–用例圖

a：用例圖（Use Case Diagrame）：描述了人們希望如何使用一個系統，將相關用戶、用戶需要系統提供的服務以及系統需要用戶提供的服務更清晰的顯示出來，以便使系統用戶更容易理解這些元素的用途，也便於開發人員最終實現這些元素。

b：為什麼要畫用例圖–用戶並不關心系統的實現和內部結構，只關心產品所呈現出來的外部特徵動態。而用例圖恰好就是描述軟體產品外部特性的視圖，它從用戶的角度而不是從開發者的角度來描述需求，分析產品的功能和動態行為。

c：用例圖包括三方面內容：參與者（Actor）; 參與者、用例之間的關係，用例（Use Case）;。用例圖模型如下圖所示，參與者用人形圖標顯示，用例用橢圓形表示，連線描述之間的關係。

a：參與者：

1、參與者是系統外部的一個實體，它以某種方式參與了用例的執行過程，在UML中，通常用名字寫在下面的人形圖標表示。

a：真實的人，即用戶

這一類是最常用的參與者，幾乎在每個系統中。在命名這一類參與者時，應該按照業務而不是位置命名，因為一個人有可能有多重身份。

比如：汽車租賃公司的客戶服務代表，通常情況下是客戶服務代表，但在她有租賃行為時，就變成了客戶。因此，按照業務而不是位置命名可以獲得更加穩定的參與者。

b：其他的系統

在有的系統中，還需要建立與其他系統的介面，依然以汽車租賃系統為例，它可能要與外部應用程序建立聯繫，比如：說外部信用卡應用程序，這時候外部信用卡應用系統就是一個參與者。

c：可運行的進程

以時間為例，當經過一定時間觸發系統中的某個時間時，時間就成了參與者。比如：在汽車租賃系統中，到了還車時間客戶仍未歸還，系統便會提醒客戶代表致電客戶。由於時間不再在人的控制內，因此它也是一個參與者。

2、參與者間的關係：

對於一些參與者來說，它既扮演者自己的角色，同時也扮演更一般的角色，在案例圖中用泛化關係來描述他們（此點與上一節類圖中介紹的泛化關係類似）。

b：用例：

1、概念：是對系統的用戶需求（主要是功能需求）的描述，用例表達了系統的功能和所提供的服務，描述了活動者與系統交互中的對話；以汽車租賃系統為例，客戶向系統發出租賃請求，並向系統中輸入數據（姓名等信息），系統響應活動者的請求，進行相應的處理，並且將結果返回活動者。

2、用例與事件流—用例分析處於系統的需求分析階段，這個階段盡量避免考慮系統實現的細節問題。但若要建立系統還需要更加具體的細節，這些細節可以寫在事件流中。

事件流描述的是一個系統做什麼，而不是怎麼做，舉個栗子，在汽車租賃系統中用例「用戶登錄」可以採取一下方法：

主事件流：客戶輸入自己的用戶名和密碼時，用戶開始。輸入的用戶名和密碼被提交後，伺服器判斷密碼是否正確。如果正確，則用戶成功登錄，系統為其展示租賃頁面。
異常事件流：用戶名或密碼錯誤，不能登錄，用例重新開始。
異常事件流：在提交密碼前，用戶清楚用戶名或密碼，重新填寫。

c：參與者、用例之間的關係

1、關聯關係；–這是最常使用的關係，用帶箭頭的實線來描述。以汽車租賃系統中的「客戶」參與這以及和他交互的3個用例（預定、取車和換車）為例。

2、泛化關係–一個用例可以被列舉為多個子用例，這就被成為用例泛化，這與類間的泛化關係類似。在用例泛化中，子用例表示父用例的特殊形式，可從父用例處繼承行為和屬性。泛化關係的圖形用空心實線箭頭表示，箭頭指向父類。

如下圖所示是汽車租賃公司用例圖中的用例「預定汽車」，該用例有兩個子用例「預定大巴中巴」和「預訂小車」。

3、包含關係–指的是其中一個用例（稱為基礎用例）的行為包含了另一個用例（稱為包含用例）。

基礎用例包含用例並依賴包含用例的執行結果。但是二者不能訪問對方的屬性。包含關係的圖形為虛線箭頭加>，箭頭指向包含用例。

4、擴展關係–擴展用例可以被定義為：基礎用例的增量擴展，它倆之間為擴展關係。

簡單來說，就是當某特定條件出現時，該擴展用例的行為才會被執行。擴展關係的圖形為虛線箭頭加上>>，箭頭指向基礎用例。

如下圖，客戶在還車超過了一定期限就需要繳納罰款，其中「借車超期」為特定條件，只有該條件出現，才執行「繳納罰款」用例行為，「還車」用例和「繳納罰款」之間就是擴展關係。

3、電商平台泳道圖的搭建

a：泳道圖的定義：泳道圖也叫跨職能流程圖，旨在展示工作流中每個步驟涉及的流程和職能部門。泳道流程圖是一種特殊的圖表可以展示出一個商業過程之間的關係，並展示為那個過程負責的功能板塊（比如說部門）。泳道流程圖專註於價值活動之間的邏輯關係，更好地展示每個價值活動的責任。

b：如何繪製泳道圖

1、分析功能的關鍵邏輯。確定涉及的所有人員和部門；確定每個人扮演的角色，承擔什麼任務，梳理參與者的關係；要完成的任務，以及任務流程。

2、明確開始與結束的路徑。每個功能模塊中，從哪裡開始流程，到哪裡終結流程；開始與結束只有一個。

3、確定功能模塊與核心路徑。核心流向一定要清晰。

4、優化順序，合併異常流程。確保流程順暢，各部門工作協調。

5、合併和拆分流程有依據。先複雜後簡單，先加法後減法；調研相關產品，合併、分拆有理有據。

4、功能結構圖與信息架構圖

a：功能結構圖就是按照功能的從屬關係畫成的圖表，在該圖表中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分得大一點或小一點，分解得最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序。（百度定義）用通俗的話來說，功能結構圖就是以功能模塊為類別，介紹模塊下其各功能組成的圖表。