企業架構有四大支柱，分別是業務架構、數據架構、應用架構和技術架構，上次我寫了一篇業務架構的文章《把業務架構搞搞懂，才算敲開了理解業務的大門！》，談了對業務架構的粗淺理解，這次來講講應用架構。

網上關于應用架構的資料非常碎，因此我找了企業架構開發方法的權威TOGAF作為參考，把應用架構的交付物和端到端流程全部走了一遍，圖文并茂，希望盡量用淺顯易懂的方法把應用架構講講清楚。

一、企業架構全景圖

TOGAF（The Open Group Architecture Framework）是一個工具集、術語集和流程集，提供了一個全面的方法來開發企業架構。TOGAF的中心是一個被稱為"架構開發方法"（Architecture Development Method，簡稱ADM）的流程，如下圖所示：

我們最關注的是業務架構、數據架構、應用架構及技術架構，這些架構層次的描述體現了從高層策略到低層實施的逐漸細化的邏輯。

1、業務架構

主要關注業務策略、治理、組織和關鍵業務流程。

描述業務功能、業務流程、事件、組織單位、角色、業務服務以及其他業務行為。

2、數據架構

描述組織的物理和邏輯數據資產以及數據管理資源。

關注企業的信息資產，如何在應用和業務流程中結構和使用它們。

3、應用架構

描述應用系統的總體結構和應用組件的相互關系。

關注系統解決方案和服務以支持業務架構的需求。

4、技術架構

描述硬件、軟件、網絡和其他技術資源的策略和標準。

定義支持應用架構運行所需的基礎技術結構。

應用架構與其他三個架構有緊密聯系：

1、業務架構定義了為什么要進行某項業務，并提供了業務需要什么樣的信息支持（即數據架構）。

2、數據架構和應用架構合作，確保業務流程能夠通過正確的信息系統得到所需的支持。應用架構定義了什么系統需要進行交互，以及這些系統如何與數據交互。

3、技術架構再進一步定義了如何實施應用架構，它描述了支持數據、應用和業務功能所需的基礎技術。

這四個層次構成了企業架構的綜合視圖，它們共同工作，確保從高層的業務策略和要求到實際的技術實施都是對齊的。

二、應用架構的定義

應用架構在TOGAF中處于階段C，專注于定義支持業務和數據處理所需的應用系統，它描述了應用系統之間、應用與用戶之間的交互和行為。

不同于應用程序或軟件的內部架構，應用架構不涉及單個應用的具體架構和實現技術。其核心是確定企業需要哪些類型的應用以及這些應用如何管理數據和為企業人員提供信息。在應用架構中，應用被視為負責支持數據對象管理的邏輯功能組或支持業務功能的組件，而不是具體的計算機系統。總之，應用架構關注如何整合多個應用系統以滿足業務需求，而不是單個系統的技術細節。

那么，應用架構具體長啥樣呢？

TOGAF 提供了一個詳細的架構工具模型，如下所示：

在階段C，TOGAF定義了應用架構的主要交付物，共分目錄、矩陣、圖三類類型，總計14個制品：

1、目錄：應用組合目錄、接口目錄

2、矩陣：系統/組織矩陣、角色/系統矩陣、系統/功能矩陣、應用互動矩陣

3、圖：應用通信圖、應用和用戶位置圖、系統用例圖、企業可管理性圖、流程/系統實現圖、軟件工程圖、應用遷移圖、軟件分布圖等

下面以案例的形式逐個說明這14個制品的具體內容，應用架構的最終交付物往往是這14個制品的編排組合：

1、應用組合目錄

假設我們有一個中型企業，該企業涉及以下幾個核心業務領域：

（1）銷售：負責產品的銷售。

（2）人力資源：負責員工的招聘、培訓和福利。

（3）財務：負責公司的財務管理，如支付、收款、預算和報表。

基于這三個業務領域，我們可以列出以下的應用組合目錄：

在這個簡化的應用組合目錄中，我們可以清晰地看到每個應用支持哪個業務領域，它們的主要功能是什么，它們運行在哪些技術平臺上，以及它們當前的生命周期狀態。這有助于企業更好地管理其應用組合，理解各應用之間的關系和依賴性，并決定在哪里投資以支持未來的業務需求。請注意，實際的應用組合目錄可能會包含更多的細節和其他信息，例如應用的擁有者、應用的使用頻率、應用的維護成本等。

2、接口目錄

