WebSphere Business Modeler 認證考試 990 準備：1

商務程序管理

      每個業務都是獨特的，都需要自訂的管理原則。定義營運目標以及如何執行它們是非常關鍵的。業務管理的另一個重要方面是管理變更，因為企業的策略會隨時間而變化。有效商務程序管理需要受過專門訓練的實踐，包括：

• 流程建模
• 啟用工作流程
• 定義業務度量
• 監視效能結果

理想情況下，您希望儘可能使管理流程自動化。通用化語言以便能夠修改流程而不影響基礎 IT 實現，這也是非常可取的。商務程序管理是工作流程和應用程式整合之間的邏輯結合。它將流程流從 IT 層級轉移到更抽象的業務層級。

什麼是商務程序管理？

商務程序再工程集中於簡化和自動化流程，以更高效地實現營運目標。用於流程重定義的步驟是：

1. 對現有的或當前的流程建模和類比
2. 對提議的或將來的流程建模和類比
3. 產生流程比較度量報告，以證明再工程後的流程價值。

 

若要做出改進，則必須熟悉現有的或當前的流程步驟。首先，分析人員捕獲模型中的當前流程以及相關支援資料，以便能夠類比該流程並在以後與再工程後的流程進行比較。對當前的流程建模將允許業務分析人員確定並量化現有的流程痛點。

對當前的流程進行分析並作文檔記錄之後，業務分析人員可以通過自動化以使用者為中心的任務（例如將書面工作替換為商務應用程式和整合應用程式以防止冗餘資料條目）來開始重新定義子流程。

定義商務程序

簡單地對流程流建模與實際捕獲商務程序之間是有區別的。分析人員還必須瞭解所有關聯的業務模型，才能真正監視和管理整個商務程序。這包括添加資源值，可以根據確保業務滿足已定義目標的營運目標來對這些值進行計算和測量。

分析人員必須記錄流程的所有重要方面：

• 流程流是什嗎？
• 流程中使用的資源是什嗎？
• 流程所操作的業務項是什嗎？
• 涉及到什麼組織和位置？

當分析人員研究流程和收集資料時，他們將記錄下列內容：

• 活動的輸入和輸出
• 任務變化以及那些變化的出現時間
• 替代任務
• 完整的任務描述
• 與任務關聯的角色

WebSphere Business Modeler 允許對與業務相關的每個元素建模。這其中包括業務項（如文檔、工作產品或商品）、通知（如警報）和資源（如人員、裝置和材料）。此外，可以對業務中用來執行流程或任務的每一個項（如人員、裝置或材料）建模以便在流程圖中使用。還可以對角色建模（為資源添加更多特徵）和對時間表建模（對資源或角色的可用性建模）。

此外，可以建立業務中存在的每一個組織實體和位置的模型。組織實體的樣本包括企業、公司、部門和團隊。位置的樣本包括地理地區、辦公室、工廠和銷售地區。然後可以將它們與商務程序圖中的元素關聯起來，或使用它們來建立結構圖以對模型元素之間的組織關係建模。

總而言之，可靠的流程定義中涉及的多維業務模型包括：

• 流程模型——流程的圖形表示形式。
• 資源模型——確定與流程關聯的資源類型和執行個體。
• 資訊模型——定義流程中使用的資料。
• 組織模型——關聯資源的定義和結構。
• 分析模型——靜態分析中的重要流程值和動態分析中流程類比結果。
• 協作模型——支援在建模和部署時進行有關流程模型的協作。
• 業務度量模型——關鍵效能指標 (KPI) 和業務度量的定義。

IBM Global Services 為業務整合產品套件提供了全套課程。有關更多資訊，請參考 IGS 培訓網站。

對組織和相關屬性建模

除了捕獲需要做的工作、誰正在做該工作和該工作所針對的目標以外，還務必從組織和地理的角度瞭解誰負責每個任務。這可以通過對各個任務、資源、角色、組織單位和涉及的位置之間的關聯進行建模來實現。

