Skip to main content
企業架構實務（一）：專案管理與企業架構如何合作？

Architecture Journal

enterprise-architectureproject-managementgovernance

企業架構實務（一）：專案管理與企業架構如何合作？

專案常遇到一種很實際的衝突：眼前的交付有明確期限與預算，這次選擇卻可能改變下一個專案的整合成本、資料責任與營運風險。專案管理關心範疇、時程、資源與驗收；企業架構（Enterprise Architecture，EA）關心企業能力、系統邊界與轉型順序。兩者處理的是同一項投資，只是觀察的時間尺度不同。

只靠專案管理，團隊可能準時完成眼前的交付，卻把整合成本或技術債留給下一個專案。只靠 EA，組織可能畫出完整的目標架構，卻沒有把方向轉成預算、里程碑與可驗收成果。

本文以企業內部 EA 培訓使用的參考資料為出發點，整理一套協作框架，用來回答一個實務問題：

專案管理與 EA 如何在不同時間尺度上互相補位，讓專案完成當期交付，也不偏離企業長期方向？

為了避免角色混用，本文以 PM 代表單一專案中的專案管理職能；涉及投資組合、跨專案資源與治理機制時，則使用 PMO 或專案治理。業務價值、投資優先級與風險是否接受，最終由董事會、專案贊助人、產品負責人或其他有權責的業務 owner 決定。

當期交付也會留下長期架構影響

系統發生事故時，專案通常先修正直接原因、完成回歸測試，再控制下一次上線的風險。這些工作都合理，也需要 PM 管理範圍、期限、依賴與驗收。然而，如果每次修補只處理本期問題，沒有檢查資料責任、整合邊界與故障範圍，眼前完成的交付可能成為下一個專案的限制。

MIT CISR 的《Enterprise Architecture as Strategy》把 EA 定位為建立 business execution foundation 的方式：企業先決定哪些流程必須做好，再用架構把策略落實成可運作的能力。[1] 換成專案語言，就是先確認組織需要哪些能力與結果，再判斷現有系統如何逐步演進。

兩種角色可以濃縮成一句話：

PM 確保當期交付可行且受控；EA 確保這次交付仍朝企業需要的能力前進。

在決策形成前，PM 與 EA 共同提出選項與代價，再由有權責的業務或投資決策者決定價值、優先級與風險處置。

flowchart TB
  EA["EA 視角<br/>企業方向、能力缺口與目標狀態<br/>系統、資料與整合邊界"]
  PM["PM 視角<br/>當期範圍、里程碑、預算<br/>依賴、風險與驗收"]
  Assessment["共同評估<br/>選項、代價、過渡路徑與影響"]
  Owner["業務／投資決策者<br/>董事會、贊助人或業務 owner"]
  Delivery["分階段交付<br/>計畫、協作、驗收與成果"]
  Evidence["營運與交付證據<br/>實際限制、成果與新風險"]

  EA -->|提供方向與長期影響| Assessment
  PM -->|提供可行性與交付影響| Assessment
  Assessment -->|提出方案與決策資訊| Owner
  Owner -->|決定價值、優先級與風險處置| Delivery
  Delivery --> Evidence
  Evidence -->|更新基線與 roadmap| EA
  Evidence -->|調整範圍與後續計畫| PM

PM 與 EA 看的是不同時間尺度

EA 要讓專案看見這次選擇留下的長期影響。核心資料各自由哪個系統負責？現有系統需要長期共存時，哪些能力要保留、包覆或逐步替換？外部系統無法同步改造時，新的整合邊界如何維持相容？現在的選擇會不會成為下一階段的瓶頸？

這些問題會形成三類架構輸入：

  1. 決策邊界：交易資料要有明確責任歸屬，跨系統整合要有可追蹤的契約與版本策略，重要操作要能稽核。
  2. 目標與過渡狀態：說清楚核心系統、舊 POS 與新能力在不同階段如何共存，不用一開始就畫出涵蓋全企業的完整藍圖。
  3. 跨專案依賴：辨識展店、加盟、會員活動、財務日結與外部平台共同依賴的資料、介面與平台能力。