接口目錄（Interface Catalog）在TOGAF中是一個結構化的文檔或表格，用于描述、定義和記錄組織內外的應用接口。這個目錄通常列出了組織中所有已知的應用接口，并為每個接口提供了相關的詳細信息。這有助于在整個組織中確保接口的一致性和互操作性。

接口目錄通常包括以下內容：

接口名稱：一個簡短、描述性的名稱。

接口描述：接口的簡短描述。

來源應用：發起或產生數據的應用名稱。

目標應用：接收或消費數據的應用名稱。

接口協議：如 HTTP、FTP、SOAP、REST等。

數據格式：如 XML、JSON、CSV等。

數據內容：傳輸的數據的簡短描述或摘要。

接口狀態：如激活、待激活、已棄用等。

以下是一個簡化的接口目錄示例，假設我們之前提到的企業場景：

此接口目錄提供了一個中心位置，用于管理和查看應用之間如何交互，使用哪些技術和協議，以及傳輸的數據內容是什么。這對于確保數據的一致性、減少接口冗余、理解和優化數據流程都是非常有用的。

3、系統/組織矩陣

系統/組織矩陣（System/Organization Matrix）是一個工具，用于顯示各個組織部門或角色與系統之間的關系。該矩陣有助于理解哪些部門或角色使用或擁有哪些系統，從而可以更好地協調和規劃業務和IT資源。

一個簡單的系統/組織矩陣可能像這樣：

在此示例中，我們可以看到：

銷售部門使用銷售管理系統和銷售分析工具。

人力資源部門使用人力資源信息系統。

財務部門使用財務管理系統。

管理團隊可以查看所有系統的信息，但可能沒有完全的使用權限。

這種矩陣形式的表示方法為組織提供了一個清晰、簡潔的視圖，展示了各部門或角色與各系統之間的關系。這有助于確保系統的正確分配、減少重復投資、優化許可證成本，并確保適當的培訓和支持。

4、角色/系統矩陣

角色/系統矩陣（Role/System Matrix）是一個工具，用于顯示組織內各個角色與他們與系統的關系。這個矩陣有助于了解哪些角色需要訪問哪些系統，以及他們對這些系統的具體使用模式（例如，查看、編輯、創建等）。

一個簡單的角色/系統矩陣可能如下所示：

在此示例中，我們可以觀察到：

銷售代表需要在訂單處理系統中創建和編輯數據，在人力資源管理系統中查看數據，并在客戶關系管理系統中進行各種操作。

人力資源經理在人力資源管理系統中有廣泛的權限，在財務系統中可以查看數據，并且可以在客戶關系管理系統中查看數據。

財務分析師在訂單處理系統中可以查看數據，在財務系統中有創建和編輯的權限，并且可以在客戶關系管理系統中查看數據。

客戶服務代表可以在訂單處理系統和客戶關系管理系統中查看和編輯數據。

這個矩陣為組織提供了一個簡明扼要的方式，來展示不同角色如何與各種系統互動。這對于理解和管理權限、培訓需求和審計跟蹤都非常有幫助。

5、系統/功能矩陣

在TOGAF中，系統/功能矩陣（System/Function Matrix）是一個工具，用于表示特定的系統提供了哪些功能。它幫助架構師和其他利益相關者理解系統的功能覆蓋范圍，并確保滿足了所有預期的功能需求。

一個簡單的系統/功能矩陣可能如下所示：

在此示例中：

電子商務系統提供了訂單處理、庫存管理和付款處理功能。

倉儲管理系統專注于庫存管理并提供報告生成功能。

財務系統處理付款并能夠生成報告。

銷售分析系統處理訂單數據并提供報告功能。

通過這樣的矩陣，組織可以清晰地看到各系統之間的功能交集或功能缺失，從而進行優化或整合。此外，當需要對某一功能進行更改或升級時，矩陣可以迅速提供哪些系統可能受到影響的信息。

6、應用互動矩陣

應用互動矩陣（Application Interaction Matrix）主要用于描述不同應用之間的交互和依賴關系。這種矩陣提供了一個結構化的方法來捕獲和描述如何通過各種接口和服務在應用之間傳遞數據。

這種矩陣特別有助于：

（1）明確哪些應用需要與其他應用通信。

（2）確定數據流的方向和性質。

（3）提供有關應用如何協同工作以支持特定的業務流程的視圖。

以下是一個簡化的應用互動矩陣例子，假設一個制造企業有以下應用：

