理論

BPM不是一個IT術語，更不是因技術的發展而起源的，相反，BPM自始至終都是管理學的術語和概念。它關注的一直都是效率、成本、利潤、質量等核心問題。
BPM是一門學科和一種方法論，只是現代的企業管理已經越來越離不開IT技術手段，而BPM軟件產品是一種構造工具，一種令人異常興奮的工具，可以提供更快、更好、更便宜的解決方案。它將IT會話轉變成業務語言，以解決IT長期存在的問題——業務與IT之間的溝通障礙，幫助企業改進效率，使得流程可視化、敏捷化，并幫助企業進行業務變革。

BPM相關標準

• BPEL（Business Process Execution Language）：以SOA為基礎，針對SOA進行編排，其本身也是一個SOA，可以被更高層的業務流程當成活動編排進業務流程里。
  • 優點： 基于SOA，所以具備集成強大的跨部門、跨平臺的異構系統的能力。
  • 缺點： 過于接近編程語言而非業務語言，并且缺少面向人工任務的定義。
• XPDL（XML Process Definition Language）：這是一個與開發者相關但與實現無關的流程過程描述規范和交換接口。
  • 優點：在業務流程完整性方面，比BPEL好。
  • 缺點：主要面向IT人員，缺乏對SOA的支持，集成能力比較差
• BPMN（Business Process Modeling Notation）：定義了一個業務流程圖，該業務流程圖基于一個流程圖，而流程圖被設計用于創建業務流程操作的圖形化模型。它的主要目標是提供一些被所有業務用戶容易理解的符號，從創建流程輪廓的業務分析到這些流程的實現，直到最終用戶的管理監控。
  • 優點： 最接近業務語言。
  • 缺點： 不支持SOA，集成能力差。

BPMN適用于業務層面，BPEL適用于IT層面，XPDL則介于兩者之間。目前最佳的解決方案是BPMN + BPEL。
IBM BPM 在7.5 中集成了面向業務人員的WebSphere Lombardi 和面向IT人員的WebSphere Process Server，包括了基于BPMN的流程設計器Process Designer和基于BPEL的Integration Designer。

BPM的生命周期

• 廣義生命周期

廣義的生命周期是從業務管理的角度進行說明，它幾乎覆蓋了企業戰略管理、戰略流程定義、業務構建、業務流程定義、業務服務定義和編排、業務執行和監控、業務流程優化改進以及戰略調整等企業管理的方方面面。

• 狹義生命周期

狹義生命周期是從IT實現的角度進行說明，它指的是可執行業務流程在BPMS系統中從設計建模到部署執行、監控和改進的過程。

BPM的未來趨勢

• 敏捷化
• 智慧化
• 社區化
• 移動化
• 虛擬化

IBM BPM產品架構

BPM產品設計的核心問題： 它必須橫跨業務和IT兩個部分，能夠很好的支持業務用戶采用業務語言來建設業務流程，同時它又必須能夠支持IT人員使用IT語言來整合IT資產以實現業務流程。這要求BPM產品必須同時具備業務設計能力和IT設計能力，并且能夠將這兩種模型統一為一個完整的模型。

BPM可以集成這種系統，這要求BPM必須具備很強的擴展能力，能夠容納、擴展、整合各種企業應用，以BPM為核心形成的應用生態圈不僅僅是孤立的業務問題和流程問題。

IBM BPM產品由以下幾部分構成：

• Process Center
• Process Server
• Process Designer
• Integration Designer

IBM BPM 項目開發方法論

BPM主要是由業務驅動的，這決定了流程開發是”粗粒度“的，所謂”粗粒度“是指BPM通過業務人員可以理解的業務部周的概念來描述業務的主要活動，屏蔽了業務部門不關心的技術細節。
流程開發是一個”粗粒度“的組合式開發過程，也是一個不斷迭代、不斷改進的過程。

BPM”粗粒度“開發的基本原則

• 用標準的、圖形化的、可定制的流程產品開發工具開發流程和表單，盡量避免使用代碼。
• 把需要用代碼開發的部分盡量封裝成可重用的組件。
• 先搭建流程平臺，再做具體業務流程的開發。
• 把業務人員可以定制的業務規則外掛，成為通過業務人員定制就可以改變的業務組件。