存在四種類型的組織元素：

• 組織目錄
• 結構
• 組織定義
• 組織單位

組織目錄執行檔案夾功能，允許您對相關的組織、位置和結構集分組。每次建立一個項目，就會自動為您建立兩個組織目錄。第一個目錄名為 Organizations，可用於儲存您自己的元素。第二個目錄名為 Predefined organizations，其中包含預設組織定義，您可以使用這些定義來建立組織單位，而不必首先為它們建立定義。

結構允許您建立可重用的模板和定義一組可跨多個組織定義而使用的屬性。使用模板來建立的每個組織定義都繼承該模板的屬性。此外，對模板所做的任何更改都將由直接或間接引用被更改模板的所有其他組織定義模板、組織定義和組織單位所繼承。

組織定義用於定義特定的組織單位。每個組織單位都必須引用某個組織定義。在建立組織定義之後，可以使用它們來建立組織單位以及結構定義。

組織單位代表組織內的特定組織部門。每個組織單位都必須基於某個組織定義，後者定義了該單位的屬性。

除了組織元素外，Modeler 工具還支援位置元素。位置模型對組織感興趣的特定地點建模。與組織一樣，每個位置都基於某個位置定義，後者規定了用於定義該位置的屬性。通過為位置定義中定義的屬性提供值，可以建立唯一的位置執行個體。

對業務項和相關屬性建模

業務項表示諸如業務文檔、工作產品或商品等由業務操作所使用的對象。它們經曆更改並從一個流程步驟傳遞到下一個流程步驟，並且它們形成了基礎流程資料或資訊模型的基礎。

與組織一樣，資料目錄可用於對業務項目範本、定義和執行個體分組。類似地，業務項目範本提供了在可重用的結構中捕獲一組屬性的方法，然後該結構可由項定義所利用。然後通過為相關屬性提供特定的值，可以將業務項定義執行個體化為業務項。

對資源和相關屬性建模

每次建立一個項目，就會自動為您建立兩個資來源目錄。第一個目錄名為 Resources，可用於儲存您自己的元素。第二個目錄名為 Predefined resources，其中包含預設資源定義，您可以使用這些定義來建立資源執行個體，而不必首先為它們建立定義。

資源與業務不同。正如前一部分所述，業務項是工作所針對的實體。資源表示誰在做該工作或所需的先決條件，並包括人員、裝置或材料。存在兩種類型的資源：單獨和批量。單獨資源是需要特定執行個體情況下的資源，而批量資源是可以使用池中的隨機執行個體時所使用的資源。單獨資源的樣本包括人員和電腦，批量資源樣本包括電力和水。

批量資源可以表示用於執行項目或任務的材料。它們可以是非消耗性的（如員工、車輛或裝置）或消耗性的（如燃料或印表機紙）。消耗性資源在流程過程中減少甚至用盡。

可以將批量資源定義為非唯一地確定的資源，但是資源是否可確定可能取決於使用它們的方式。因此資源的建模取決於被建模的流程中的角度及流程的用途。

資源可能已指定了可用的時間段。若要指定可用性，您可以使用現有時間表或建立新時間表來指明可用時間段。如果不指定某種資源可用性，則假設該資源始終可用。還可以為資源添加成本和資格。資格是該資源所必須滿足的特定角色。

一經定義，即可將資源與流程流中的各個任務關聯起來。還可以使用資源定義模板以允許一次性建立模板和定義屬性。這對於具有共同屬性的資源非常有用，並且此類資源代表資源定義的值或執行個體。此外，與組織一樣，資來源目錄是可用於包含資源定義模板、資源定義和資源的容器。

角色和時間表為資源添加了額外的特徵。角色用於定義特定資源的一組功能。時間表用於對資源或角色的可用性或者適用特定成本的時間進行建模。

對流程流建模

流程是即時商務程序的表示形式。流程由各個步驟或活動、指示這些步驟和活動發生時間的條件以及流程的效能或執行所需的資源群組成。