（1）銷售系統

（2）生產計劃系統

（3）倉儲系統

（4）財務系統

矩陣可以如下：

解釋：

（1）銷售系統:

與生產計劃系統交互：請求產品信息以確保產品可用性。

與倉儲系統交互：查詢庫存確保產品庫存量。

與財務系統交互：創建發票和管理付款。

（2）生產計劃系統:

與銷售系統交互：接受并處理銷售訂單。 與倉儲系統交互：基于需求和庫存發出生產訂單。 與財務系統交互：查詢產品的制造成本。

（3）倉儲系統:

與銷售系統交互：提供庫存信息。 與生產計劃系統交互：接受并執行生產訂單。 與財務系統交互：提供庫存產品的成本信息。

（4）財務系統:

與銷售系統、生產計劃系統 和 倉儲系統都有交互，處理與財務相關的各種事務。 通過此應用互動矩陣，企業可以明確理解其不同應用之間的交互和依賴關系，從而更好地進行集成和優化工作。

7、應用通信圖

應用通信圖（Application Communication Diagram）描述了應用組件之間的通信關系。這些關系可以是調用、數據流或其他形式的連接。這種圖有助于展示系統和應用之間的交互模式，以及它們是如何支持業務功能和進程的。

應用通信圖通常包含以下元素：

（1）應用組件：如系統、模塊或其他應用單位。

（2）通信關系：如數據流、調用或消息傳遞。

（3）可選地，外部用戶或系統和其他接口。

案例描述：

假設一個簡化的電商平臺包含以下應用組件：

（1）客戶前端（Customer Frontend）

（2）訂單管理系統（Order Management System）

（3）倉庫管理系統（Warehouse Management System）

（4）付款網關（Payment Gateway）

在應用通信圖上，它們的交互可以描述如下：

（1）客戶前端

用戶在這里瀏覽產品、添加到購物車并下單。 當用戶下單時，前端與訂單管理系統通信，提交訂單詳情。 前端還與付款網關通信，處理支付。

（2）訂單管理系統

接收來自客戶前端的訂單數據。 與倉庫管理系統通信，通知出貨。 一旦支付確認，通知付款網關。

（3）倉庫管理系統

接收來自訂單管理系統的出貨請求。 更新庫存信息。

（4）付款網關

接收和處理來自客戶前端的支付請求。 一旦支付成功，通知訂單管理系統。

這只是一個非常簡化的示例，實際的應用通信圖可能包括更多的細節、更復雜的應用和更多的交互模式。這種圖為企業提供了一個可視化的工具，以理解應用如何互相關聯，以及它們是如何支持特定的業務需求和流程的。

8、應用和用戶位置圖

應用和用戶位置圖（Application and User Location Diagram）是用來展示應用系統與用戶的物理位置關系的。這種圖的目的是確保應用的部署位置滿足用戶的性能需求，并可以實現應用之間的互動。它還有助于確定網絡帶寬需求。

例如，考慮一個大型企業，它的總部位于紐約，但在全球各地都有辦公室。它使用一個集中的CRM系統、ERP系統和一個分布式的報告工具。一個簡化的應用和用戶位置圖案例描述：

（1）物理位置

紐約 (總部)

倫敦

北京

孟買

（2）應用系統

CRM系統 (部署于紐約)

ERP系統 (部署于紐約)

報告工具 (分布式部署于各個辦公室)

（3）用戶

銷售團隊 (在所有辦公室)

財務團隊 (主要在紐約和倫敦)

人力資源 (主要在紐約)

這個圖展示：（1）CRM和ERP系統在紐約的數據中心有實體。

（2）報告工具在每個辦公室都有實體或本地訪問點。

（3）銷售團隊在各個地方都需要訪問CRM。

（4）財務團隊在紐約和倫敦需要訪問ERP系統。

（5）人力資源在紐約訪問ERP系統的HR模塊。

這樣的圖有助于決策者理解網絡帶寬的需求，以及如果某個地方的系統出現問題，哪些用戶將受到影響。這還有助于計劃備份和災難恢復策略。

9、企業可管理性圖

企業可管理性圖（Enterprise Manageability Diagram）主要描述了架構管理和控制要點，以確保系統的穩定性、性能、安全性和其他可管理性方面的要求得到滿足。這些圖表提供了對管理控制點（例如性能監控、安全性、日志記錄、異常管理等）的高級視圖，以及管理數據如何流動到企業中的各種支持系統（例如性能監控工具、安全工具、事件管理工具等）。

