說到流程的表達方式，所有人都會在腦海里立刻浮現出那種圖形的模樣，就是流程圖。它是一種語言，為我們講述事情是怎么發生的。

?

它表述了四個問題，我們可以用四個“W”來表示：When，What，Who和Why。什么情況下會發生的？發生一件什么事？這件事是誰做的？結果怎么樣？

我們把這種流程的圖形化表述叫做流程圖，甚至有的時候我們一說到流程也是專指繪制出來的流程圖。

流程的表達方式也經歷了一個逐步演化和發展的過程，大致可以分成四個時期。

業務邏輯圖

80年代，早期的流程圖很簡單，我們用來表達一個業務的基本邏輯，目的是很直觀地呈現一系列動作之間的邏輯關系，我們可以叫它業務邏輯圖。沒有我們今天說到的眾多流程要素和圖例，甚至我們也不用在乎語言的標準，沒有關系，只是為了能夠表達文字難以表達的邏輯關系，便于我們溝通和討論。沒有專業的流程圖工具，可以是一種繪圖軟件甚至只是紙筆來完成它，當然我們也并沒有很多將它們用于管理的期待。

?

泳道流程圖

90年代，我們有了管理的需求，有了專門的流程圖工具，開始用泳道流程圖，Visio這個工具至今我們依然非常熟悉。研究流程的人都用過Visio，它是用一個頁面的方式來表達一段流程。泳道流程圖有很典型的特征，那就是分泳道。泳道用來表達完成這段流程活動的具體部門或者是某些角色。一般從上面開始，經過一系列動作組合之后，在下面會有一個結束。其中有動作符號、判斷符號，也有引用和附加的文本等要素信息。用這種方式做的流程圖，一般都會附加一頁流程說明，在流程說明里面我們會比較詳細的列出來這段流程相關的更多信息。包括每個動作相關的屬性，目的、參與人的職責、衡量的指標、參考的標準、輸入和輸出等等。為什么要附帶這樣的說明？因為我們有相關的管理需要，而在這樣的流程圖工具中沒有辦法表達多個維度的要素，所以為了把事情說清楚會附加這些具體的說明。

?

全息流程圖

00年代，流程管理開始有了平臺化的工具，平臺和繪圖工具的顯著區別就是背后有了數據庫，它們可以承載多維度的流程信息，然后根據我們的需要來呈現流程，而不再像從前一樣用一個頁面附加繁雜的說明來展現大量的信息。從工具到平臺是一個跨越，這是基于我們對于流程的認識和管理需要的不斷深入應運而生的。

首先，它具有更大的信息承載能力，可以不斷補充和修改流程圖和要素的信息；再者，它體現了流程的層級機構，可以逐層從宏觀到細節地展開流程，而且可以將繪制的流程片段鏈接起來，流程可以形成完整的整體；還有就是它具有了管理功能，也可以多人平臺化地協作、授權和管理這些流程圖。雖然信息量大了，但是它的視覺上卻更加友好了，我們給它起個名字叫全息流程圖。

?

仿真流程圖

10年代，人們不再滿足于只是用工具來呈現流程，隨著管理更加需要數據化，以及類似于ERP、PLM這樣大型的企業管理軟件的應用，人們更加希望能夠讓流程管理平臺的輸出結果更容易被那些管理和業務的系統軟件所應用。于是更強大的管理平臺應運而生，就是現在我們普遍說的BPM平臺。

在這樣的平臺上，首先，描繪流程的語言逐漸形成了通用標準，比如BPMN的標準符號語言被普遍采用，這些符號在平臺上被賦予數據定義；繪圖演變成了建模，實際上我們的工作不只是把流程講清楚讓人們看懂，而是需要遵從嚴格的標準語言將真實的流程再現出來；然后，具有數據含義的流程圖可以進行數據分析，可以模擬真實的環境仿真運行，這對于流程優化具有非常重要的意義；還有更令人振奮的結果是，我們甚至可以用這樣的平臺來設計流程，然后通過中間件將某些流程植入到IT系統中實現自動運行。

?

上圖中形成的表格就是這段流程仿真運行之后得到的數據。我們給它起個名字叫仿真流程圖，雖然它已經不僅僅是一張圖。