流程和任務都表示業務中執行的活動。但是流程比任務更複雜，並且可表示為通過控制和資料流連結起來的活動序列。該序列作為一個整體稱為流程流。相反，任務是原子活動，無法劃分為更小的操作。

存在兩種類型的流程：全域和局部。全域流程顯示在 Project Tree 中，並且可以跨項目中的多個流程使用。局部流程（或子流程）僅顯示在其父流程的流程圖中。

流程可以包含下列局部元素：

• 流程
• 任務
• 存放庫
• 開始、停止和結束節點
• 串連
• 決策
• 分支
• 接合
• 迴圈
• 映射
• 合并
• 通知廣播器
• 通知接收器
• 觀察器
• 計時器
• 註解

在流程中使用決策可允許以許多不同的方式執行該流程，具體取決於每個決策的結果。每條可能的執行路徑稱為案例。

流程的定義包含以下部分：

• 流程圖，是流程流的可視化表示形式
• 規範，定義流程的輸入和輸出。還可以定義成本和期間以及負責該流程的組織單位。請注意，負責的組織單位與執行該流程中的任務所需的資源之間沒有任何隱含的關係。

全域流程必須從 Project Tree 開啟以便進行編輯。例如，可以將全域流程拖放到某個圖上，然後在它與圖中的其他流程或任務之間建立串連，但前提是該全域流程包含適當的輸入和輸出。否則，您必須開啟全域流程的規範並做出更改。

可以在圖中顯示所有流程的標籤，以便能夠一眼看到某些特徵。最多可以指定兩個標籤，一個在上面，另一個在下面，並且可以從下列內容中選擇：

• 描述
• 處理成本
• 啟動成本
• 收入
• 處理時間
• 組織單位
• 位置
• 分類器值

流程串連

串連指定流程中的活動的年代順序。每個任務、子流程、決策或其他元素沿某個串連將控制傳遞到下一個任務或元素。

如果您要建立的流程從接收輸入開始，則不需要使用在建立圖時預設添加的開始節點。相反，您要通過直接連接到圖的邊框來向流程指明輸入。類似地，您將串連到右手邊的邊框來向流程表明期望的流程輸出。可以在圖中利用停止節點來表明流程已完成特定的決策流。

最後，您需要將業務項與需要在流程流中的元素之間傳遞該業務項的每個串連關聯起來。

分類器

如果需要對任務和其他流程元素分類，以便最佳化流程和容易地識別具有特定特徵集的元素，您可以使用分類器。存在幾個預定義的分類器，您也可以定義自己的分類器和分類器值。在流程圖中，分類器允許您快速查看具有某些特徵的元素。例如，您可以查看現有流程中的哪些任務專門用於品質控制，或者快速確定沒有為流程增添實際業務價值的所有任務。分類器使您可以對具有某個共同特徵的元素分類，然後為該特徵分配某種顏色。

每次建立一個項目，就會自動為您建立兩個分類器目錄。第一個目錄名為 Classifiers，可用於儲存您自己的元素。第二個目錄名為 Predefined classifiers，其中包含預設分類器定義，您可以使用這些定義來建立分類器，而不必首先為它們建立定義。

布局

存在兩種可用的流程布局：泳道 (swimlane) 和自由格式。泳道布局使您可以按照特定屬性顯示流程活動，從而協助您可視化地識別具有某些特徵的活動。自由格式允許您將元素放在編輯器表面上的任何位置。

泳道布局允許您通過將活動移動到不同的泳道行來調整屬性。它還按照您指定的類別顯示圖中的元素。當在圖中建立許多元素以後，如果不分別選擇每個元素並檢查其屬性，要取消那些元素的特定屬性將變得非常困難。通過切換到泳道布局，您可以按照某些特徵（如資源定義、角色或位置）來快速顯示活動。

流程建模的提示和技巧