具體案例：

假設一個大型在線電商公司有以下幾個主要的系統模塊：

（1）用戶服務

（2）商品瀏覽服務

（3）訂單處理服務

（4）付款服務

（5）物流服務

以及以下管理工具：

A. 安全監控工具B. 性能監控工具C. 錯誤日志系統D. 用戶行為分析工具

一個簡化的企業可管理性圖可能如下：

以上描述提供了一個概念性的視圖，描述了這些服務與企業的管理工具之間的互動。在實際的企業可管理性圖中，這些關系會被更加直觀地表示出來，通常使用箭頭來指示數據流的方向。

10、軟件工程圖

軟件工程圖（Software Engineering Diagram）是用來展示應用結構的。這些結構包括應用的軟件組件、接口和與其他軟件組件的連接。它為軟件工程師和系統開發人員提供了一個視角，幫助他們理解和構建系統的軟件部分。這種圖的核心是展示軟件組件之間的關系、依賴和流程。其目的是為了確保軟件設計的完整性和一致性。

案例：在線圖書商店

假設我們要為一個在線圖書商店開發軟件。以下是與此相關的軟件工程圖的簡化描述：

軟件組件：

（1）用戶界面組件：處理用戶交互、顯示圖書目錄、購物車管理等。

（2）訂單處理組件：處理用戶的訂單，包括支付、庫存檢查和訂單狀態更新。

（3）支付網關接口組件：與外部支付服務提供商進行交互，處理支付事務。

（4）庫存管理組件：負責圖書的庫存檢查和更新。

（5）推薦系統組件：基于用戶的瀏覽和購買歷史為其提供圖書推薦。

關系和依賴：

（1）用戶界面組件依賴于推薦系統組件來為用戶提供圖書推薦。

（2）用戶界面組件將訂單數據發送到訂單處理組件。

（3）訂單處理組件與支付網關接口組件交互，以處理支付。

（4）訂單處理組件查詢庫存管理組件來檢查圖書的可用性。

在實際的軟件工程圖中，這些組件、接口和關系將被更詳細地展現，還可能包括具體的方法、屬性或操作。

11、系統用例圖

系統用例圖通常是一個高層次的圖，描述了系統與其外部實體（例如用戶、其他系統或外部組織）之間的交互。用例圖能夠描述系統的主要功能，并表明誰可以執行或受益于這些功能。

用例圖包括以下元素：

（1）參與者：與系統交互的外部實體，可能是用戶、其他系統或硬件設備。

（2）用例：系統的功能或動作，用橢圓表示。

（3）關系：表示參與者與用例之間的交互關系。

案例：假設我們要為一個圖書館信息系統創建一個系統用例圖。

（1）參與者

讀者

圖書管理員

（2）用例

借書 還書 查找圖書 登記新圖書 注銷圖書

（3）關系

讀者可以“查找圖書”，“借書”和“還書”。 圖書管理員可以執行所有的用例。

這個簡單的用例圖為我們提供了一個清晰的視圖，描述了圖書館信息系統的主要功能及其與參與者的交互方式。

12、流程/系統實現圖

流程/系統實現圖（Process/System Realization Diagram）主要目的是確保某個業務流程或業務用例可以通過現有的系統和應用得到實現和支持。這種圖的目標是描述系統的物理實現和系統如何支持某一流程或多個流程。

這種圖通常顯示：

業務流程或用例的一部分或全部 支持該流程的系統或應用組件 系統或應用組件之間的流動或交互

以HR招聘流程為例：

（1）發布職位

業務活動：HR部門確定了一個新的職位或空缺，需要在公開市場上進行招聘。 IT系統支持：HR管理系統中，HR人員可以創建和發布新的職位描述、職位要求等。

（2）篩選簡歷

業務活動：收到應聘者的簡歷后，HR人員對簡歷進行篩選，將符合條件的簡歷篩選出來。 IT系統支持：HR管理系統允許HR人員記錄每個候選人的信息，簡歷篩選工具可以幫助快速篩選合適的簡歷。

（3）安排面試

業務活動：對于篩選出來的候選人，HR或相關部門人員會安排面試。 IT系統支持：電子郵件系統用于發送面試邀請給候選人；日歷系統用于安排和通知面試時間。

（4）面試反饋

