《IBM BPM實戰指南》讀書筆記

理論

---

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卓越中心的三個關鍵領域

• 戰略
• 交付
• 共享平臺