Modeler 協助系統提供了指向下列主題的連結，其中包含了可以使 WebSphere Business Modeler 的使用更快、更容易的想法和捷徑。

• 一般提示和技巧——包含使用 WebSphere Business Modeler 的一般技巧。
• 流程編輯器提示和技巧——包含使用流程編輯器的提示和技巧
• 活動流建模——描述通常使用的流模式和建議用於實現它們的元素。
• 全域和局部元素——為了建立逼真和精確的模型，您需要知道何時使用模型種特定的元素。
• Project Tree 提示和技巧——包含使用 Project Tree 的提示和技巧。
• Expression Builder 提示和技巧——包含使用 Expression Builder 的提示和技巧。
• 類比和資源提示和技巧——包含運行類比和分配資源的提示和技巧。
• 報告和查詢提示和技巧——包含使用報告和查詢的提示和技巧。
• 匯入和匯出提示和技巧——包含適用於匯入和匯出的技巧。
• 快速鍵和導航——如何使用鍵盤和按鍵組合來執行也可以通過滑鼠操作來完成的操作。
• 自訂 WebSphere Business Modeler——如何自訂 WebSphere Business Modeler 環境。

定義一組標準以便維持一致的流程模型是很好的做法。流程建模標準為團隊提供了公用語言。擁有公用語言可以提高項目效率和減少誤解的發生。

建議對要包括的元素名稱和詳細資訊層級進行標準化。最重要的是，要保持模型與業務上下文相關。盡量選擇業務操作中出現的名稱和模型關係。務必記住，模型代表業務分析人員的視圖，以便能夠根據營運目標對其進行測量。模型應該與 IT 實現無關。

流程和任務應該遵循“動賓”命名規範，如建立銷售訂單。任務名稱應該簡練。決策和選擇可以簡化流程圖，應將它們陳述為諸如貸款是否已獲批准？ 之類的問題。

最後，範圍界定對於商務程序模型的成功非常關鍵。應該對項目目的和目標作文檔記錄、確定相關涉眾並確保他們的參與，以及清楚地定義項目時間表和計劃以監視和跟蹤正常進度。

匯入和匯出

匯入模型構件

WebSphere Business Modeler 允許您從各種來源匯入資訊，以便於快速構建商務程序模型。

WebSphere Business Modeler 所使用的資訊可能已經在另一個應用程式、工具或 WebSphere Business Modeler 的另一個副本中或以另一種檔案格式存在。WebSphere Business Modeler 提供嚮導來協助您將該資訊匯入新項目或匯入現有項目中。該嚮導支援下列類型的匯入：

• WebSphere Business Modeler 項目
• WebSphere MQ Workflow
• WebSphere Business Integration Workbench V4.2.4
• 分隔文本
• XML 模式
• Microsoft Visio
• WebSphere Business Modeler XML

一旦完成匯入嚮導，它就開始匯入處理程序。匯入處理程序檢查所匯入的元素是否與現有元素具有相同的名稱。如果存在重複名稱，則匯入處理程序將對所匯入的元素重新命名。但是在進行 WebSphere Business Modeler 項目匯入時，您可以改寫現有元素。如果選擇不改寫，則匯入處理程序就不會匯入具有重複名稱的元素。

匯入處理程序還會對內容進行驗證。如果發現諸如非法字元等問題，該過程將修複問題以便能夠繼續匯入。當該過程完成匯入時，您可以查看它所遇到和修複的問題。在匯入完成以後，WebSphere Business Modeler 將對新內容進行驗證。

匯出模型構件

在對商務程序建模以後，WebSphere Business Modeler 允許您將資訊匯出到另一個應用程式，例如為了實現該商務程序。還可以匯出項目以便其他人能夠匯入它以進行查看和處理。

WebSphere Business Modeler 提供嚮導來協助您將該資訊匯入為另一個應用程式能夠讀取的格式。該嚮導支援下列類型的匯出：