業務活動：面試官在面試后提供對候選人的反饋。 IT系統支持：面試評價系統允許面試官輸入和保存他們對候選人的評價。HR管理系統會更新應聘者的狀態。

（5）發放Offer

業務活動：對于成功的候選人，公司會發放正式的工作邀請或Offer。 IT系統支持：HR管理系統可以生成、記錄和發送Offer。

（6）入職安排

業務活動：一旦候選人接受Offer，HR部門會為其入職做準備。 IT系統支持：HR管理系統可以安排入職培訓、生成員工編號等。

流程/系統實現圖將明確這些業務活動如何與各個IT系統相關聯。它可以清晰地展示每個活動是如何由不同的IT系統支持的，以及這些系統之間如何交互來支持整個業務流程。

13、應用遷移圖

應用遷移圖（Application Migration Diagram）主要描述了從當前架構狀態到目標架構狀態的遷移路徑。這個圖為架構師、項目管理、IT策略決策者等提供了一個明確、可視化的工具，用以顯示如何在多個項目或階段中進行遷移以達到最終的目標狀態。

具體來說，應用遷移圖主要包括：

（1）現有的應用、組件或系統。

（2）預期的未來或目標應用、組件或系統。

（3）遷移路徑，這可能涉及到某個應用的升級、合并、退役或替換。

（4）時間軸或項目階段，以展示遷移的進展和時間表。

讓我們考慮一個場景：

一個大型企業決定將其所有應用遷移到云環境以減少基礎設施成本和提高可伸縮性。此外，由于某次收購，他們還需要整合新公司的一些應用程序。原始環境中有CRM, ERP, 和一個舊的財務系統。收購帶來了一個新的BI系統和ERP系統。他們的目標是：

（1）遷移CRM到云并升級到最新版本。

（2）合并兩個ERP系統，并在云中運行一個統一版本。

（3）廢棄舊的財務系統，并在云中使用收購公司的BI系統。

（4）CRM集成新的BI系統

在此圖中，我們可以看到各種遷移活動，以及由于整合和依賴關系帶來的復雜性。這樣的圖形提供了關于項目計劃和資源分配的見解，以確保遷移的成功。

14、軟件分布圖

軟件分布圖（Software Distribution Diagram）在TOGAF中主要是描述軟件的物理部署以及如何在多種環境中進行分布。這種圖的目標是確保所有的軟件組件都被適當地部署到其所需的硬件環境中。這包括顯示軟件組件、關系、以及它們如何映射到硬件上。這有助于明確哪些軟件組件部署在哪些服務器、設備或平臺上。

假設有一個電子商務應用，它包括前端服務器、后端應用服務器、數據庫服務器、以及一個CDN（內容分發網絡）來服務其靜態內容。以下是此案例的軟件分布圖：

在這個例子中：

數據中心內有前端Web服務器、應用服務器和數據庫服務器。 CDN用于分發靜態內容。 移動用戶設備上的移動應用通過API與前端Web服務器通信。 前端Web服務器與應用服務器以及數據庫服務器之間存在通信。 前端Web服務器從CDN的靜態內容分發節點請求靜態內容。

那么，應用架構定義這么多輸出物的目的是什么？

1、全面性：應用架構需要涵蓋許多方面，從高層策略到詳細的實施細節。多個輸出物確保了各個方面都得到了恰當的關注。

2、分層的設計：不同的輸出物對應不同的關注點。例如，系統/功能矩陣關注功能的分配，而應用通信圖關注應用之間的互動。這樣的分層設計有助于簡化復雜性。

3、有效溝通：不同的利益相關者需要不同的信息。例如，業務人員可能更關心應用組合目錄，而技術團隊可能更關心應用互動矩陣或軟件工程圖。為每個群體提供專門的輸出物可以確保他們得到所需的信息。

4、靈活性和模塊化：分解成多個輸出物意味著當組織的某個部分發生變化時，只需更新或修改特定的輸出物，而不是整個架構。

總的來說，應用架構的多個輸出物提供了一個全面、詳細和模塊化的方法來描述和管理組織的應用景觀。這確保了有效的溝通、明確的決策路徑、和更好的架構治理。

大家平時看到的很多應用架構圖表現形式千變萬化，但無論怎么變化，核心內容大都逃不掉TOGAF定義的14種制品的內容范圍，下面舉例說明：

1、某WeB中間件功能架構圖，其實就是系統/功能矩陣的視圖版本。

