本文會包含幾塊內容：
流程圖= 流程+圖。
流程：Flow, 是指特定主體為了滿足特定需求而進行的有特定邏輯關系的壹系列操作過程，流程是自然而然就存在的。但是它可以不規範，可以不固定，可以充滿問題。所以就會造成看似沒有流程。
圖：Chart 或者 Diagram , 是將基本固化有壹定規律的流程進行顯性化和書面化，從而有利於傳播與沈澱、流程重組參考。
從定義可以看出，只要有事情和任務，流程就會有，但是並不是所有的流程都適合用流程圖的方式去表現，適合用流程圖去表現的流程是壹定程度固定的有規律可循的，流程中的關鍵環節不會朝令夕改的。
● 參與者 ：誰在這個流程中？可以是系統，可以是個打印機，更多的指什麽角色——壹般是有某種工種的人。比如客服同時有小A和小B兩人，但是若他們的工作性質完全壹樣，那麽在流程圖裏只需要寫壹個客服角色就可以了。
● 活動 ：做了什麽事，比如點餐，結帳等活動。
● 次序 ：這些事情發生的前後順序如何，哪個任務是其他任務的前置條件？比如客人不結帳，就不會產生送他優惠卡的活動。
● 輸入 ：每項活動開始取決於什麽樣的輸入物或數據，比如做飯的師傅開始做菜時，需要拿到具體的點菜單。
● 輸出 ：每項活動結束後，會輸入什麽樣的文檔或數據傳遞給下壹方，比如師傅做好菜後，如何讓負責傳菜的人知道菜已經做好？
● 標準化 ：采用壹套標準化的符號用以傳遞妳的流程圖，從而使受眾更快明白。
常見的流程圖有業務流程圖（Transaction Flow）, 頁面流程圖（Page Flow）。
在工作中，作為UED，妳可能會發現PD經常談的是業務流程，而作為交互設計師，我們更多產出的是頁面流程圖。頁面流程圖和業務流程圖到底有什麽關系呢？ 先有誰，其次再有誰呢？
先講個故事：假設妳的夢想是開個中高檔的全國連鎖餐館，那麽首先妳想到的應該不是如何去選址，而是將為何要開連鎖餐館這件事情，以及妳的定位，核心競爭力想清楚。是快餐，還是點餐，是連鎖還是加盟？定位於社區還是繁華商圈？是川菜還是江浙海鮮？是面向中老年還是年輕人？是家庭主題還是動漫主題？競爭對手是誰？需要什麽樣的投資？可能的風險是什麽？這些都想清楚了，問題都有答案了，所謂戰略層要清晰了吧。然後假設妳現在分析來分析去，與主要投資方決定了壹個方向：面向年輕人的時尚動漫茶餐廳，連鎖，但是先在杭州開始第壹家，選址定位於年輕人約會，掃街的地域，比如風景區，著名商圈，電影院旁…………等等等等，那麽接下來呢？
接下來就是想辦法讓這些實現吧？那麽需要做什麽事情呢？選址？拉投資？搞裝修？選餐飲菜單？雇傭員工？每壹步怎麽去做，時間點是什麽？等等的任務拆解以及計劃，就需要到戰術層了。
這些事情的執行，總是需要請人的吧？先是核心團隊分工去部署各項建設任務，當餐廳開設起來後，就需要組織穩定的運營團隊，如服務、衛生、廚房、采購、人事等等，廚房裏面還得分工，白案，熱菜，冷菜等等吧？每個部門需要設置管理層以及匯報關系吧？所以妳的組織結構就誕生了。
那具體每種角色是如何順暢合作完成日常穩定的以及突發的各項任務呢？比如，當顧客上門時，誰去引導客人入座，誰去點菜，怎麽將點菜的訊息迅速傳遞到廚房，並分發到酒水間、冷菜間、熱菜間？並保證客人盡快能夠吃到所點的菜？妳必須要考慮各種人員的協作流程，優化效率，所以業務流程就出現了。
人肉運營了壹段時間，沒有借助任何點餐系統，妳發現也還可以。客人點菜時，服務員手抄寫下客人的要求，因為有復印紙，所以服務員能夠將副本送入廚房，同時寫下餐桌號碼。廚房規模較小，負責分配任務的員工看下菜單，分別往冷菜處的黑板上寫下需要他們處理的，以及跑到熱菜區的黑板上寫下待處理的菜品，以及去酒水間報下品名即可。可是隨著經營的擴大，以上的人肉方式出現了很多問題，首先，手抄效率太低，顧客頻繁換菜，響應來不及，手抄出錯，導致經常報錯菜。廚房很混亂，不得不多招了幾個人專門跑堂。而壹旦顧客要加菜，撤菜就更麻煩了，需要找出他們當時點的菜，再進行人工的批註和修改，同時要修改廚房後端的各個黑板……
所以妳們想要開發壹套智能系統，取代很多人肉工作，妳們請了系統開發團隊，他們經過評估，判斷從點菜開始，壹直到傳菜都可以用系統解決。手持終端，能夠快速傳遞顧客點菜需求到打印機，打印系統能夠根據顧客點菜的類型進行自動的分單打印，所以熱菜間看到自己的熱菜菜單，冷菜間看到自己的冷菜菜單，而酒水間看到酒店菜單。當他們準備完畢後，送出，傳菜員可以根據菜名與打印出來的單據進行傳菜並根據顧客的點菜小票進行核對。這套系統同時必須配備結算系統，將最終確認掉的菜單及消費價格傳遞到結算前臺，收銀員能夠快速進行操作。
這套系統最終是需要展現出來的，那麽手持終端的界面如何設計？服務員能夠用更少的點擊完成壹個菜的點餐嗎？結算中心的界面如何設計？
通過以上的故事，是不是更明白從戰略、戰術、業務流程圖到頁面流程圖的關系了？總結下：
●先是有壹個業務需求和業務目標，也即我們的願景是什麽？（戰略）
●然後就誕生了我們需要分解出什麽樣的任務，如何執行戰術？（戰術）
●然後就誕生了需要架構什麽部門，崗位去分工協作？（組織架構）
●然後就誕生了不同的部門在協作完成某件任務時的業務流程？（業務流程）
●業務流程基本穩定後，往往會考慮優化效率，所以會誕生出系統來支持流程，減少人肉環節，促進數據采集（系統願景）
●為了設計這個系統，PD需要思考什麽功能能夠取代某個環節的人肉工作（功能需求，系統流程）
●不管是怎麽樣的功能最終都會以界面的方式呈現，設計師們會關註用戶在系統裏的任務流，行為路徑，讓用戶完成任務更加高效愉悅。（頁面流程）
當然，除了業務流程，系統流程，頁面流程，還有數據流程被人關註。
我們平時工作中，還會經常聽人談到泳道圖啊，任務流程圖啊等等概念，究竟是神馬關系呢？
在工作中，我們經常能夠看到兩種業務流程圖，從表現形式來看，壹種很好區分，俗稱為“泳道圖”的它，在樣子上也確實像個泳道，可以有橫向的泳道，也會有縱向的泳道。泳道圖在某些文檔裏會被稱為“以活動為單位的流程圖”，浮在泳道中的都是壹個個活動。
泳道圖有幾個關鍵點：兩大維度，活動流轉，流程要素。
另外壹種類型是以部門和崗位為單位的流程圖，下圖中的圓形就代表壹個個部門或崗位。矩形代表活動。這種流程圖關註事情如何完成的邏輯，但是在體現各個部門的責任上比較弱。如果是某個崗位的人來看，很難像泳道圖那樣壹眼就能看到自己部門的職責和任務。所以現在用得比較少。
流程圖可以提供壹種簡單扼要的“縮略俯瞰圖”，幫助觀眾快速了解業務如何運轉。它包含了幾個關鍵詞： 誰，什麽時候，在什麽條件下，做了什麽事情，輸入什麽，輸出什麽，輸出給誰……
與系統流程不同，業務流程更關註於業務本身如何運作，講的是業務故事，包含的是業務規則。而系統流程則是滿足業務流程，實現部分流程或全部流程的信息化和系統化。
所以業務流程是所有環節的前置條件——軟件需求分析，信息系統建設也會先進行業務流程的梳理。
下面表現了業務流程圖是如何在三個主要場景中發揮作用的：
1、培訓
在此場景中：流程圖能夠提供壹種快速了解業務如何運作的視圖，通過業務流程圖，新員工能夠快速明白業務的最終目標是什麽，中有哪些角色在參與以及他們的職責，以及彼此之間的聯接。
除了培訓新員工，在員工輪崗、調職場景中，員工也需要業務流程圖參考，明白新的工作內容如何開展，以及自己所處的位置，自己的上遊是誰，下遊是誰，自己需要交付的工作內容是什麽。
2、流程優化與重組
業務流程重組（Business Process Reengineering）的存在可以明確反駁：存在即合理。事實上，存在的業務流程並未是合理的，有可能是參與的多個角色習慣了某種做法，有可能是變革尚未影響到末端的操作，也有可能缺乏對於運行中的業務流程問題的洞察以及強有力的變革推動——因為要推動業務流程變革，不是某個部門的事情，而是需要流程中各個部門的通力配合。
更多時候，業務流程優化是自上而下的，但是老板們未必對實際運作的業務流程那麽心知肚明，業務流程圖能夠很好去表現這個“運作模型”。通過看業務流程圖，找關鍵節點的人訪問，能夠直接切入：為什麽要這麽做，為什麽不這麽做？從而探索出更深層次的問題，而不是問：妳們現在怎麽做？
通過調研，分析業務流程圖，引入更多角色，能夠分析出目前業務流程的問題：缺失，重復，風險，效率等等。從而制定相應的優化方案。
3、信息化的基礎
正如上文所述的餐館夢想的案例，信息系統的壹項任務就是解放員工的手腳，取代壹些重復的人力勞動工作。系統上了之後，不是說業務流程不需要而是經過了壹些調整，其中某個參與者變成了系統，或手持設備，或打印機而已。
那麽在做系統的功能設計和系統流程設計時，是不是必須先要了解目前業務是如何運作的呢？從而更好分析分析，更好說明系統在什麽環節取代了什麽類型的人肉工作？
所以我們看到的PRD往往也會先以業務流程圖開始說明，而敘述壹個系統建設的好處時，也可以用以前的業務流程與系統上了之後的業務流程進行對比。根據分析，將願景中的新的業務流程圖背後需要系統的功能點撰寫清楚。
首先繪制業務流程圖本身有沒有流程？壹定是有的。在軟件工程學裏聽說壹句話叫：萬物皆對象。那麽在流程學裏，萬事皆流程。吃飯難道沒流程嗎？就吃飯的動作而言，就有流程：拿筷子——夾菜——入口——咀嚼——吞咽。
那麽，繪制業務流程圖有沒有可遵循的流程呢？我建議可以從下面4步著手。
1、調研
如何快速了解業務運作真相？有沒有調研的技巧放送？
2、梳理與呈現
能否快速將調研得到的文字和問題，快速轉化為業務流程圖？
業務流程圖的標準圖示是什麽？
怎麽評價壹個業務流程圖的好與壞？
3、評審與確認——能否真正讓業務流程圖反映現實中的業務？
4、歸檔維護——流程不斷變更，業務流程圖如何快速響應？
在繪制業務流程圖前，思考如何精美、如何交互以及使用什麽工具，都不應該是重點。
真正重點的是將業務流程圖的關鍵要素給搜集壹番。請試圖回答清楚以下幾個問題，否則不要開始繪制流程圖：
除了在本部分開始的那幾個問題要顧及到， 其實調研過程解決的仍然是who，what，why，how，以及where的問題：誰，在什麽情況下，做了什麽事情，這個事情需要什麽前置條件，又輸出了什麽，這個事情在哪裏完成的？ 搞明白這幾個問題，我們的調研就可以圓滿完成了。
流程圖的表現，要回答這幾個問題：
1、Who——誰？部門，角色，崗位
2、What——什麽事情？
3、Where——在哪裏做的？在我梳理的業務流程圖上，where更多表示是文檔還是各種系統，用來表示信息化的程度。比如當我們梳理中發現，有壹項登記，是用excel而不是業務系統來進行的，那麽在這裏的where就可以表示為：excel文檔。
4、Document——那產生的這份文檔叫什麽名字？也寫出來，代表有文件的傳遞，而以後要進行信息化的話，此份人肉文檔也是需要被消除而被系統取代的。（相反，如果這項工作是在某個系統裏操作的，where就可以寫成“人事系統”，文檔可以繼續存在，即該系統中的表單名稱：“員工登記表單”）
5、Condition——條件。在這種條件下，下壹個活動還能夠繼續，即用邏輯鏈接線的方式來表示壹項活動的輸入和輸出，指向某個活動的箭頭就表示此活動的前置輸入條件。
6、Dicision——決策。有些活動會產生壹個條件判斷，根據不同的判斷結果從而走不同的分支流程。比如輸入員工信息的時候，可以根據員工之前是否就職過，選擇不同的流程，對於已經就職過的，選用之前的工號而不用生成新的工號。
舉個案例（如果不太恰當，請意會）。假設妳受命要調研兩家餐飲店的業務流程，目的是給他們提供性價比最高的點餐系統。
在調研中：
妳首先可以要求精通業務流程的人給妳系統講解壹遍。
調研具體操作的人，來驗證他給妳講解的是否全面和偏差。
實地觀察和記錄（花點時間走遍業務流程）
三種方式相互結合使用。第壹種方法可以讓妳首先建立壹個系統觀，了解大體枝幹，但是很難切入到可能會出現問題的細節。第二種方法太依賴於問題的質量以及問問題的場景。有很多結論的不正確其實是因為問錯了人或者問問題的方法不對。那麽就需要借助第三種，在觀察中再進行驗證。
在這些問題中，就涉及到了“分單”，“切菜”，“擇菜”，”烹飪”，“傳菜”，“上菜”幾個活動，也涉及到了“服務員”，“廚師”，“助理”，“刀工”，“傳菜員”幾個角色。幾個活動的次序也比較清楚了。
下面的問題，可能廚師就不了解了，要問點菜員了。
妳的調研和觀察使妳擁有了“烹飪”所需的原材料。
接下來的任務是不是很簡單，對，就像填空題壹樣簡單。將活動/事件按照壹定的規則填到由部門和時間兩條維度決定的框框裏。
這個階段是paper work，妳需要將調研階段收集到的原材料用更直觀明了的方式呈現出來。從而能夠更好進行評審和確認。也為以後的流程評審和優化做準備。
不可能將所有的活動都放到壹張圖裏呈現。
“業務流程是有層次性的，這種層次體現在由上至下、由整體到部分、由宏觀到微觀、由抽象到具體的邏輯關系。這樣壹個層次關系符合人們的思維習慣，有利於企業業務模型的建立 企業部門之間的層次關系表。壹般來說，我們可以先建立主要業務流程的總體運行過程（其中包括了整個企業的大的戰略），然後對其中的每項活動進行細化，落實到各個部門的業務過程，建立相對獨立的子業務流程以及為其服務的輔助業務流程。”
——引自《百度百科》 業務流程詞條
對於很多新人來講， 業務最難的在於劃分業務流程圖的層次上。
首先，明確妳要梳理的業務流程的範圍 ——用大的粗略的關鍵節點，講清楚這個業務流程範圍中的故事，就是頂層業務流程圖。妳的頂層業務流程圖是業務全局故事的簡單表達，但是請註意這裏的業務全局不見得是公司整體的業務全局，而是妳界定好的業務範圍。比如，下圖是餐廳的日常運作流程圖，若妳界定的業務範圍是面向顧客的點餐和結帳流程，那麽這就是頂層業務流程圖。但是若妳界定的是整個餐廳的運作業務流程，那這顯然還是壹個子集——並沒有包含餐廳的采購、供應商管理、壹級庫存管理等工作。
其次，先從頂層的業務流程分解開始，由粗至細。 頂層業務流程圖的梳理原則：
1、界定範圍內的業務全局故事。
2、包含該範圍內的關鍵節點。並且，當被質疑說某某環節怎麽不存在時，自己要清楚它在下壹層分解中應該被包含在那個關鍵節點中。比如，贈送10周年優惠券，應該會在結帳節點分解中出現。而打印分單，會在點菜節點中分解。而準備兒童座椅應該是接待入座環節。
3、頂層流程圖分解出來的關鍵節點未必都會細化分解下去，生成二級以及三級的流程圖。這要看該節點涉及到的“活動”以及“角色”是否復雜。
再看壹個案例，對傳統生產型企業的進銷存主業務流程進行分解。橙色的代表被分解點，已經可以分解為四層。當我們分解到第四層，發現再往下去涉及到的活動和角色都已經很少時，就不必再分解了，而是可以將第四層的關鍵節點直接作為第三層業務流程的“活動”，而不是子流程圖。
當然，這是依賴於妳梳理業務流程的目標。如果妳偏偏是要對“打樣”環節進行剖析優化，則還可以繼續分解下去。
這壹步的工作會幫妳建立出清晰的流程目錄結構，如下圖所示是摘選於剛完成的壹個流程梳理的項目中的目錄結構部分。可以看到全圖即是頂層關鍵節點，作為老大，可能只要看這壹層就夠了。下面則會對頂層做更多細化拆解。
“H3.樣品認證”在頂層業務流程圖中，僅僅是壹個“活動”，而在自己細化的這壹個層次中，則會包含詳細的子活動壹級參與者。
我常用的就是前兩行的“活動”，“判斷”，“邏輯關系線”，“起始與終止”，以及第二行的“子流程”，和“文件/表單”。如果妳不是符號控，我建議這幾個就足夠了。
其中，“子流程”此圖示就是可以幫助妳將流程分解得到的子流程能夠串聯起來，比如，當在”A流程”中涉及到進壹步需要分解的”A1.1流程”時，就可以在”A流程”中用子流程符號代表“A1.1”。然後妳的讀者就會明白要想進壹步了解”A1.1″應該參考另外壹個流程圖。
流程圖的常用結構：
給大家看壹些案例：
基本上包含大多數圖示的流程圖：
只用到少數幾個圖示畫的簡單流程圖（臺灣人的文檔中稱為程序圖——不過這裏的程序不是指計算機程序，而是process，僅僅是體現任務之間的處理流程，所以使用極簡單的符號也不為怪了）：
以上兩個流程圖案例，從符號的復雜程度上來講，壹個是完整流程圖，壹個是基本流程圖，但是從表現形式來講，都屬於“泳道圖”——Swimlane。這也是我們最常用的壹種表現形式了。泳道圖能夠很好體現部門或者角色在流程中的職責以及上下遊的協作關系。且流程圖本身的標準容易掌握，達成***識也就更加容易。
驗證妳是否做到了以上的DO，以及規避了Donnot的做法是什麽？
很好辦，及時與各位進行評審。將各個涉眾都叫到壹起，給他們看妳梳理出來的成果。
這會發現壹些有意思的事情，除了評審妳的流程圖是否符合現實外，也會評審目前的業務流程是否符合理想。不同的部門和崗位的代表會在這個評審中，確認當前，也會相互提出意見，甚至吵起來，這不失於做流程優化的壹個很好的契機。暫且不表了。