• WebSphere Business Modeler 項目
• UML 業務建模概要
• WebSphere MQ Workflow
• WebSphere Business Integration Server Foundation V5.1
• 分隔文本
• WebSphere Business Modeler XML
• WebSphere Process Server

重要：WebSphere Business Modeler 中建立的模型不保證能在其他工具中正確工作。在轉換檔時，您應該知道以下事項：

• 如果計劃匯出 FDL、BPEL 或 SCA 構件，您應該首先確保是在適當的模式（分別為 WebSphere MQ Workflow、WebSphere Business Integration Server Foundation 或 WebSphere Process Server）下工作，並且您的模型沒有錯誤。這些模型強制了 WebSphere Business Modeler 中對模型的約束，以確保能將該模型匯入其他應用程式並且能正常工作。
• 基於模型中指定的內容，可能無法產生完整的流程定義。例如，如果模型中的決策分支沒有與它們關聯的形式運算式，則不會產生任何 BPEL 或 FDL 轉換條件。
• 匯出檔案時不會產生與部署相關的資訊。該資訊將會在您將檔案匯入 Application Developer Integration Edition、WebSphere Integration Developer 或 WebSphere MQ Workflow 時產生。

在協作環境中使用 Modeler 產品

WebSphere Business Modeler Publishing Server 支援在基於 Web 的協作團隊環境中對模型進行檢查和注釋的能力。模型發布涉及到將一致的模型發送到發行伺服器。為實現一致性，必須存在來自不同 WebSphere Business Modeler 執行個體的模型元素的整合。

發行伺服器為不擁有 WebSphere Business Modeler 來查看和注釋商務程序模型的人員提供了一種方法。它使用一組 Portlet 在 網頁瀏覽器中顯示模型。那些 Portlet 一般與 WebSphere Business Modeler 所使用的四個窗格對應。

發布項目的建議方法是將發布與建模分離。因此，發布項目應該涉及下列步驟：

• 建模，其中建模人員團隊聯合建立模型。
• 整合，其中某個個人在建模團隊提供的內容基礎上構建一致的模型。
• 發布，其中充當發布人員的人將一致的模型發送到發行伺服器。

為了支援協作業務建模，項目版本控制允許團隊成員從某個公用源工作，並隨著模型的演變而對模型變更進行跟蹤。Repository 視圖支援並發版本系統 (Concurrent Versions System, CVS) 或 Rational ClearCase。

瞭解變更管理的限制和約束

在做出任何變更時，可能會發生衝突，當團隊成員同時對項目的同一個版本做出變更時尤其是如此。具有傳入和傳出變更的任何元素都可能會導致衝突。發生衝突時，使用者可以顯式改寫變更。他們必須注意仔細檢查變更以確保模型的一致性。在公用存放庫的需要（以在團隊成員之間共用模型項目）與用於管理和控制變更的成本之間，您必須進行平衡。

請注意，使用共用存放庫並不保證一致的整合模型。該存放庫包含可能具有相互依賴性的不同版本的模型元素。不同的版本使得構建一致的模型非常困難。

使用匯入和匯出以共用項目

可以使用匯入和匯出來在團隊成員之間共用項目。這種共用使得多個人可以對模型的開發做出貢獻。在使用匯入和匯出來共用項目時，建議採用以下過程：

1. 建立將用作合併專案的項目。如果可能，則在此時建立所有目錄。
2. 匯出項目以供每個人進行處理。建議的匯出格式是“WebSphere Business Modeler 項目”。每個團隊成員都將該項目匯入他們各自的工作區。
3. 團隊成員處理該項目並添加他們的元素，同時遵守下列規則：
   • 為每個新元素或目錄提供唯一的名稱（以避免名稱衝突）。
   • 不要對從合併專案匯出的目錄或元素重新命名（以避免標識資訊衝突）。
4. 在每個團隊成員完成某個添加階段後，他們要匯出模型。然後其他團隊成員和合併專案的擁有者將匯入那些模型。
5. 在每個穩定階段，備份該合併專案。