McKinsey 與 Henley Business School 的調查提供了一個實務對照。自認是 digital leaders 的受訪者更常表示，EA 團隊會參與高階策略討論、更新未來架構，並以 business capability 作為通往目標架構的里程碑。投入高於平均時間做策略規劃的 EA 團隊，也更常回報可持續的解決方案與較高的專案效益。這是相關性調查，不能證明因果，但可以看出長期規劃與專案成果並不互斥。[2]

PM 則把方向轉成專案承諾：這一階段先改善哪一條流程、需要哪些團隊與外部廠商、預算和時程是否足夠、切換失敗如何回復，以及什麼證據可以證明成果。當目標超出團隊可以承擔的範圍，PM 要促成拆分、重新排序或風險升級，讓業務 owner 做出取捨。

Kaine Ugwu 的文章原本比較的是 EA 與 PMO。EA 提供目標狀態、transition architecture、依賴、roadmap 與轉型原則；PMO 形成可執行的專案計畫，並持續回報進度、阻礙、風險與必要變更。[3] 單一專案由 PM 管理交付；跨專案排序、共用資源與投資治理則屬於 PMO 或專案治理。兩個層次要分開，資訊仍需雙向流動。

把合作放進專案生命週期

EA 無須審查每一行程式碼，PM 也不能等到上線前才詢問架構影響。最有價值的介入點，是高影響力決策仍可調整的時候。這種先規劃、再檢查、最後執行的節奏，也和 Plan Gate Execute 談的分階段做法相近。以下分工是本文整理的協作建議，並非引用來源定義的標準流程。

專案階段PM 的主要任務EA 的主要任務協作產出
啟動釐清業務目標、範圍假設、資源與限制評估對企業能力、現有系統與其他計畫的影響展店、新品牌、加盟與不中斷營運的架構影響初評
規劃安排里程碑、預算、依賴、風險與驗收方式定義架構原則、資料責任、系統邊界與過渡狀態分階段 roadmap、外部系統依賴、審查節點與可驗收指標
執行協調工作、阻塞、變更與決策時程參與高影響力設計決策，記錄例外與長期影響ADR、整合契約、切換與回復方案、技術債清單
監控追蹤範圍、時程、成本、品質與風險評估變更是否偏離目標，或把風險轉移到其他系統故障範圍、交易可追查性、展店時間與交付速度的證據
收尾完成驗收、交接、未結事項與經驗回顧更新實際架構、可重用資產與後續 roadmapAs-Is／To-Be 更新、例外處置與下一階段投資建議

這個協作會持續到收尾：預算、人才或外部依賴不足時，調整過渡路徑；資料責任或故障範圍擴大時，重新檢視範圍、時程與風險。重大取捨仍由業務或投資決策者承擔。

把架構方向轉成可驗收成果

以餐飲業為例，連鎖業者從既有門市擴展到更多據點、新品牌或加盟體系時，常會同時面對幾個問題：原本只服務單一品牌與少數門市的 POS 或核心系統，開始承擔訂單、付款、庫存、會員、外送與電子發票等跨通路流程；新門市的菜單、價格、權限與設備設定仍得靠工程團隊處理；舊系統又不能一次下線，因為營運中的門市不能長時間停擺。

因此，轉型不只是換掉一套系統，而是要逐步拆開資料責任與整合邊界，讓新能力可以和既有系統共存，並降低單一服務異常時擴大成所有門市與通路中斷的風險。這時「支援快速展店與多通路成長」仍無法直接排程，也無法直接驗收。PM、EA、產品負責人與交付團隊要把架構意圖拆成專案問題，再為每個問題定義證據。下表只示範這個轉譯方式，不預先決定技術方案。