BPM是一種管理理念，它不是要取代現有的系統，而是利用或者重用現有系統，達到管理企業各個層級的業務流程的目的。
從技術角度來看，人工工作流的實施有三個挑戰：1）流程建模和流程環節之間的狀態跳轉；2）人工任務的人員分配；3）環節內的表單和表單業務邏輯。

BPM項目實施的順序

• 人工工作流
• 協同流程
• 三級流程的監控流程
• 基于SOA的自動流程
• 二級流程以上的監控流程

流程平臺的內容和開發原則

什么是”流程平臺“？ 指搭建一個企業共享的功能模塊平臺，把流程開發中可以重用的模塊和服務放在共享平臺之上，讓一個具體流程的開發變得簡單。

人工工作流平臺的開發內容

• 定義并建立流程平臺和企業門戶系統。業務系統之間的邏輯關系。
• 定義并建立流程平臺對外提供的標準API接口。
• 建立流程平臺常用的功能模塊：流程的觸發、掛起、恢復、終止。
• 建立流程監控的基本機制和監控頁面
• 建立和服務總線的整合調用機制。
• 建立流程生命周期的管理。
• 滿足流程平臺的非功能指標
• 建劉流程部署的環境：開發、測試、生產。
• 建立流程平臺的運維規范。

人工工作流程的開發原則

• 流程的路由環節和環節內的表單邏輯松耦合。
• 流程路由和環節的執行人的任務分配規則松耦合。
• 流程和后臺服務松耦合。
• 流程數據和業務數據松耦合。

流程平臺的對外接口

• 創建并啟動流程實例
• 終止流程
• 刪除流程實例
• 休眠流程實例
• 激活流程實例
• 節點跳轉
• 認領任務
• 提交任務
• 獲取任務的參與者
• 查看任務項
• 轉派
• 建模工具參與者設置
• 強制辦結
• 流程文檔操作
• 性能數據

具體流程的開發步驟和開發原則

開發步驟

• 定義流程的業務數據結構
• 定義用到并畫流程圖
• 指定環節的屬性并指定環節的執行角色以及任務的分配規則
• 定義開發環節中涉及到的表單和表單背后的邏輯
• 給出流程監控的績效指標
• 和業務人員一起對流程進行”回放”，改進流程設計

什么是”環節“？ 環節可以是一個簡單的人工任務，也可以是一個已經在工具箱里面的子流程。常見的環節類型：1）人工環節；2） 人工會簽環節；3）業務自定義環節；4）自動環節；5） 控制環節；6）決策環節。
什么是”流程回放“？ 指和業務人員一起，用流程工具提供的流程回放功能對建立的業務流程進行場景回放，期間，討論流程人員開發的流程模板和業務人員的流程功能開發說明書是否一致，有沒有需要改進的地方，同時也要檢視流程末班描述的業務活動環節。
流程回放是保證流程健康性的一個必要步驟，是流程開發過程中必須定期執行的。

流程回放一般包括的內容：

• 流程開發的”粒度“是否為業務人員明白的業務內容，盡量屏蔽業務人員不懂的IT部分
• 流程的業務數據結構是否和業務需求一致
• 流程圖的各個環節之間的路由規則和跳轉規則
• 各個環節的執行角色以及任務分配規則
• 各個環節的表單展現和表單邏輯是否和業務需求一致
• 流程監控的績效指標是否和業務需求一致

流程梳理和設計