2、某支付系統架構圖，看起來挺復雜的，其實就是系統/功能矩陣、應用通信圖、應用互動矩陣、角色/系統矩陣的組合。

3、“4+1”視圖模型是Philippe Kruchten提出的，它為軟件架構定義了五種主要視圖：邏輯、實現、過程、部署和用例視圖，其與應用架構交付物其實也有很好的對應關系，如下所示：

（1）邏輯視圖

應用通信圖：展示了應用組件間的通信和關系，這與邏輯視圖的關注點相似。 系統/功能矩陣：展示了系統與其支持的功能之間的關系，這與邏輯視圖的關注系統功能有關的部分相似。 應用互動矩陣：展示了應用間的互動，這也是邏輯視圖的一部分。

（2）實現視圖

軟件工程圖：這個圖描述了系統的軟件結構，包括軟件組件、它們的依賴關系以及與之相關的構建和發布流程。這與實現視圖的核心概念非常相似。 軟件分布圖：此圖描述了軟件如何分布于物理硬件之上，但它還涉及軟件組件及其依賴關系，這也與實現視圖的部分關注點相似。

（3）過程視圖

應用通信圖：展示了應用組件之間的通信路徑和方法，這涉及到動態的信息交換，與過程視圖關注的運行時交互相似。

（4）部署視圖

應用和用戶位置圖：這個圖描述了應用的物理部署以及用戶的物理位置。它提供了有關哪些應用部署在哪里，以及用戶如何與它們互動的信息。這與部署視圖的主題非常相似。 軟件分布圖：此圖描述了軟件如何分布于物理硬件之上。它直接關注于軟件組件與硬件資源之間的映射，這與部署視圖完全一致。

三、應用架構的構建

TOGAF給出了ADM的架構開發方法，這種方法同樣適用于獨立的應用架構開發，企業可以基于自身實際對ADM進行裁剪后進行。這里以供應鏈管理系統升級為例，演示如何使用TOGAF的ADM來創建一個應用架構的交付物，即系統/功能矩陣：

1. 準備階段 (Preliminary Phase):

輸出物:

架構原則: “采購管理集中化、標準化、一體化”，“流程高效”。

架構框架：采用TOGAF架構方法、ArchiMate建模工具和相關系統、流程文檔模板。關鍵利益相關者列表：上級管理層、供應鏈經理/主管、采購團隊、庫存和倉庫管理者、外部合作伙伴、財務團隊、IT團隊等。

2. 架構愿景 (Phase A: Architecture Vision):

與公司領導、采購部門、物流部門等相關部門協作，明確他們希望系統達到的目標和功能。預期輸出：“集成性”、“統一性”、“智能化”。

3. 業務架構 (Phase B: Business Architecture):

通過與各部門溝通，繪制業務流程圖 識別和記錄核心業務功能，如“采購尋源”、“需求預測”、“物流配送”等。 輸出：業務流程圖、核心功能列表。

4. 應用架構 (Phase C: Application Architecture):

現有架構評估：發現現有的功能分散在“供應鏈管理系統“、”MIS系統”、“供應商門戶系統”、“合同管理系統”等。

定義目標應用架構:

根據業務架構輸出，未來的供應鏈管理系統需要支持的功能：“庫存管理”、“訂單生成”、“需求提報”等。

識別和定義系統組件：例如“供應鏈管理系統”、“MIS系統”、“決策支持系統”。

創建系統/功能矩陣。在其中，所有系統都被列出，并對每個功能進行標記，以指示該系統是否支持該功能。

5. 機會與解決方案 (Phase E: Opportunities & Solutions):

發現“需求提報”和“訂單生成”落在了MIS系統，“采購合同”和“供應商注冊”分別落在了合同管理系統和供應商門戶系統，“采購分析”落在了供應鏈管理系統，這些功能與原有系統的定位不符，供應鏈功能割裂，導致流轉不暢，考慮重新歸位。輸出：一系列建議和機會，以優化系統功能。

6. 遷移規劃 (Phase F: Migration Planning):

基于系統/功能矩陣和機會列表，根據系統間功能模塊的業務關聯程度選擇業務依賴較高的功能模塊作為優先建設的目標，制定遷移策略 第一步：整合現有供應商門戶、合同管理系統相關功能到新供應鏈系統 第二步：遷移并升級需求提報、庫存管理等功能到新供應鏈系統，與MIS系統做好集成 第三步：決策支持系統新增采購分析等能力