流程圖=流程圖+圖表。
流程:流程是指特定主體為了滿足特定需求而進行的壹系列具有特定邏輯關系的操作，流程自然存在。但它可以是不規則的，不固定的，充滿問題的。所以好像沒有過程。
圖:圖表或圖示是將具有壹定規則的基本固化流程顯形化、書面化，有利於傳播沈澱，流程重組參考。
從定義中可以看出，只要有事情和任務，就會有流程，但並不是所有的流程都適合用流程圖來表示。適合用流程圖來表示的流程在壹定程度上是固定的、有規律的，流程中的關鍵環節不會經常變化。
●參與者:誰在這個過程中？它可以是壹個系統，可以是壹個打印機，它指的是更多的角色——通常是從事某壹類工作的人。例如，有兩個客戶，小啊和小B，但如果他們的工作性質完全相同，那麽就在流程圖中寫壹個客服角色。
●活動:妳做了什麽，比如點餐，結賬。
●順序:這些事情是什麽順序，哪個任務是其他任務的前提？比如客人不退房，就不會有送他優惠卡的活動。
●輸入:每個活動的開始取決於什麽樣的輸入或數據。例如，當廚師開始烹飪時，他需要獲得特定的菜單。
●輸出:每次活動結束後，會輸入什麽樣的文檔或數據，傳遞給下壹方，比如如何讓負責送餐的人知道廚師做好菜後，菜已經做好了？
●標準化:用壹套標準化的符號來傳達妳的流程圖，讓聽眾更快理解。
常見的流程圖包括事務流和頁面流。
在工作中，作為UED，妳可能會發現PD經常講業務流程，而作為交互設計師，我們制作更多的是頁面流程圖。頁面流程圖和業務流程圖是什麽關系？誰先來，誰接著來？
先說個故事:假設妳的夢想是開壹家中高端的全國連鎖餐廳，那麽妳首先要想的不是如何選址，而是為什麽要開連鎖餐廳，以及妳的定位和核心競爭力。是快餐，還是訂餐，連鎖還是加盟？是位於小區還是繁華商圈？是川菜還是江浙海鮮？是針對中年人還是年輕人？是家庭題材還是動漫題材？競爭對手是誰？需要什麽樣的投資？可能存在哪些風險？這些都想清楚了，問題也有了答案。所謂戰略層面應該是明確的。那麽假設妳現在分析壹下，和主要投資人決定壹個方向:壹個年輕人的時尚卡通茶餐廳，連鎖，但是在杭州開第壹家，定位在年輕人聚會掃街的區域，比如景點，著名商圈，電影院旁邊等等。下壹步是什麽？
下壹步是找到實現這壹目標的方法，對嗎？那麽需要做些什麽呢？選址？拉投資？裝修？選擇餐飲菜單？雇傭員工？每壹步怎麽做，什麽時候做？任務分解和規劃等。，需要去戰術層面。
這些事情的實施，總需要討好人吧？首先，核心團隊分工部署各項建設任務。餐廳開業，需要組織穩定的運營團隊，如服務、衛生、廚房、采購、人事等。廚房裏也有分工，白案，熱菜，涼菜等。各部門是否需要建立管理和報告關系？於是妳的組織架構就誕生了。
那麽各個角色是如何順利配合完成日常穩定和突發任務的呢？比如顧客上門，誰來引導客人坐下，誰來點菜？點餐的信息如何快速傳到廚房，分發到酒房、涼菜房、熱菜房？並且保證客人能盡快吃到自己點的菜？妳要考慮各種人的合作流程，優化效率，於是業務流程就出現了。
人肉已經運營了壹段時間，沒有任何點餐系統妳也能發現是ok的。客人點餐時，服務員手寫下客人的要求。因為有復印紙，服務員可以把復印件送到廚房，同時記下桌號。廚房很小，負責分配任務的工作人員看著菜單，在冷菜處的黑板上寫下自己需要處理的事情，跑到熱菜區的黑板上寫下需要處理的菜，去酒房報名字。但是隨著業務的擴大，上述吃人的方法出現了很多問題。首先，人工抄菜效率太低，客戶頻繁換菜，反應太晚，導致人工抄菜失誤，經常會出現錯菜的情況。廚房裏亂七八糟，我們只好多招幾個人跑腿。壹旦顧客想加菜，撤就更麻煩了。他們需要找出自己當時點了什麽，然後手動標註修改。同時，他們需要修改廚房後端的黑板...
所以妳想開發壹個智能系統來代替大量的人類工作。妳雇傭了壹個系統開發團隊。經過評估，他們判斷該系統可以解決從點餐到上菜的問題。手持終端可以將客戶的點餐要求快速傳輸到打印機，打印系統可以根據客戶的點餐類型自動打印訂單，這樣熱菜房可以看到自己的熱菜菜單，冷菜房可以看到自己的冷菜菜單，酒房可以看到酒店菜單。做好了就送出去，送菜員可以根據菜名和打印的單據送菜，並根據顧客的訂單收據核對。同時這個系統必須配備結算系統，將最終確認的菜單和消費價格傳送到結算前臺，方便收銀員快速操作。
這個系統最終是要展示的，那麽手持終端的界面怎麽設計呢？服務員能否少點擊完成壹道菜的點餐？結算中心的界面怎麽設計？
通過上面的故事，是不是更好的理解了從戰略、戰術、業務流程圖到頁面流程圖的關系？總而言之:
●首先，有壹個業務需求和業務目標，即我們的願景是什麽？(策略)
然後就誕生了我們需要分解什麽任務，如何實施戰術。(戰術)
●那麽，需要架構哪些部門和崗位來協同工作呢？(組織結構)
然後就出現了不同部門合作完成壹項任務的業務流程？(業務流程)
●業務流程基本穩定後，往往會考慮效率優化，所以會誕生壹個系統來支撐流程，減少人肉環節，促進數據收集(系統願景)。
●為了設計這個系統，PD需要思考什麽功能可以代替人肉工作的某個環節(功能需求，系統流程)。
●無論什麽樣的功能最終會以界面的形式呈現，設計師都會關註用戶在系統中的任務流程和行為路徑，讓用戶更高效、更快樂地完成任務。(頁面流量)
當然，除了業務流程之外，還關註系統流程、頁面流程、數據流程。
在我們的日常工作中，經常會聽到人們談論泳道圖、任務流程圖等等概念。神馬關系？
在工作中，我們經常可以看到兩種業務流程圖。從表現形式上來說，有壹種是很好區分的，俗稱“車道圖”，看起來確實像車道，可以有橫車道，也可以有豎車道。在某些文檔中，泳道圖會被稱為“以活動為單位的流程圖”，所有浮動在泳道中的活動都是活動。
泳道圖有幾個關鍵點:兩個維度，活動流和流程要素。
另壹種是以部門和崗位為單位的流程圖。下圖中的圓圈代表每個部門或崗位。矩形代表活動。這種流程圖講究的是事情怎麽做的邏輯，但是在體現各部門的職責方面比較薄弱。如果妳是某個崗位的人，很難像泳道圖壹樣壹目了然的看到自己部門的職責和任務。所以現在用的少了。
流程圖可以提供壹個簡單明了的“簡略鳥瞰圖”，幫助觀眾快速理解業務是如何運作的。它包含幾個關鍵詞:誰、何時、在什麽條件下、做了什麽、輸入了什麽、輸出了什麽、給了誰...
與系統流程不同，業務流程更關註業務本身是如何運作的，講述業務故事，包含業務規則。系統流程是為了滿足業務流程，實現部分或全部流程的信息化和系統化。
所以業務流程是所有環節的前提——軟件需求分析，信息系統建設也會先梳理業務流程。
下面顯示了業務流程圖在三種主要場景中的工作方式:
1，培訓
在這種情況下，流程圖可以提供業務如何運作的快速視圖。通過流程圖，新員工可以快速了解企業的最終目標是什麽，其中涉及哪些角色，他們的職責和他們的關系。
除了培訓新員工，員工還需要參考員工輪崗、調動場景下的業務流程圖，了解新的工作內容是如何進行的，在哪裏，他們的上下遊是誰，需要交付哪些工作內容。
2.流程優化和重組
業務流程再造的存在可以明確反駁:存在即合理。事實上，現有的業務流程並不合理。可能是很多參與者習慣了某種做法，可能是變革沒有影響到終端運營，也可能是缺乏對運行中的業務流程問題的洞察和對變革的強力推動——因為要推動業務流程變革，不是某個部門的事，而是需要流程中所有部門的全力配合。
更多時候，業務流程優化是自上而下的，但老板們可能對實際的業務流程並不是那麽了解，業務流程圖可以很好的表現這種“運營模式”。通過看業務流程圖，找關鍵節點的人去拜訪，可以直接切入:為什麽要這麽做，為什麽不做？從而探討更深層次的問題，而不是問:妳現在是做什麽的？
通過調查、分析業務流程圖和引入更多角色，可以分析出當前業務流程存在的問題:缺失、重復、風險、效率等等。從而制定相應的優化方案。
3、信息技術的基礎
就像上面提到的餐廳夢的案例，信息系統的壹個任務就是解放員工的手腳，代替壹些重復性的人力勞動。系統安裝後，並不是不需要業務流程，而是經過壹些調整，其中壹個參與者變成了系統，或者手持設備，或者打印機。
那麽，在設計系統的功能和流程時，是否有必要了解業務目前是如何運作的？從而更好的分析說明系統在哪個環節取代了什麽類型的人肉工作？
所以我們看到的PRD往往是從業務流程圖開始，在描述壹個系統建設的好處時，也可以把之前的業務流程和系統安裝後的業務流程進行對比。根據分析，遠景中新業務流程圖後面需要系統的功能點寫得很清楚。
首先，繪制業務流程圖本身有沒有流程？肯定有。在軟件工程中聽到壹句話，壹切都是對象。那麽在過程科學中，壹切都是過程。吃飯不是有個過程嗎？就吃的動作而言，有壹個過程:拿筷子——拿菜——入口——咀嚼——吞咽。
那麽，畫業務流程圖有流程可循嗎？我建議可以從以下四個步驟入手。
1，調查
如何快速了解企業經營的真相？有什麽研究技巧可以播報嗎？
2、梳理和呈現
能不能快速把調查得到的文字和問題變成業務流程圖？
業務流程圖的標準圖是什麽？
如何評價壹個業務流程圖的好壞？
3.審核確認——業務流程圖是否能真實反映真實業務？
4.檔案維護——在流程不斷變化的情況下，業務流程圖如何快速響應？
在畫業務流程圖之前，思考如何精致，如何交互，用什麽工具應該不是重點。
真正的要點是收集業務流程圖的關鍵要素。請盡量回答清楚以下問題，否則不要開始畫流程圖:
除了這部分開頭的問題，研究過程還解決了誰、什麽、為什麽、如何、在哪裏的問題:誰做了什麽，在什麽情況下，這個東西需要什麽前提條件，輸出了什麽，這個東西在哪裏完成？如果我們理解了這些問題，我們的研究就能順利完成。
流程圖的性能應該回答這些問題:
1，誰-誰？部門、角色、職位
2.這是什麽？
3.在哪-在哪做的？在我梳理的業務流程圖上，哪裏更多的是壹個文件或者各種制度，用來表示信息化程度。比如當我們發現壹個註冊是用excel而不是業務系統做的，那麽這裏的where可以表示為:excel文檔。
4.文檔-這個文檔的名稱是什麽？也寫了，代表文件的傳遞，而如果以後要進行信息傳遞，這種人肉文件也需要被系統淘汰和替代。(相反，如果這個工作是在某個系統中操作的，在哪裏可以寫成“人事系統”並且文檔可以繼續存在，也就是這個系統中表單的名稱:“員工登記表”)
5.條件-條件。在這種條件下，下壹個活動可以繼續，即壹個活動的輸入和輸出用邏輯鏈接線表示，指向壹個活動的箭頭表示這個活動的預輸入條件。
6.決策。有些活動會產生壹個條件判斷，根據不同的判斷結果采取不同的分支流程。例如，在輸入員工信息時，您可以根據該員工以前是否被雇用來選擇不同的流程。對於已經就業的，可以選擇以前的工號，不生成新的工號。
舉個例子(不合適請諒解)。假設妳奉命調查兩家餐廳的業務流程，以便為他們提供最具性價比的點餐系統。
在調查中:
可以先請精通業務流程的人給妳系統講解壹下。
調查具體操作者，驗證他給妳解釋的是否全面，是否有偏差。
現場觀察和記錄(花時間走壹遍業務流程)
這三種方法相互結合使用。第壹種方法可以讓妳先建立壹個系統的觀點，了解大體的分支，但是很難切入可能會出問題的細節。第二種方法太依賴問題的質量和提問的場景。很多不正確的結論，其實都是因為問錯了人，或者問錯了問題。那麽妳需要用第三種方法在觀察中驗證。
在這些問題中，涉及到分菜、切菜、選菜、烹飪、傳菜、上菜等幾項活動，以及服務員、廚師、助手、刀工、傳菜員等角色。幾個活動的順序也比較明確。
可能廚師不明白下面的問題，只好問點餐人員了。
妳的研究和觀察給了妳烹飪所需的原料。
下壹個任務是不是很簡單？是的，就像填空壹樣簡單。將活動/事件按照壹定的規則填入由部門和時間確定的框架中。
這個階段是紙面工作，妳需要把調研階段收集到的原始資料用更直觀、更清晰的方式呈現出來。以便更好地評估和確認。它還為將來的流程審查和優化做準備。
不可能在壹張圖中呈現所有的活動。
“業務流程是分層次的，這個層次體現在從上到下、從整體到部分、從宏觀到微觀、從抽象到具體的邏輯關系中。這樣的層級關系符合人們的思維習慣，有利於建立企業業務模型和企業部門之間的層級關系表。壹般來說，我們可以先建立主要業務流程(包括整個企業的大戰略)的整體運作流程，然後細化每項活動並落實到各部門的業務流程中，建立相對獨立的子業務流程和為其服務的輔助業務流程。”
——引自百度百科業務流程詞條
對於很多新人來說，做生意最難的就是劃分業務流程圖的層次。
首先明確妳要梳理的業務流程的範圍——用大粗關鍵節點在這個業務流程範圍內講故事，這就是頂層的業務流程圖。妳的頂層業務流程圖是整體業務故事的簡單表達，但請註意，這裏的整體業務不壹定是公司的整體業務，而是妳所定義的業務範圍。比如下圖是餐廳的日常運營流程圖。如果妳的業務範圍是面向客戶的點餐和結賬流程，那麽這就是頂層業務流程圖。但如果定義整個餐廳的業務流程，顯然是壹個子集——不包括餐廳采購、供應商管理、壹級庫存管理等等。
其次，從頂層業務流程分解入手，由粗到細。頂層業務流程圖的梳理原則:
1.定義範圍內的整體業務故事。
2.包括該範圍內的關鍵節點。而且，當被質疑為什麽某個環節不存在的時候，妳要知道，在下壹次分解中，它應該包含在那個關鍵節點裏。比如贈送10周年優惠券要出現在結賬節點分解中。打印訂單將在訂貨節點分解。兒童座椅的準備工作應該是接待和就座。
3.從頂層流程圖分解的關鍵節點可能不會全部被提煉和分解以生成第二層和第三層流程圖。要看節點涉及的“活動”和“角色”是否復雜。
再看壹個案例來分解傳統生產企業的進銷存主要業務流程。橙色代表分解點，可以分解成四層。當我們分解到第四層，發現下壹步涉及的活動和角色很少，就不需要再分解了，而是可以直接把第四層的關鍵節點作為第三層業務流程的“活動”，而不是子流程圖。
當然，這取決於妳梳理業務流程的目標。如果只是想分析優化“打樣”環節，可以繼續分解。
這壹步的工作將幫助妳建立壹個清晰的流程目錄結構，如下圖所示，是從壹個新完成的流程梳理項目中提取的目錄結構部分。可以看出，整個地圖是頂層的關鍵節點。作為老板，看這壹層可能就夠了。下面將對頂層做更詳細的拆解。
“H3。“示例身份驗證”只是頂級業務流程圖中的壹項活動，但在這壹級別的細化中，它將包括詳細的子活動1級參與者。
我壹般用前兩行活動，判斷，邏輯關系行，開始和結束，第二行子流程和文件/表格。如果妳不是符號控，我建議這些就夠了。
其中“子流程”圖標可以幫助妳將流程分解得到的子流程串聯起來。例如，當“A流程”涉及到需要進壹步分解的“A1.1”流程時，可以用子流程符號來表示“A流程”中的“A1.1”。那麽妳的讀者就會明白，要進壹步理解“A1.1”，妳應該參考另壹個流程圖。
流程圖的常見結構:
讓我給妳看壹些案例:
基本上包含大部分圖表的流程圖:
只使用了幾個簡單的帶插圖的流程圖(在臺灣省人的文檔中稱之為程序圖——但這裏的程序不是計算機程序，而是壹個過程，只反映任務之間的處理流程，所以使用極其簡單的符號也就不足為奇了):
以上兩個流程圖案例，從符號的復雜程度來看，壹個是完整流程圖，壹個是基本流程圖，但從表現形式來看，都屬於“泳道”。這也是我們最常用的表達形式。泳道圖可以很好地反映流程中各部門或角色的職責以及上下遊的合作關系。而且流程圖本身的標準也容易掌握，更容易達到* * *的理解。
驗證自己是否做到了以上do，避免Donnot的做法是什麽？
非常好辦，及時跟妳復習。把所有利益相關者召集到壹起，向他們展示妳整理出來的結果。
這樣會發現壹些有趣的東西，除了判斷妳的流程圖是否符合現實，還會判斷目前的業務流程是否符合理想。不同部門、不同崗位的代表會在這次評審中確認現狀，也會互相發表意見，甚至爭吵，這是流程優化的好機會。暫時不看。