什么是流程梳理？流程梳理是指圍繞企業的內部要素和外部要素，對整個企業的業務特點和管理現狀進行深入細致的分析和提煉，識別流程現狀和管理的關鍵點，搭建企業的流程框架，對流程進行分類分級，幫助企業更好的進行管理轉型和業務運營，并幫助管理人員優化組織架構及平衡資源配置等。
流程梳理的過程：首先通過收集、分析企業現有的流程文檔和業務事件列表，了解企業的整體情況并初步梳理出流程的大體框架，然后通過業務訪談、Workshop討論、問卷調查等方式，明確流程清單并對流程進行逐級分解和定義描述，最后根據流程梳理的結果，編寫流程需求文檔，清晰的定義和描述流程，并與用戶做最終確認。
流程體系框架的構建是一個企業進行流程管理的起點，一個完整的業務體系包括組織、流程和系統，構建的原則是從宏觀的業務級別到微觀的活動級別，從易到難，從簡到繁，完整的覆蓋企業從業務到運營的全部內容和細節。

流程體系框架設計的步驟

• 明確企業的業務框架，確定企業有競爭優勢的價值鏈
• 針對每個流程的模塊領域，明確核心業務和支持業務，并設計有效的業務管理模型
• 針對各業務模塊下的管理模型，列出整體的流程清單，并考慮各流程間的關系，從而形成該業務模塊的流程體系框架

流程分級

• 價值鏈
• 流程鏈
• 流程
• 任務
• 步驟

流程梳理完成之后，需要明確定義流程，將流程的輸入、輸出、活動步驟以及相關人員等描述出來，回答為什么做、做什么、怎么做、誰來做等問題。
在這個階段，我們需要輸出流程圖和流程文檔。

常使用的流程圖定義工具：

• Visio
• SmartDraw
• UML
• BPMN

流程文檔需要包括的內容：

• 流程概述
• 流程參與崗位
• 輸入輸出
• 流程活動描述
• 關鍵控制點
• 流程KPI
• 參考資料
• 版本管理

流程梳理的一個重要目的，是要把分析出來的流程進行梳理、分類、合并，歸并出企業通用的流程末班，以供后面業務人員在開發流程中使用。

BPM流程設計

業務流程設計使之根據市場需求與企業要求調整企業流程，包括設計、分析和優化流程。其中，設計階段的目的是根據分析結果并結合企業目標制定目標流程，進而在IT系統中實施，有助于今后為企業創造有價值的目標流程。

如何轉換業務需求

• 用例模型
  • 服務用例
  • 業務用例
• 記錄業務場景和數據要求

什么是BPMN？全稱是“業務流程建模標記/業務流程建模標注（Business Process Model and Notation）”， 是由對象管理組織（OMG）管理的一種公共的建模標準，它提供了流程交互、異常處理和語義補充等諸多功能，是被業界主流廠商廣泛接受的建模標準。
BPMN主要由4部分組成：1）流對象；2）連接對象；3）泳道；4）器物。

在構造表單時，IBM BPM支持兩種方式：

• 基于Coach的表單
• 基于外部頁面的表單，這是通過URL的方式來實現的，因此極大豐富了該部分的擴展性。

在業務流程中經常會出現一些自動環節，或者在人工服務中調用某些特殊的接口，甚至是某些環節需要調用外部系統的某些內容，這就要求BPM系統提供豐富的接口支持，BPM支持的方式：

• 基于WebService的接入
• 基于Java的接入

KPI定義

KPI（關鍵績效指標，Key Performance Indicator）是通過對企業組織內部的某一流程的輸入端、輸出端的關鍵參數進行設置、取樣、計算、分析，來衡量流程績效的一種目標式量化管理指標。

IBM BPM允許用戶執行如下KPI相關操作：

• 查看KPI屬性并修改所有者。
• 打開“警報管理器”，并未KPI創建警報。
• 打開KPI的歷史記錄和預測配置選項。
• 將KPI窗口小部件作為一個任務發送給其他儀表板用戶。

流程門戶

IBM BPM支持的流程門戶類型：

• 默認流程門戶
• 定制化的流程門戶
• 外部實現的流程門戶

流程梳理和建模的基本原則

• 要從工作的目標而非工作的過程出發，定制崗位職責。
• 剔除對內部客戶和外部客戶不增值的活動。
• 使決策點盡可能的靠近需要進行決策的地點。
• 盡可能的使同一個人完成一項完整的工作。
• 部門之間的溝通、決策和問題的解決應在直接參與作業的層面進行。

流程設計和開發的基本原則

