業務分析 - 建模

---

---

業務模型可以定義為對業務或解決方案的表示，通常包括圖形元件以及支援文字和與其他元件的關係。例如，如果我們必須瞭解公司的業務模型，那麼我們希望研究以下領域，例如 -

• 公司的核心價值觀
• 它服務於什麼？
• 是什麼讓它與眾不同？
• 其關鍵資源
• 主要關係
• 其交付渠道

藉助建模技術，我們可以建立對企業使用的現有和擬議的組織結構、流程和資訊的完整描述。

業務模型是一個結構化模型，就像最終產品的藍圖一樣。它為規劃提供了結構和動力。它也為最終產品提供了基礎。

業務建模的目的

業務建模用於設計企業的當前和未來狀態。業務分析師和利益相關者使用此模型來確保他們對企業的當前“現狀”模型有準確的理解。

它用於驗證利益相關者是否對擬議的“解決方案的目標狀態”有共同的理解。

分析需求是業務建模過程的一部分，並且構成了核心重點領域。功能需求是在“當前狀態”期間收集的。這些需求由利益相關者提供，涉及描述所需功能的業務流程、資料和業務規則，這些功能將在未來狀態中設計。

執行差距分析

在定義業務需求後，必須確定當前狀態（例如，當前業務流程、業務職能、當前系統功能以及提供的服務/產品和系統必須響應的事件），以瞭解人員、流程和技術、結構和架構如何透過尋求 IT 員工和其他相關利益相關者（包括業務所有者）的投入來支援業務。

然後執行差距分析，以評估是否存在任何阻止實現業務需求的差距，方法是將確定的當前狀態與預期結果進行比較。

如果沒有差距（即，當前狀態足以滿足業務需求和預期結果），則可能沒有必要啟動 IT 專案。否則，應確定需要解決的問題/問題以彌合差距。

可以使用 SWOT（優勢、劣勢、機會和威脅）分析和文件分析等技術。

評估擬議系統

BA 應協助 IT 專案團隊評估擬議的 IT 系統，以確保它滿足業務需求並最大化交付給利益相關者的價值。BA 還應審查組織支援向擬議 IT 系統過渡的準備情況，以確保系統實施順利。

BA 應幫助 IT 專案團隊確定擬議的系統選項和高階系統設計是否可以滿足業務需求並提供足夠的業務價值來證明投資合理性。如果有多個系統選項，BA 應與 IT 員工合作，幫助確定每個選項的優缺點，並選擇提供最大業務價值的選項。

業務建模的指導原則

業務建模的主要作用主要是在專案的啟動階段和詳細闡述階段，並在構建和過渡階段逐漸減少。它主要與業務的分析方面以及應用程式或軟體解決方案的技術對映相關。

• 領域和使用者差異 - 開發業務模型通常會揭示利益相關者之間存在分歧或混淆的領域。業務分析師需要記錄以下現狀模型中的差異。

• 多個工作單元執行相同的功能 - 記錄現狀模型中的差異。這可能是不同的部門或地理區域。

• 多個使用者執行相同的工作 - 不同的利益相關者可能會以不同的方式執行類似的工作。差異可能是不同業務部門的不同技能和方法的結果，也可能是企業服務的不同外部利益相關者的不同需求的結果。記錄現狀模型中的差異。

• 解決方案機制 - 業務分析師應記錄ToBe 解決方案是否會適應當前業務模型中的不一致性，或者解決方案是否需要標準化。利益相關者需要確定採用哪種方法。ToBe 模型將反映他們的決定。

BA 在 ERP 系統建模中的角色示例

業務分析師應該定義一個標準的業務流程並將其設定為 ERP 系統中，這對高效實施至關重要。在實施之前，BA 還負責以易於理解的語言定義開發人員的語言，然後利用最佳實踐並根據系統功能對其進行對映。

對系統的一個要求是 GAAP 適配分析，它必須在以下之間取得平衡 -

• 對技術更改的需求，即為了與現有實踐保持一致而進行的增強。

• 有效的更改，這些更改與重新設計現有業務流程相關，以允許實施標準功能和應用流程模型。

功能業務分析師

領域專業知識通常透過長期從事“業務”活動而獲得。例如，

• 銀行業務員瞭解客戶（個人和企業）可以操作的各種型別的賬戶以及詳細的業務流程。

• 保險銷售代表可以理解獲取保險單所涉及的各個階段。

• 營銷分析師更有可能瞭解客戶關係管理系統中涉及的關鍵利益相關者和業務流程。

• 參與資本市場專案的業務分析師應該具備專業知識和對股票、固定收益和衍生品的深入瞭解。此外，預計他擁有後臺、前臺、應用風險管理模型的實踐經驗。

• 醫療保健業務分析師需要對美國醫療保健財務和利用指標、EDI 837/835/834 的技術經驗和理解、HIPAA 指南、ICD 編碼 - 9/10 和 CPT 程式碼、LOINC、SNOMED 知識有基本瞭解。

一些業務分析師透過測試業務應用程式和與業務使用者合作來獲取領域知識。他們透過人際交往和分析技能創造了良好的學習環境。在某些情況下，他們會透過 AICPCU/IIA 和 LOMA 在保險和金融服務領域提供的少量領域認證來補充他們的領域知識。還有其他機構提供其他領域的認證。

