簡介
在這裡，我們將審視一下市場中的供應商和它們的產品。然後討論一下BPMS的主要功能應該有哪些，最後我們將回到BPMS技術和業務流程分析與建模（BPA/M）、商務智慧型（BI）、線上分析處理（OLAP）、企業績效管理（EPM）、業務活動監控（BAM）、業務規則引擎（BREs）、企業事件管理（EEM）、門戶、B2B流程、EAI、企業服務匯流排（ESBs）、Web Service、集成開發環境（IDE）的關係上來。
一、BPMS的供應商分類
我們可以將BPMS供應商分成幾類。雖然分類不一定很準確，但它能夠幫助我們理解不同的供應商對BPM的理解，它們的產品解決哪些BPMS需求。幾乎所有的BPMS供應商都是從技術角度看BPM，因此它們的產品只是間接地滿足BPM提出的業務管理原理。這種狀態是非常不幸的，因為只有採取一個清晰定義的面向流程的業務管理戰略才能成功地實施一個BPMS。不過有跡象顯示這種狀態正在改變。
目前主要有8類最重要的BPMS供應商：
· 純粹的BPMS供應商：純粹的BPMS供應商從一開始就設計了一個BPMS產品，並將它作為自己的旗艦產品。
· EAI供應商：EAI供應商很自然地從它們的軟體產品擴展到流程集成和流程自動化上面來。從訊息流到工作流管理服務、活動監控dashboards、績效管理，這在概念上並無多大飛躍。但是許多EAI供應商還在進一步向業務流程方向發展。
· 工作流供應商：與EAI供應商類似，工作流管理系統供應商能夠很容易地進入BPMS市場。一個工作流可以看作是一個結構特別好的業務流程。
· BPA和BPR供應商：現有的業務流程分析供應商靠BPR獲得了市場。這些供應商通常都有豐富的流程分析、定義、模擬經驗，有些供應商提供的產品具有流程執行、流程監控功能。
· EAS和IDE供應商：這些供應商發現BPM市場商機誘人。它們採取的第一步往往是向IDE添加圖形規則驅動或流程驅動的功能和集成功能（尤其是與Web Services和JavaBeans集成），以便快速開發基於流程的套用。要超越這種技術流程觀點，就要加入業務流程分析與設計和流程定義驅動的流程引擎。
· 企業套用供應商：企業套用套件（如ERP）內含有植入式的工作流管理和一些EAI功能，這些功能幫助客戶進行定製和集成。在目前的市場壓力下，它們開始增強這方面的功能，以便更好地適應BPMS需求。
· BRE、BAM、EEM供應商：這些供應商的產品在BPMS中扮演著重要角色。一些供應商正在擴展它們的產品，以提供更加完整的BPMS功能。一些供應商使用規則引擎在流程執行中實施規則驅動的方法。
· BI和OLAP供應商：這些供應商在業務、企業、EPM、dashboards方面的發展使得它們正成為BPMS供應商。它們開始意識到，BPM或工作流管理是滿足績效管理需求必需的功能。它們可能會在分析流之外提供對流程的支持。
二、BPMS的功能
要描述所有供應商實現BPMS的方法是不可能的。因此，我們將描述一個理想的BPMS應該具有的組件。從概念上講，這些組件可以分成6大類：
· 用戶界面
· BPA/M功能
· 運行時組件
· BAM和EPM
· 基礎設施
· 系統管理
用戶界面和系統管理的功能是十分清楚的，下面就不再做介紹了。
1、BPA/M功能
一個BPMS含有一組BPA/M工具。BPMS的使用者通過這些工具與系統進行互動。這些工具應該無縫集成，以供業務使用者方便地使用。這些工具產生的定義存儲在一個知識庫內，運行時系統可以直接或間接地訪問這些定義。
· 業務流程建模器：業務流程建模工具是BPMS主要的流程設計與流程變更界面。除了傳統的流程分析功能——捕捉、設計和修改業務流程及其屬性，還需要解決業務功能的操作性屬性和界面屬性。這些包括資源需求。雖然必定要採用一些流程設計方法論，但建模器在捕捉流程的過程中不應該受到限制，不管是在複雜性方面還是結構方面。它應該允許使用者定義和推行流程標準，為流程設計之間的轉換提供幫助。應該根據許可權、功能責任、所需的細節層次提供流程的各種視圖。如果要支持流程獨立與流程抽取的話，最後一個要求是很重要的。
· IT編制建模器/映射器：IT編制建模器用於定義和維護技術流，如訊息流與數據流、數據轉換、IT資源的事務性管理等。在一個理想的BPMS中，它支持業務流程定義與技術編制之間的映射。此外，業務功能也與服務類進行了映射。這種映射過程可以是顯式的也可以是隱式的。
· 業務事務建模器：對於業務來說，將業務事務與業務流程事件聯繫起來、定義事務性屬性的功能是重要的。業務事務建模組件能夠滿足審計、一致性、錯誤恢復的業務需求。
· 技術事務建模器/映射器：一個業務事務最終必須轉換為一個實施模型，這個實施模型將它映射為一組協調的流、事件、具有ACID（Atomicity、consistency、Isolation、Durability）屬性的技術事務。這個工具用於創建、維護定義和映射。
· 業務標準建模器：只有當業務流程和業務功能與業務標準或關鍵績效指標（KPIs）聯繫起來時，它們對業務經理來說才是有用的。因此，BPMS的一個關鍵功能就是要捕捉業務標準，將它們與粗指標（比如由流程引擎或特定的業務功能產生）聯繫起來。業務標準與粗指標之間的差異是關鍵的。比如業務人員對一個業務事務的完成時間感興趣，而平均排隊時間、平均活動服務時間、完成的最可能路徑等粗指標則過於技術、過於細節了。業務標準定義影響粗指標的制定。
· 技術指標建模器/映射器：一個業務標準或KPI最終要轉換成一組物理或技術指標，以及用於獲得這些指標的操作。這個工具用於制定所需的技術指標和由技術指標生成業務標準的方法。
· 業務流程模擬：離散的業務流程模擬對於業務流程的設計、最佳化、故障檢查是十分有價值的。它應該提示可選路徑的分布、調整基於活動的成本分析中的成本、調整控制流程路徑分支的數據值的分布。它還應該對潛在的瓶頸或不一致提供可視化的強調，應該根據使用者的標準識別出最佳的流程設計。它應該能夠用使用者提供的數據或歷史性數據進行模擬。使用者對可視化的模擬過程和模擬結果的要求也很高。
· 模擬引擎：模擬的有效性取決於對流程引擎的操作性特性的精確表示。模擬引擎與目標流程引擎的匹配度越高，模擬結果就越精確。
· Dashboards：這個工具用於監控流程實例和它們產生的標準數據。Dashboards大致可分為3類：BAM Dashboard、EPM Dashboard和流程監控器Dashboard。
· Dashboards設計器：可能要根據不同的使用者設計Dashboard。這個工具可以利用個性化技術和內容管理技術。
· 業務流程管理者：應該授權一些使用者啟動、停止、暫停、重定義或改變一個流程或業務功能實例。他們可能需要修改一條訊息或需要手工分配資源。這個功能顯示了BPMS的柔性。
· 業務分析器和報表生成器：業務人員的許多問題都要通過大量計算和分析才能解決。有時候，分析涉及到複雜的統計模型，用戶不需要理解這些模型，只要知道任何使用就可以了。用戶需要通過報表來瀏覽分析結果，最好是通過網路傳遞這些報表。這些工具在一個OLAP系統中是很普遍的，雖然BPMS的業務分析組件還要根據特定業務流程環境進行定製。如果能夠提供一個幫助理解特定業務流程的分析幫助庫也是非常好的。這種工具通常是BAM和EPM產品的組件。
2、運行時組件
運行時組件是BPMS的心臟。如果沒有運行時組件，BPMS就無法執行流程定義、無法管理流程的運行。運行時組件的技術架構、特性和功能在很大程度上決定了操作可用性、績效、效率和靈活性。
· 流程引擎：BPM流程引擎顯然是BPMS的中心組件。它的目標是實現業務流程、管理實時調用和終止業務功能。理想情況下，它不應該規定流程的形式或業務功能的性質。我們認為傳統的工作流引擎是BPM流程引擎的一個子集，因此流程引擎也應該能夠處理結構化的工作流。
· 分散式的BPM協調器：B2B、B2C、全球化、跨地區或跨部門的業務流程需要一個分散式的流程引擎。這意味著流程引擎要具有遠程流程調用、通信和協調功能。在某些情況下，流程引擎之間的對話是通過全局流程來協調的。對話中的每個參與者可能有各不相同的流程視圖、安全策略，它們可能將流程的外部部分視為一個子流程。協調器同時也是一種監督器和防火牆。
· 資源管理器：在一個理想的BPMS中，需要一個工具來實現業務功能定義與業務功能實現之間的獨立性。這種資源獨立性能夠讓業務使用者優先關注業務目標，改進業務流程定義的魯棒性，對可用資源進行有效的運行時管理。業務功能可能通過機制、電子手段、軟體或手工方法來實現。資源管理器必須為業務功能的執行分配合適的資源，這些資源應該能滿足業務功能的定義時需求和運行時需求。當業務功能被調用或激活時，所需的資源必須是可用的。業務功能完成後，這些資源又被送回資源庫。通常一個任務可以並行執行，在一組資源中進行負載平衡。如果所需的資源不可用，那么資源管理器應該自動分配一項替代資源。比如一項本該通過自動化方法執行的任務，可以改用手工方法來完成。
· 調度器：在BPMS中，業務功能的調度是一項重要的任務。如果資源的使用沒有限制，如果時間先後順序沒有限制，如果沒有外部約束，那么業務功能就能在前序任務完成之後立即執行。但事實上，這些條件很少能夠滿足。我們必須考慮授權、負載、能力問題，而且有些功能是由代理執行的，而我們對這些代理不擁有控制權。另外，業務流程和事務通常受到外部施加的時間約束，或者是由外部事件觸發的。這些因素使業務功能的調度變成一個複雜的技術問題。如果BPMS沒有這個組件，那么它就無法高效地運行，流程也無法及時執行。
· 規則引擎：一個規則引擎可以增強流程引擎和資源管理器的作用。規則能夠表示一個流程容許的轉換，從而也能夠表示活動之間的控制流決策。規則還能夠表示活動的初始條件和完成條件。業務功能的資源需求與資源能力的匹配可以通過帶有規則引擎的管理器完成。規則引擎可以幫助資源管理器最佳化資源分配。規則引擎在EAM、EPM中也十分重要，尤其是涉及到事件、標準、回響時。
· 硬體接口管理器：這個組件使得BPMS能夠支持活動通過計算機數控、機器人接口、流程控制接口等對機器進行控制。這能夠實現對起重機、運河水閘、製造設備、閥門等的操作。
· 界面管理器：如果流程引擎不能與業務功能通信，那么BPMS就沒有什麼價值。它必須用一種協調的方式實現控制流與數據流之間的通信。如果BPMS是與一套集成組件整合在一起的，那么界面管理器就應該負責整合的操作方面。界面管理器應該處理與適配器、技術編制引擎的通信。
· 工作單管理器：與人力資源的互動需要一些任務交付方法。通常，面向人的工作流管理需要用戶登錄系統，然後從表單中選擇任務。這些表單通常是有優先次序的。現在，任務選擇可能會調用一個自動生成的小程式或表單，或者是企業套用中的一個互動功能。工作單管理器應該支持涉及到外部資源的手工活動。
· 知識庫：BPMS需要一個成熟的DBMS或知識庫來存儲數據和元數據。知識庫要存儲的數據對象有很多，包括業務流程定義、完整性規則、實例日誌、訊息和數據流、業務標準定義和數據、業務分析和報告定義、保留數據、事務定義和數據、安全和政策定義、訪問日誌、模擬數據、錯誤事件和解決方法等。
如果沒有正確地集成這些技術性的運行時組件，那么使用起來將十分不便。但如果能夠用一個通用的架構和編程接口將它們整合起來的話，那么它們就能夠形成一個連貫的、協調的單元，增強企業的完整性。
3、業務活動監控與企業績效管理
對於流程管理，監控事件、分析測評數據、探測趨勢、計算KPIs的能力是很關鍵的。如果沒有這些能力，就不能智慧型化地最佳化業務流程或是回響戰略性事件創建有效的新業務流程。語義層、分析引擎、規則引擎是BAM（側重於對實時事件的檢測和回響）和EPM（側重於業務績效相關趨勢的探測、回響、預測）共有的。
· 語義層：這一層處理業務使用者要求的視圖與技術性描述之間的映射。這是一個概念層，它允許業務使用者從業務標準、業務對象、平衡記分卡等角度出發監控業務流程。
· BI/分析引擎：在根據底層或技術性標準計算業務標準和KPIs時，通常必須進行複雜的、規則驅動的分析。
· 門戶管理和個性化：每個業務使用者都可能要求個性化地展示業務測評數據。如果將dashboards配置為門戶，就可以通過門戶管理來實現這一點。
· 事件管理：BAM要求監測業務事件和技術事件，要求與規則引擎和分析引擎進行互動以對事件進行分類，確定合適回響，最終執行回響。回響的執行可能涉及到流程的初始化、事件的發起、警告的觸發等。
· 企業信息集成：EPM和BAM要求訪問各種各樣的數據。從概念上講，這個功能屬於一個企業信息集成產品，但大部分BPMS產品都會提供對數據源的集成的訪問。
· 內容管理：大部分業務數據是植入文檔中的。BAM的內容管理功能使得它能夠監測到更度的數據事件。
4、基礎設施
下面的技術接口可以是簡單的也可以是複雜的，但BPMS中必須具有這些組件。
· 系統管理器：BPMS需要IT支持組件來負責安裝、配置、系統管理。系統管理器應該具有企業級軟體系統管理器擁有的一般功能。一個系統管理員的工作是非常複雜的，因此系統管理器的可用性和可靠性是十分重要的。它的目標是要消除手工的管理任務。
· 審計管理器：大多數企業要求對業務流程進行審計。審計管理器負責跟蹤流程做了什麼、做出什麼決策、什麼時候、由誰、用了哪些資源。審計條件一旦定義好以後，就應該嚴格執行。審計點應該與事務邊界緊密地結合在一起。審計管理器必須支持跟蹤查詢和報表生成。
· 錯誤管理器：雖然許多錯誤是可以預測的，可以建立業務流程來對它們做出回響，但總是有一些錯誤是無法預見的。因此必須通過一種一致的、可審計的方法來管理錯誤，即使是要用手工的方法來處理錯誤。錯誤管理器應該定義錯誤類別和相關的回響。
· 安全和政策管理器：正如前面提到的，並不是所有代理都能夠獲得授權執行任何一項任務或活動、在任何時候使用任何資源。BPMS不能違反業務政策，它必須保證安全性。它可能必須支持加密、數字簽名、公鑰基礎設施（PKI）、單點登錄等。BPMS必須具備一個涉及到訪問、使用、管理的安全模式，因為業務流程可能是最寶貴的智慧財產權。
· 集成基礎設施：從一種最底層的角度看，集成基礎設施由一組直接連線的適配器組成，提供BPMS與實施業務功能的方法之間的點到點的集成。最低限度上，BPMS需要為手工流程提供一種與人通信的方法。從最高層的角度看，集成基礎設施可能是一個完整的業務集成組件。顯然，BPMS在一個完全集成的層面上才能夠運行好。這個基礎設施可能是一個架構在ESB上的傳統的EAI、Web Services。
· IDE：隨著BPMS的成熟，使用者肯定會想開發出能夠充分利用BPMS功能的軟體。要做到這一點，就需要一套開發工具。最簡單的一個IDE應該能夠開發新的適配器和Web Services。使用者很需要能夠提供流程驅動的設計與開發的IDE，以建立事件驅動的、基於規則的套用或套用組件。在使用這些IDE工具之前，使用者需要學習集成的流程對象方法論。有時候套用伺服器和套用平台產品會提供流程驅動的IDE。
三. 發展趨勢與預測
早期的BPMS產品只具有簡單的類似於工作流的功能，幾年前發展成為對BPA/M和BAM有最低限度支持的產品，現在它能夠支持更加複雜的含有手工和自動化活動的流程。它對BPA/M的支持已經大大改進了，對BAM和EPM的支持也在改進中。
在接下來的4～5中，BPMS還是有很多發展可以期待的。下面的一些發展預測尤其重要：
· 業務流程的範圍更加廣泛，而且無需將它們轉換成高度結構化的等價物
· 設計和監控中業務視圖和技術視圖的分離
· 意外處理的集成解決方法
· 改進聯合與分布能力，更好的支持企業級套用和B2B套用
· 協同的業務流程
· 相互連線的業務流程
· 有力的業務事務支持
· 智慧型的資源管理器，資源獨立性更好
· 經驗證的標準化的設計與開發方法論
· 具體的實施方法論
· 集成的BAM/EPM，經過閉環最佳化
· 更高水平的績效、可靠性和可用性
· 標準的但更易於定製的業務流程定義（模板）庫
BPM及其相關技術是非常有前途的，這裡面有許多潛在的業務利益。但它的實施只有經過仔細研究和量化控制才能取得成功。