• 基本功能組件化，可變功能腳本化。
• 流程模板分類和可定制化。
• 考慮流程體系的可遷移性。

BPM開發基礎及進階

這一部分占的篇幅最多，但看的最快，因為日常工作中一直在用IBM BPM為客戶提供解決方案，不過這一部分是整本書中最接地氣的內容，可操作性很強。其中有一些內容在工作中沒有怎么用過，特此記錄。

• 定義coach時，可以直接將變量拖拽到頁面中，會自動根據變量中各屬性，自動生成對應的控件。
• IBM BPM應用的兩種部署方式：1） 在線部署（twx）；2） 離線部署（offline package)。
• 關于服務器端腳本，IBM BPM使用了Mozilla的JavaScript引擎Rhino來解釋之星腳本，Rhino引擎是一個純粹的java實現，它的工作室橋接兩個不同的語言，在它的實現里既可以通過JavaScript直接調用Java方法，也可以在Java方法里面調用JavaScript。
• IBM的用戶組分為：1）系統管理層面的、物理的組——安全組；2）應用層面的、邏輯的組——參與者組，或者Team。
• 關于Team，分為：1）靜態的團隊；2）動態的團隊。動態團隊使用的服務包括：1）Team Retrieval Service; 2）Team Filter Service。
• 調用Ajax服務的例子很不錯，之前一直在使用REST的方式調用Ajax服務，也可以在腳本中直接調用。

常用的Coach使用模式

• 數據同步模式，coach中不同的部分綁定相同的變量。
• 異步數據更新模式，使用Ajax服務。
• 頁面刷新模式，刷新整個頁面，在Human Service內部實現。
• 頁面模板模式，相當于母頁。
• 重復試圖模式
• 基于角色的動態顯示，在為每個控件設置visibility屬性，在腳本中為屬性進行賦值。
• 標簽頁面模式，使用選項卡控件。
• 數據列表模式，使用表控件。
• 數據列表監聽模式，1）在load事件中處理；2）使用Change Data Boundary Event。
• 選項數據更新模式，靈活使用綁定變量。

理解和運用UCA

UCA的全稱是“隱蔽（事件）代理”，Undercover Agent， 它由事件啟動，事件通常是由消息或者特定時間觸發，從而啟動UCA，當UCA啟動時，它將調用與之綁定的特定BPM服務來回應該觸發事件。因此，當希望在某類消息事件發生時自動觸發某個BPM服務或流程，或者當希望某個BPM服務或流程作為某類定時發生的消息事件自動觸發的結果而被調用，應該使用UCA。

平時項目中使用UCA的地方很少，有一些場景：在每個月的指定時間啟動特定的BPD，一般都使用Unix的cron腳本來實現，通過url的方式來啟動BPD。

流程門戶定制

流程門戶允許用戶對以下場景進行定制化：

• 修改登錄頁面
• 定制導航欄
• 修改主題元素

目前還沒有遇到定制門戶的要求，因為在生產環境中，一個BPM服務器為多個客戶同時提供服務，如果定制流程門戶，就會影響所有用戶。

使用REST API管理業務流程

這部分很熟悉了，在項目中大量使用了REST。

使用REST API時的注意事項：

• URL長度的限制，可以使用ＰＯＳＴ方式建立請求，同時設置Content-Type HTTP頭信息為application/x-www-form-urlencoded。
• 創建HTTP方法重寫通道
• 切換數據格式

IBM BPM與Web Service集成

這部分平時很少用到，以后有機會再詳細學習。

一些可重用資產

• 會簽、動態加減簽
• 代理
• 自定義實現樹結構

我理解應該會隨書提供一些可重用的toolkit，但目前還沒有發現。

BPM開發中的注意事項

流程應用程序和工具箱

• 流程應用程序和工具箱的依賴關系是靜態綁定的。
• 版本控制針對的是流程應用，而不是流程應用中的單個文件。
• 當針對一個流程應用程序產生一個快照時，在該快照中流程應用程序所包含的的工具箱版本也同時被確定了。

業務流程定義

• 在一個業務流程定義中定義適量的業務活動。
  • 一般認為，主流程的業務活動不超過7個
