我舉個例子說明吧，我們經常透過火車運輸貨物到各個地方，火車運輸的時候需要有“鐵軌”，這裡的“鐵軌”就相當於我們資訊化說的工作流，工作流就是指“業務過程的部分或整體在計算機應用環境下的自動化”，是對工作流程及其各操作步驟之間業務規則的抽象、概括描述。走不同的軌道可能會走向不同的目的地，甚至相同的目的地之間可以有不同的軌道，鐵軌可以很長也可以很短，鐵軌還不一定是一條直線，總之這個過程中會有很多的靈活性。說到工作流的應用。這裡就很廣泛了，比照火車運輸的例子，我們傳統oa系統上的流程流轉主要就是依賴工作流進行的，但我們也要注意到，但要想實現貨物實現不同站點的運輸轉移，出了軌道外我們還要考慮很多其他的因素，比如火車本身，如何實現更多貨物的裝填，比如不同的站點如何進行貨物的裝卸和處理，又比如不同火車之間如何進行互動或者區分實現整個運輸網路的淨化和高效執行，這時候只看軌道就搞不定了，所以這也是現在工作流紛紛為BPM讓路的原因所在，根據BPM廠商天翎的定義，BPM是Business Process Management的簡稱，譯為業務流程管理，它是一種以規範化的構造端到端的卓越業務流程為中心，以持續的提高組織業務績效為目的的系統化工具和方法論，面對經濟全球化的競爭壓力和各種新技術創新場景下不斷變化的使用者需求，這種透過診斷、梳理、E化、監控和持續最佳化業務流程的實踐，可以有效提升企業組織力並助力企業贏得市場競爭。

工作流引擎是指workflow(工作流)作為應用系統的一部分，併為之提供對各種應用系統有決定作用的根據角色、分工、和條件的不同決定資訊傳遞路由、內容等級等核心解決方案

那在簡單的從字面分開來講，我們可以這樣拆分著理解，工作流理解為工作流管理系統，那一個工作流管理系統可以包含多個引擎，而且工作流管理系統最核心部分是工作引擎，引擎是驅動流程流動的主要部件，他喚醒流程終止正在執行的流程，與其他引擎之間通訊等等工作

工作流的應用這裡就很廣泛，很多的oa系統上的流程流轉主要就是依賴工作流進行的，但是僅僅靠工作流，比較單一實現複雜的資訊互動比較難，所以為此就造就了現在很火的BPM，根據BPM廠商天翎的定義，BPM是Business Process Management的簡稱，譯為業務流程管理，它是一種以規範化的構造端到端的卓越業務流程為中心，以持續的提高組織業務績效為目的的系統化工具和方法論，面對經濟全球化的競爭壓力和各種新技術創新場景下不斷變化的使用者需求，這種透過診斷、梳理、E化、監控和持續最佳化業務流程的實踐，可以有效提升企業組織力並助力企業贏得市場競爭。

工作流引擎是用來實現工作流的一種元件化工具，它是一整套解決方案，比如說一般工作流引擎包含這些功能：流程節點管理、流向管理等，是為了減小開發成本而推出的。因為在軟體開發過程中，如果是從零開始實現工作流，那開發成本很大。

上面講到，工作流本質上是實現工作流的一種封裝，那我們就有必要了解一下工作流是啥了。工作流其實是協同辦公化的一部分，在日常辦公中，工作都是有一套流程的，且各個流程都有相應的業務規則。

舉個簡單的例子：比如說請假，在任何一家公司中員工想要請假基本上都是有一個請假流程，而不是說你想來就來想不來就不來。你的請假先經過你的組長/主管審批 -》部門經理審批 》行政報備 》抄送財務等。

上面請假的例子就很好的說明了辦公流程化，每一步操作都會涉及一些人和一些事的處理，傳統的辦公流程都是紙質化流程，效率極其低下。

而在資訊化辦公場景下，我們接入了工作流後，流程發起者只需要在系統上填寫好表單提交後，流程就會按著預定的規則去執行，每一級審批者會自動接收到資料。工作流的好處就體現出來，比如說：

提升效率，避免了流程發起者到處跑現象；

流程及時性提高，紙質化流程審批者如果不在辦公則無法審批，影響審批進度；而工作流的電子化場景使得審批容易；

流程便於管理，用了工作流後流程的查詢、統計、列印等都很簡單。

工作流引擎並不會隨意更改執行的順序。更貼切一點來說工作流引擎是用來驅動工作按既定流程的執行，即根據工作流程定義中設定的規則、條件來判斷流程執行的方向。就像所舉的請假的例子一樣。一般對於業務邏輯較強的工作流相對來說會固定一些，反而對於公文審批這種，人為干預的因素比較多(這個可能是你認為流程引擎可以隨意改變的原因吧)，需要的流程引擎就要靈活一些。另外，像Activiti這種工作流引擎是面向BPM的，即業務流程管理，對國內這種公文審批適應性會差一些。再者現在的工作流引擎結合訊息服務的話可以進行跨系統執行，不再侷限一個簡單的請假審批這種小流程。

工作流引擎是一種軟體設計開發平臺，比如notes domino，能夠透過二次開發協助企業與政府解決辦公自動化，電子政務，電子商務，自動製造等自動管理方面的流程設計與流程再造應用

如果說工作流引擎，我最有發言權了，本人從事工作流引擎的開發已經有一段時間,我們一般一般說的工作流引擎一般是指的是activiti框架，比如說你現在畫一個流程圖，程式能自動的根據流程的走向，完成各個節點的工作

資料 -> 資訊 -> 知識 -> 智慧，我們認知客觀世界行動，正在沿著這樣的道路不斷前行。“工作流（程）”是跨越在“資訊 -> 知識”之間的一種問題解決方法。以往的人們，需要花費很長的時間，才能習得的某些業務處理流程知識（它們之所以複雜、難學，大部分原因是“問題或事件”出現的機率很低、或週期很長）。這樣的流程化工作，透過程式設計可以有效的加以解決。然而，固定程式碼實現的流程，帶來的問題是，當“業務流程”需要調整時，相關的程式碼需要做出必要的調整。將“流程”作為“程式碼”，把“業務流程”實現為在“流程”程式碼在“流程引擎”的執行過程。藉助“流程程式碼”編輯、定製”工具，將複雜、難懂的規則、邏輯隱藏起來，僅僅透過可直觀理解的場景決策選擇，使得不懂“業務規則”的“小白”也可以正確的處理重要的業務事物。

不過，遺憾的是現在絕大多數工作流引擎和預定義的“工作流”往往都是被人們“命名”為“流程”的工作條例吧，其中涉及的“知識”寥寥無幾。