架構意圖專案需要回答的問題可驗收的證據
局部故障不再拖垮所有門市與通路第一階段先隔離哪些故障？哪些功能可以降級？故障演練證明單一外部服務或模組異常時，其餘接單與出餐流程仍可運作
訂單、付款、退款與發票可追查哪個系統負責各種交易狀態？跨系統如何關聯？客服與財務能沿同一筆交易識別碼查到完整歷程，並解釋狀態差異
舊 POS 與新能力至少共存三年哪些契約必須穩定？門市如何分批切換與回復？相容性測試、分批上線計畫、回復演練與版本淘汰條件
新門市五個工作天內完成設定哪些差異要改成設定？誰有權限修改與核准？用新門市情境演練菜單、價格、權限與設備設定，全程不修改程式

這個轉譯會逼出必要的取捨。第一階段要優先降低尖峰中斷、縮短新門市設定時間，還是先改善財務對帳，屬於業務與投資決策；PM 提供成本、時程與依賴，EA 說明每個選項對目標架構與後續階段的影響。架構要求若排不進計畫、找不到 owner 或無法驗收，代表它仍太抽象，或當期範圍需要重新決定。驗收條件、證據與剩餘風險如何接回交付決策，也可參考 AI 時代的自動化測試與驗收（九）。

留下五份最小產物

有跨系統影響的改造不必產生厚重文件，但至少要留下可追蹤的決策脈絡：

  1. 架構原則對照：方案採用哪些原則，哪些地方暫時例外。
  2. 架構決策紀錄：選了什麼、放棄什麼、依據是什麼、何時重新檢視。
  3. 專案依賴圖：標出核心系統、舊 POS、金流、電子發票、ERP、外送平台、團隊與其他專案。
  4. 例外登錄與處理期限：記錄誰接受風險、補強期限與收斂條件。
  5. 驗收與營運指標：定義上線前如何證明，上線後由誰觀察與處理異常。

架構治理要守住哪些邊界

技術選擇是否需要升級，可以先看影響範圍與不可逆程度。以餐飲連鎖業者為例，下列決策應由 EA 或架構審查介入：

  • 改變訂單、付款、庫存或會員資料的責任歸屬與 domain boundary
  • 新增供多個通路、團隊或品牌共用的 API、事件或平台能力
  • 引入長期基礎設施、供應商、資安或營運依賴
  • 影響加盟權限、個資、稽核、可用性或災難復原
  • 失敗後難以回復，或會和其他轉型專案競爭共同資源

團隊可以自行決定不改變外部契約與資料責任的內部重構、能快速回復的實作細節、已被既有標準涵蓋的低風險選擇，以及只影響單一元件且不增加長期營運負擔的調整。例如，重新整理 Promotion 模組內部程式結構可以留在團隊；改變優惠、訂單與付款之間的交易責任，就需要把問題提高一層。

治理深度也要符合風險。時程壓力確實存在，但審查仍要聚焦於交易、資安、切換與回復風險，不能因此省略高影響力決策的紀錄。若新品牌或加盟需求中途改變資料與權限邊界，EA 先盤點受影響的系統和長期依賴，PM 再換算成時程、成本、品質與承諾的變化，最後由業務 owner 選擇延期、分階段、縮小範圍或接受風險。

這套協作仍有現實限制。目標狀態可能建立在不完整的現況資料上，預算與時程會迫使組織採用過渡方案，不同單位也可能對風險和急迫性有不同判斷。例外缺少 owner 與期限，最後就會成為永久狀態；文件存在，也不等於團隊已理解決策或用營運證據驗證結果。

Atencio、Bustos 與 Mancini 的文獻回顧指出，既有研究強調專案與業務對齊，也把 EA 視為治理工具；但作者在選定文獻中沒有找到 EA 在 project-based organizations 的完整應用，只看到部分元件，EA 在 project management 領域的應用則較明確。[4] 這個研究缺口提醒我們，本文框架適合拿來釐清問題與責任，還不能被當成已成熟驗證的固定方法。

PM 與 EA 的合作可以用三個問題檢查：誰有權決定價值與風險、當期交付要用什麼證據驗收、這次選擇會替下一階段增加什麼限制。PM 讓方向成為可交付承諾，EA 讓交付不會只剩一次性的修補；業務與投資決策者則對最後的取捨負責。

參考資料