• 避免定義書序的系統通道活動。
  • 在業務流程定義引擎執行過程中，過多的順序執行的活動，特別是系統通道活動，會大大降低整個引擎處理事務的能力，并增大數據庫端的負載。
• 避免定義多實例的系統通道活動
  • 因為這樣會產生大量的令牌，而同一時間，只能移動一個令牌。
• 避免定義無限循環的業務流程圖
  • 使用業務流程定義進行輪詢操作，會消耗一定的服務器處理器資源。
  • 盡可能考慮使用別的通訊機制替代輪詢，例如Java消息服務。
  • 如果輪詢是必要的，則應該使用秘密代理程序，即UCA。
• 避免有深層嵌套的流程或者活動
• 了解計時器（Timer）和服務級別協議（Service Level Agreement， SLA）的區別
  • 服務級別協議的裸機只會在關聯的活動的開始或者完成時才會被觸發。
  • 我們可以通過計時器事件來發送通知，而是用服務級別協議跟蹤和監控歷史趨勢。

服務開發環節注意事項

• 人工任務節點定義，盡量將同一個人操作的頁面封裝在同一個human service中。
• 避免保存上下文
• 變量
  • 變量的數量和大小
    • 當某個變量不再被需要時，將其置空。
    • 盡量減少在每個活動節點間傳輸的變量的數量及內容。
  • 區分流程數據和業務數據
    • 不要把整個業務應用數據都定義為流程變量，業務應用數據應該單獨維護
• 界面設計和腳本
  • 避免在一個頁面展示過多內容
  • 避免使用大段JavaScript
• 跟蹤，對于不需要手機和跟蹤KPI的業務流程，可以金庸自動跟蹤功能。
• 異常處理
  • 避免全局異常處理
  • 業務異常和運行時異常
    • 業務異常是指已經在業務系統中定義好、有業務含義的異常。
    • 運行時異常是指IT層面的異常。
• 命名規范
  • 流程應用程序和工具箱明明規則
    • 名稱控制在64個字符以內
    • 除了約定俗成的名稱，盡量避免使用縮寫
    • 在描述欄中填寫詳細的描述信息
    • 名稱中不帶版本信息
  • 快照命名規則
    • 提供快照日期戳
    • 描述該版本的變化、增強內容

運行時性能調優

• 事件管理器調優
  • 事件管理器的主要功能是為了保證代碼可以按照計劃執行
  • 任何事件管理器計劃好的任務實際上是在一個流程服務器上具體執行的。
  • 使用事件管理器的場景： 1）UCA調用；2）處理業務流程定義（ＢＰＤ）的通知；3）執行業務流程定義的系統通道活動；4）執行業務流程定義的定時器事件。
• 同步隊列
• 異步隊列

業務運維注意事項

• 通過流程管理控制臺進行監控
• 通過流程監視器搜索流程實例
• 通過流程監視器對失敗的流程實例中的錯誤和故障進行故障診斷
• 在流程服務器上部署新版本快照時參與者組的映射關系
• 遷移現行數據，使用策略文件
• 定期清除
  • 定期清除流程實例
  • 數據備份歸檔
• 管理員干預
  • IBMBPM中包含事件管理器組件，它負責在業務流程定義引擎和服務引擎中移動令牌，事件管理器持續不斷的處理一個循環事件，知道事件管理器被停止或者循環終止。

IT運維注意事項

• 如何保證系統的健壯性，保持對系統的跟蹤和記錄
• 環境備份
  • BPM的概要文件目錄
  • 數據庫
  • IBM Installation Manager
• 更新流程門戶任務索引，使用taskIndexFullReIndex腳本

BPM的高可用性

從系統運行的角度來看，高可用性分為兩類：1）進程高可用性；2）數據高可用性。
高可用的建設目標是通過消除單點故障來提供持續服務，主要手段是通過冗余組件和集群技術來消除單點故障。
系統的高可用性不是由最可靠的組件的高可用新計算出來的，相反，整個系統的高可用性取決于系統中高可用性最低的組件。也就是木桶理論。