其他主要活動

在徹底檢查當前業務流程後，您可以提供高度專業的幫助，以識別系統建模的最佳方法。

• 組織準備以確保系統高效自動化的方式對業務流程進行正式和統一的描述。

• 協助您的團隊填寫開發人員可能提供的相關係統的標準問卷。

• 參與工作會議，為開發人員定義需求。

• 檢查和控制您設定的需求是否已正確“複製”並記錄在描述系統未來模型的文件（藍圖）中。

• 準備資料並協助系統原型設計。

• 協助準備系統所需格式的列表和餘額遷移資料。

• 審查設定的原型，以確保其符合業務流程所有者定義的需求。

• 作為您 IT 團隊在準備資料和實際執行系統功能和整合測試方面的支援資源。

在下一節中，我們將簡要討論大型組織在 IT 環境中使用的一些流行的業務建模工具。

工具 1：Microsoft Visio

MS-Visio 是一款繪圖和圖表軟體，可幫助將概念轉換為視覺化表示。Visio 為您提供預定義的形狀、符號、背景和邊框。只需將元素拖放到圖表中即可建立專業的溝通工具。

步驟 1 - 要開啟新的 Visio 繪圖，請轉到“開始”選單並選擇“程式”→“Visio”。

步驟 2 - 將游標移到“業務流程”上並選擇“基本流程圖”。

以下螢幕截圖顯示了 MS-Visio 應用程式的主要部分。

現在讓我們討論每個元件的基本實用程式 -

A - 螢幕頂部的工具欄與其他 Microsoft 程式（如 Word 和 PowerPoint）類似。如果您以前使用過這些程式，您可能會注意到一些不同的功能，我們將在稍後探討。

選擇“幫助”>“圖表庫”是熟悉 Visio 中可以建立的繪圖和圖表型別的好方法。

B - 螢幕左側顯示特定於您正在建立的圖表型別的選單。在這種情況下，我們看到 -

• 箭頭形狀
• 背景
• 基本流程圖形狀
• 邊框和標題

C - 螢幕中央顯示圖表工作區，其中包括實際的圖表頁面以及頁面旁邊的一些空白區域。

D - 螢幕右側顯示一些幫助功能。有些人可能會選擇關閉此視窗以增加圖表工作區的面積，並在需要時重新開啟幫助功能。

工具 2：Enterprise Architect

Enterprise Architect 是一款基於 UML 的視覺化建模和設計工具。該平臺支援軟體系統的設計和構建、業務流程建模和基於行業的領域建模。它被企業和組織用來不僅對他們系統的架構進行建模。而且要處理這些模型在整個應用程式開發生命週期中的實現。

Enterprise Architect 的目的是確定組織如何最有效地實現其當前和未來的目標。

Enterprise Architect 有四個視角，如下所示 -

• 業務視角 - 業務視角定義了業務日常運營的流程和標準。

• 應用程式視角 - 應用程式視角定義了組織使用的流程和標準之間的互動。

• 資訊視角 − 定義和分類組織為了高效運營而需要的原始資料，例如文件檔案、資料庫、影像、簡報和電子表格。

• 技術視角 − 定義組織使用的硬體、作業系統、程式設計和網路解決方案。

工具 3：Rational Requisite Pro

獲取、記錄、組織、跟蹤和更改需求，並在專案團隊之間傳達這些資訊的過程，以確保在整個專案生命週期中維護迭代和意外更改。

監控狀態並控制對需求基線的更改。主要元素是變更控制和可追溯性。

Requisite Pro 用於上述活動和專案管理目的，該工具用於查詢和搜尋，檢視作為需求一部分的討論。

在 Requisite Pro 中，使用者可以在需求文件上工作。該文件是在 Reqpro 應用程式中建立並與專案資料庫整合的 MS-Word 檔案。在 Requisite Pro 之外建立的需求可以匯入或複製到文件中。

在 Requisite Pro 中，我們還可以使用可追溯性，在這裡它表示兩個需求之間的依賴關係。可追溯性是一種透過連結彼此相關的需求來管理更改的系統方法。

Requisite Pro 使得在整個開發週期中輕鬆跟蹤需求的更改，因此無需單獨檢視所有文件以確定哪些元素需要更新。您可以使用可追溯性矩陣或可追溯性樹檢視檢視和管理可疑關係。

Requisite Pro 專案使我們能夠建立一個專案框架，在該框架中組織和管理專案工件。每個專案都包含以下內容。

• 一般專案資訊
• 包
• 一般文件資訊
• 文件型別
• 需求型別
• 需求屬性
• 屬性值
• 跨專案可追溯性

Requisite Pro 允許多個使用者同時訪問相同的專案文件和資料庫，因此專案安全方面非常關鍵。安全性可防止未經授權的使用者訪問專案文件，從而防止系統使用、潛在危害或資料丟失。

建議為所有 RequisitePro 專案啟用安全性。這樣做可確保對專案的任何更改都與進行更改的個人的正確使用者名稱相關聯，從而確保您擁有所有更改的完整審計跟蹤。