這是流程表達方式經歷的四個階段，我們現在只是在探討流程的視覺表達，關于軟件我會在另外的專題里面去專門說明。

很多人在暢想著這樣一個未來：企業應用軟件的開發不再是那些寫代碼的工作，而主體是管理工作，由管理和業務人員來繪制流程，然后通過BPM平臺直接就能轉化成可以執行的軟件，我們稱之為敏捷開發。這樣的未來是可以預見的，因為那些有嚴密邏輯性的苦工正是計算機所擅長的，而人類的智慧應該體現在設計上。

語言的標準

隨著流程表達方式的演進，流程的語言也在變化。最早的業務邏輯圖，語言的規范不重要，因為可能我們只需要用它們來幫助我們看懂一些活動的關系。在后來泳道流程圖的時候開始形成了一些規范，但是這種規范是建立在片段流程圖的基礎上，只是為了讓管理人員和操作人員能夠看懂和傳遞這些規范。但是漸漸地演進，到了全息流程圖和仿真流程圖的年代，流程的語言規范就顯得越來越重要，因為流程的應用范圍在逐漸擴大。包括整合各種管理功能，包括流程分析，也包括IT開發的支持。

聽起來有點復雜，其實說到根本流程圖就是一種語言，就像我們的語言從古代漢語轉變成現代漢語一樣。這套語言能夠幫助我們對話，不僅是業務人員之間，也有管理和業務人員之間，也有業務和IT人員之間，我們需要一套標準的普通話，然后所有的事情我們都能相互聽懂了。

流程表達的語言標準，現在普遍采用的是BPMN的標準語言。這是BPMN這個國際組織在04年發布的，一套完整的流程描述模型和符號，能夠在業務和管理、業務和業務、業務和IT之間，形成一個對話，得到了IBM、Oracle、SAP等一些軟件商和公司的認可。2011年又升級了一個2.0的版本。這套模型和符號中，定義了流程的各種要素，包括活動、事件、網關、數據，以及各種流程活動和要素之間的邏輯關系的表達規范。

?

BPMN標準符號語言與我們傳統使用的流程符號語言相比有很大概念上的差異。比如有事件的概念，用來表達一種狀態，觸發流程活動的一種狀態，或者流程活動發生之后的狀態。還有網關，我們可以將其理解為邏輯關系的開關，用來定義多個分支狀態時什么條件下走什么樣的路徑。最簡單的網關就是一個判斷，YES走一條路徑，NO就走另外一條路徑。現實中還可以存在并行的網關、多重選擇的網關。具體細節我們可以找相關資料來參考。

?

這是一個包含10個活動的流程圖，我們分別用兩種語言表達來進行對比。上面是用最簡單的業務邏輯圖來表達的，下面的是用BPMN的語言來表達的，活動都是一樣多，但是很明顯BPMN的語言表達的流程圖要素就要豐富得多，也能夠將流程信息表達得更完整和精準。BPMN的標準差不多有上百個圖例，但其實我們真正地去描述業務的時候通常用不到那么多的符號。就像漢字一樣的，我們的新華字典有66萬個字，但是我們平常能用到的只有3500個字。有3000個字我們就能寫99%的文章；有3500個字我們幾乎可以寫100%的文章了。

用什么樣的語言來表達流程取決于你要交流的對象以及用途。當我們與管理人員或者業務人員描述業務活動的時候，用相對簡單的常用符號就完全可以應付自如，我們也只能用這樣的方式，因為復雜的符號語言對于非流程專業人員來說的確是一場災難。但如果我們需要將流程最后轉化為IT的時候，你就會發現問題不是那么簡單了，恐怕你就需要更多的符號才能夠把那些相對復雜的邏輯表達清楚和準確，才能讓開發人員真正明白其中的關系。

描述流程對業務人員來說叫流程梳理，對專業人員或者技術人員來說叫流程建模。建模就需要能夠完整、清楚、準確地描述流程，將前者的工作成果轉換成后者需要一定的專業性。所以其實我們可以將流程梳理和流程建模看作是兩種工作，前者是業務人員的工作，后者是專業人員的工作。我通常也會建議那些應用BPMN語言的團隊，在做流程建模的時候不要一次性地完成，而是分成梳理和建模兩個步驟來做，這樣就不容易產生與業務人員溝通的障礙。