BPM高可用性架構

• 前臺有兩臺Web服務器，可以是Active-Active模式或者Active-Standby模式
• BPM層的高可用性是通過WebSphere內嵌的集群技術來實現集群成員的高可用性
• LDAP服務器層的高可用性是通過配置一個或者多個Standby的LDAP服務器，然后再WebSphere中定義這些服務器
• 數據庫服務器的高可用性可以通過集群技術或者數據庫自身的HA技術來解決
• 單個存儲本身就已經做了大量的工作，例如使用RAID來保護數據

BPM的管控方法論

企業采用和試試業務流程管理是一個長期的、持續的、不斷提升、不斷成熟的過程。

企業應用BPM的能力可以分為5個級別：

• 初始級，探索和嘗試
• 掌控級，最佳實踐的應用和積累
• 標準化級，從BPM項目發展到BPM項目組
• 流程優化級，BPM在企業層面全面實施
• 業務轉型級，基于業務流程的企業文化

企業采用業務流程管理是為了解決自己的管理問題和業務問題，提升自己的業務價值和管理效率，最終提高自己的市場競爭力并實現自己的戰略目標。
企業在決定采用業務流程管理之前既要有近期目標，也要有遠期規劃，在初期應該采取“想大做小，快速擴展”的原則

企業采用BPM時遇到的問題

• 業務流程實施和管理能力的缺失
  • 卻反對業務流程的正確認識
  • 缺乏對業務流程的敏銳洞察
  • 缺乏采用業務流程的長期規劃
  • 缺乏對業務流程的快速交付能力
  • 缺乏對業務流程實施的資源與技術
• 企業層面業務流程平臺的缺失
  • 企業層面的業務流程存儲庫
  • 與企業其他系統的集成能力
  • 企業級的標準化
  • 企業級的安全機制
  • 企業級的監控機制
  • 企業業務的不斷擴展
• 缺少企業組織架構的支持
  • 基于戰略層面的指導和監控
  • 業務流程全生命周期的管控
  • 最佳實踐的管理和維護
  • 企業級業務模型的描述
  • 業務層面和IT層面的協調
  • 共享平臺的支撐和管理

成功實施第一個業務流程項目

第一個業務流程項目應該首先考慮選擇在本企業里面運行已經比較成熟、達成共識、易于梳理、復雜度小的流程來實施。

應該注意避免的誤區：

• 錯誤的項目范圍導致需求不清
• 業務流程不會產生有效的投資回報率（ROI）
• 業務需求缺乏有效的溝通和表達
• 需求頻繁變更，影響項目的及時交付
• 業務團隊和IT團隊是相互孤立的，需要一起進行playback
• 部門間缺乏有效協調，導致不同部門采用不一致的實施方略

BPM流程管控機制

業務流程管控的基本概念是企業的戰略目標能夠在業務流程層面得以成功實現的企業層面框架，同時，該框架還確保企業的業務價值能夠通過業務流程得以體現。

BPM管控框架具備的要素

• 定義BPM管控以及與其他管控層面交互的總體原則
• 建立各項活動的標準、規范、指導原則或基本框架
• 定義所有相關角色及其責任。全力和溝通渠道
• 定義管理業務流程生命周期的組織架構
• 定義共享和重用業務流程相關信息的基本程序
• 定義BPM項目的資助模型
• 定義評估和測量業務流程業務價值的準則
• 定義業務層面和IT層面合作準則和溝通渠道

BPM管控機制的操作模型

• BPM執行指導委員會，負責調整方向和資金
• BPM項目評審委員會，負責計劃、排序和宣講
• BPM設計團隊，負責構建和復用
• BPM解決方案團隊，負責交付流程解決方案
• BPMSOA和平臺團隊，負責構建和管理基礎架構

BPM卓越中心

什么是“BPM卓越中心”？這是一個實體組織，具體負責企業BPM相關的戰略規劃、行為規則、實施指導、項目監控、IT規劃等事項，保證BPM管控機制在全企業的有效施行和不斷改進。

BPM卓越中心的三個關鍵領域

• 戰略
• 交付
• 共享平臺