專案管理指引（八之八）

 （續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

7.11 品質管制

7.11.1 概述

品質管制的目的是提高產出符合目的或用途的可能性。品質宜作為專案計畫的一個組成部分（見7.2）。品質管制包括品質要求、驗收準則和查證方法、採用的標準以及專案交付物，包括內部、外部、臨時、最終、有形和無形的交付物。宜記錄品質要求和準則，以證明專案如何符合品質要求和準則。

由於專案的臨時性和約束作用，例如進度、成本、品質、資源、風險和其他參數，無法輕易為每個專案制定新的品質準則。品質標準和產品品質要求的制定和組織驗收可以超過專案邊界界限。品質標準和產品品質要求的驗收通常由顧客或執行組織的負責，以兩者之一為準。此外，創新或前所未有的專案可能需要制定新的準則，這也可能帶來新的風險，在專案與組織之間分擔責任，並讓其他利害相關者參與進來。管理專案品質宜包括制定品質管制計畫，品質保證和品質控制流程。

宜告知專案利害相關者以下情況的可能性：
a）專案將達到目標；
b）交付物將符合品質要求和標準；
c) 專案產出和成果將是組織或社會實現預期收益。

7.11.2 規劃品質

規劃品質宜確定適用於專案及其交付物的品質要求、量測指標和標準，以及如何達到該等要求。

為了實現品質，宜定義用於決定需求、設計解決方案產出、構建和基礎解決方案單元、查證與確證該等要素的方法、過程和辦法。正是針對該等方法、過程和辦法，才能進行品質保證和品質控制。

品質要求、量測指標和驗收準則由利害相關者、標準和組織的品質政策確定，並適用於內部、外部、臨時、最終、有形和無形的交付物。

規劃品質宜包括：
a) 決定並與專案發起人和其他利害相關者，就擬實現的目標和相關品質標準達成一致；
b) 記錄專案交付物的品質量測指標和驗收準則；
c) 建立實現商定準則所需的工具、程序、技術和資源；
d) 確定實施計畫的系統品質活動的方法、技術和資源；
e) 制定明確的品質管制方法，包括根據專案計畫安排的審查類型、責任和參與者；
f) 在品質管制計畫中整合品質資訊。

7.11.3 保證品質

品質保證宜促並使其符合適用的性能要求、品質過程和標準，包括：
a） 傳達要使用的目標和相關準則，並查證該等目標和準則是否得到使用；
b） 查證是否符合規定的品質管制方法；
c） 查證是否正在使用既定的工具、程序、技術和資源；
d） 符合計畫的方式，以根據確證的要求和規範（如相關）查證產出；
e） 由獨立于專案經理和團隊的人員進行稽核；他們可以來自發起和或執行組織的另一部分，也可以來自顧客的組織。

變更請求（見7.10）可能來自品質保證活動。

7.11.4 控制品質

品質控制宜用於：
a）決定專案目標、品質要求、品質量測指標和標準是否得能達到；
b）識別造成不符合的原因和消除不符合表現的方法。

品質控制宜考慮進展資料、交付物、品質管制方法，以及品質控制測量的結果、經查證的交付物及檢查報告。結果宜有助於識別性能差或產品品質不符合的原因，並可導致預防和矯正措施以及變更請求。

品質控制宜適用於專案交付物和產出，包括以下活動：
—通過使用既定的工具、程序和技術檢測缺陷，查證交付物和產出達到品質要求；
—分析缺陷產生的可能原因；
—確定預防措施和變更請求；
—溝通矯正措施和變更請求。

品質控制可以由執行組織的其他部門或顧客在專案邊界之外執行。

7.12 專案利害相關者管理

7.12.1 概述

利害相關者參與的目的是使利害相關者的需求、利益和關注點能夠得到充分的識別、理解和解決，從而實現專案目標。

在整個專案裡，宜識別、分析、記錄和參與專案的專案利害相關者。

利害相關者參與宜包括識別和表徵利害相關者的活動。宜進行計畫的參與活動，以確定和解決利害相關者的關注點，並利用利害相關者支持和溝通。

7.12.2 識別專案利害相關者

識別利害相關者時宜同時識別其利益、參與度等資訊。該等資訊可以包括利益、影響力、期望和需求等。利害相關者宜積極參與專案，可以是專案的內部或外部，具有不同的職權級別。

利害相關者宜包括但不僅限於：
a) 發起組織和專案團隊（見4.5）；
b) 顧客；
c) 合作夥伴和供應商；
d) 特殊利益團體或壓力集團；
e) 法規主管機構；
f) 資金提供方；
g) 股東；
h) 相關外部協力廠商。

7.12.3 管理專案利害相關者

對管理利害相關者參與專案的計畫宜考慮已識別的利害相關者、專案計畫和其他專案檔案。管理利害相關者參與可以包括識別利害相關者的關注的問題、解決的問題和特定活動，例如溝通（見7.13），旨在讓關鍵的利害相關者適當參與做出決策的過程（見4.3.1）或參與其他對專案成功至關重要的活動。

利害相關者的問題宜通過外交、談判解決，如有必要，宜根據規定的程序逐級亢遞昇到更高層級的組織權責者。或者，利害相關者的問題可以通過請求個人或協力廠商的協助來解決。解決利害相關者的問題可能導致變更請求（見7.10）。

7.13 溝通管理

7.13.1 概述

溝通管理的目的是實現利害相關者的有效互動，並可能有助於專案成果的成功交付和收益的成功實現。

宜規劃和記錄所選擇的溝通方式和方法。專案的成功取決於溝通的有效性以及溝通與利害相關者的互動程度。

宜進行有計劃的溝通活動，以瞭解利害相關者的資訊需求，包括資訊水準和溝通頻率。宜監督計畫的溝通活動的有效性。

7.13.2 規劃溝通

宜規劃溝通，以滿足利害相關者的需求和期望，包括回饋機制和有效性度量。必要時，溝通宜包括針對特定受眾的一系列特定推廣活動或大型活動，並使用適當的媒體帶有既定目的和傳遞出的信息。

溝通宜側重於通過以下方式支援專案目標：
a) 增進各利害相關者之間的理解與合作；
b) 提供及時、準確、無偏頗的資訊；
c) 設計溝通以將風險將至最低。

宜將地理位置分散的利害相關者、語言、文化和組織隸屬關係等因素與使用的適當媒體一起考慮。

該等因素會對溝通方式產生重大的影響。

7.13.3 分發資訊

宜使用議定的媒體、消息和時間分發針對利害相關者的需求和期望的溝通。
資訊的分發宜在相關情況下為資訊提供足夠的保密性、安全性和準確性，並宜符合溝通計畫。

7.13.4 監督溝通衝擊

宜對溝通的衝擊進行監督和評鑑，並在適當情況下做出回應。如有必要，宜對溝通計畫進行調整，以使專案成果取得成功。監督宜側重於溝通對以下方面的衝擊：
a) 增進各利害相關者之間的理解與合作；
b) 提供及時、準確、公正的資訊；
c) 解決溝通問題以將風險降至最低。

7.14 組織與社會變革管理

7.14.1 概述

組織與社會變革管理的目的是實現專案的預期成果。

如果專案範圍包括預期成果，則需要組織與社會變革管理，以準備、裝備和支援，組織和個人改變他們進行特定活動的方式，並在適當的情況下，改變他們的行為。變革可發生在商業前後環節中，也可以發生在整個社會，也可能發生在更具體的專案前後環節中，例如政府資助的專案中。

變革可以是適應性的（重新引入或調整熟悉的實施）、創新性的（向從業者引入新的實施）或變革性的（引入對行業、組織或社會來說是全新的實施）。

專案經理宜與專案發起人和受到變革影響的利害相關者合作，以實現所需成果。

變革管理宜包括確定組織變革的必要性(無論是在發起組織內部還是外部)，確定所需的具體變革，以及規劃和實施變革所需的活動。

注1：組織變革包括組織的結構、管理或運作方式，例如引入新的工作方式。
注2：社會變革包括影響社會的變化，如基礎設施（如公路、鐵路、機場和供水）、新的稅收制度、國家養老金和福利、住房、環境、健康、安全和保障。

7.14.2 識別變革需要

對於一些專案而言，變革是專案啟動的核心，需要通過組織或社會變革來實現預期成果。在該等項目中，專案經理和適當的團隊宜與專案發起人和受衝擊的利害相關者合作，確定所需的變革，並擬定實施所需變革的計畫。

宜制定變革實施的計畫，以支援組織和個人，如使用者或公民，根據專案的預期成果，改變其方法，並在適當的情況下，改變其行為。

變革計畫宜包括對未來理想狀態的願景或藍圖。該藍圖的制定宜包括評鑑受衝擊的利害相關者的當前狀態，確定所需的變革，並應用適當的技術來實施該等變革。該計畫還宜包括高階的時間表，顯示何時需要取得成果。變革技術可以包括為教學、有影響力和資訊目的之溝通方式，向受影響的利害相關者提供訓練、指導或提供設備或其他資源，以及使用專業的組織變革管理方法。

註：藍圖可稱為「目標營運模式target operating model」、「未來狀態future state」或組織內部使用的任何其他術語。

7.14.3 實施組織與社會變革

實施變革後，專案發起人宜與受衝擊組織和利害相關者的營運經理或代表協調，須監督變革的接受情況以及預期成果的實現情況，或在必要時採取措施。

7.15 專案匯報管理

7.15.1 概述

專案匯報的目的是提供專案的現狀、預測和分析。專案匯報宜與當前的、可能更新的專案檔案保持一致，並根據對專案管理資訊的分析來確定。

宜在專案早期規劃和記錄專案匯報的方式和方法。在專案期間，進行專案匯報，並宜進行監督和調整，以保持與匯報聽取人的需求和要求一致。

註：專案匯報與溝通不同。專案匯報側重於提供專案的狀態、偏差分析和對未來績效的預測，而溝通側重於滿足資訊需求，使利害相關者能夠有效互動，並有助於專案成果的成功交付。

7.15.2 規劃專案匯報

專案匯報宜作為專案治理的一部分進行規劃（見4.3），通常需要將其責任範圍內的工作狀態告知專案組織中不同層級的人員。宜明確專案匯報的要求，包括但不僅限於所需每份報告的內容、匯報人、接收者、頻率、保密性和格式。

7.15.3 管理專案匯報

專案匯報管理宜側重於確認適當和可靠的資訊正在從專案組織的一個層級傳遞到另一個層級。專案匯報可以包括（但不僅限於）以下報告：
a) 從工作包負責人到專案經理，包括進展報告、所需決策和方向以及團隊問題；
b) 從專案經理到專案發起人和專案委員會，反映專案的狀態、風險和問題；
c) 從專案發起人到反映利害相關者在專案中的利益的關鍵利害相關者。

如果報告不再相關或不符合接受者的需求，則宜採取矯正措施。

7.15.4 交付報告

宜按照專案規定的專案匯報管理方式（見6.5.3）及時提交報告。在相關情況下，報告宜遵守機密性或保全性要求。

7.16 資訊與文件管理

7.16.1 概述

資訊與文件管理的目的是使從事工作的人和決策的人能夠獲得相關且可靠的資訊（實體性的、數位化的）。

資訊與文件管理包括安全、及時地收集、儲存、分析、分發和維護等項目的規劃、實施、稽核工作以及經驗教訓和知識管理等活動所需的準確資訊。資訊和文件宜可提供歷史參考。活動宜包括建立一個接收、安全儲存、和識別需要管理和獲取的資訊和文件的系統。與專案相關的資訊和文件管理可能需要根據組織的資訊管理和保留策略進行。

7.16.2 識別應管理的資訊

根據資料保密性、安全性和準確性的要求，宜識別和管理必需的資訊和文件。與專案有關的資訊和文件包括計畫、進度評估、評審、稽核、品質審查、合約、報告、溝通以及與設計、規範和準則等專案產出相關的專業資訊。

7.16.3 儲存、檢索資訊和文件

宜定義並建立一個系統，用於接收、識別、安全儲存和維護資訊和文件，以便資訊和文件可以分發，並且只有授權訪問該資訊和文件的個人才能檢索。該系統宜包括在發生破壞性事件時的業務連續性措施。該系統宜包括對已定義為需要管理的各類專案資訊的處置和保留要求。

宜建立一個系統，以確保相關聯資訊的完整性，例如用於配置管理的系統。

7.17 採購管理

7.17.1 概述

採購的目的是採購品質合適、物有所值、在可接受風險水準內需要時可以交付的產品和服務，作為工作資源的一部分。

採購計畫宜根據專案的採購策略，使用組織的採購流程（如有）。採購管理宜與策劃相結合（見7.2）。

註：採購需要瞭解相關法律和實施，通常由專案組織外的專家進行，如發起組織內的採購專家。

7.17.2 規劃採購

宜定義採購策略，同時考慮到：
a）專案的「自製/外購」決定；
b）交付實務；
c）具有法律約束力的協議的類型；
d）擬使用的採購流程。

負責採購產品和服務的團隊成員宜確定適用的採購準則和流程，以便從外部貨源採購所需的產品和服務。

宜與專案經理或起草明確採購資訊及合約技術規範的機構代表確認採購要求。

7.17.3 評估和選擇供應商

宜在供應商識別、供應商篩選活動獲得的資訊且經過查證，以之作為基礎選擇供應商。

宜根據規定的評估準則對每個供應商的報價進行評估。

根據合約要求，宜在整個專案中重新評估供應商的績效。

7.17.4 管理合約

管理合約宜：
a） 涉及採購關係管理、監督合約執行情況、管理著合約變更和更正、處理索賠和終止合約；
b） 使合約雙方根據具有法律約束力的協議履行合約規定，以滿足專案要求；
c） 包括供應商績效資料收集和詳細記錄的維護（見7.15）；
d） 根據需要在整個專案中執行。

宜以書面形式與供應商就爭議事項進行溝通或跟進，以提供合約雙方採取措施的證據。宜尋求合約和法律諮詢。

7.17.5 終止合約

合約可以在以下兩種情況下終止：
a）當事人的合約義務已經履行；或
b）根據合約的終止條款，合約提前終止。

在制定終止條款時，宜考慮採取措施，將合約終止的成本和衝擊降至最低。
合約結束時，相關合約文件宜按照專案資訊管理架構（見7.16）進行歸檔。

7.18 經驗教訓管理

7.18.1 概述

吸取經驗教訓的目的是從實施中受益，避免重蹈覆轍，並傳遞改進的做法，使當前和未來的專案團隊受益。

專案期間發生的問題、每個問題的解決方式以及每個風險的管理方式都可能帶來經驗教訓。品質審查也可以帶來經驗教訓。宜在整個專案期間予以識別、記錄和傳遞經驗教訓。

7.18.2 識別經驗教訓

在整個專案中，專案團隊和主要的利害相關者宜識別有關專案技術和管理方面的經驗教訓。宜捕獲、彙編、正式化和儲存經驗教訓。

7.18.3 分享經驗教訓

經驗教訓宜在整個專案中傳遞和使用，並在適用的情況下，納入組織的知識庫，以便分享和使用，以促進當前和未來專案績效的改進。

如果一個組織使用定義的專案管理過程或方法，則宜將單個專案的經驗教訓傳達給或方法的所有者，以便改進流程，使其他使用者受益。

註：專案辦公室通常是專案管理流程和方法的擁有者（見4.5.7）。

（全篇竟）

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 專案管理指引

（全篇竟）

專案管理指引（八之七）

 （續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

7.6 進度管理

7.6.1 概述

進度管理的目的是使工作能夠及時進行，並將延誤減少到可接受的水準。進度計畫宜是專案計畫的一個組成部分，並在專案經理的指導下制定（見7.2）。

根據專案實施團隊對工作的承諾或工作之間的影響，時程管理宜包括對活動進行排序、估算活動持續時間以及制定和控制進度。排列活動順序須合乎邏輯順序，以支援發展為切合現實、可實現和可控制的時程計畫。專案中的活動宜用依賴關係來描述，以便確定關鍵路徑或確定替代方法。

專案經理宜根據批准的進度基線監督進度，以使專案範圍能夠在既定的進度約束和目標範圍內按時交付。進度控制宜包括監督與專案相關的階段、工作包和活動的狀態。控制還宜包括管理進度變更、監督里程碑和引入其他適當的控制措施。掙值管理等技術可用於監督進度和預測未來績效（參考ISO 21508）。

7.6.2 估算活動持續時間

在制定時間表之前，專案經理宜與專案團隊合作，估算專案活動的持續時間。與當前活動相比，可以對未來活動進行更詳細的定義。隨著專案的進展和更多資訊的提供，活動可作進一步的定義和詳細說明。活動持續時間可以表示進度約束和資源可獲得性之間的權衡輕重。宜定期重新估計活動持續時間，根據進度基線更新預測是必要的。在專案的整個生命週期內，宜重新考慮活動持續時間的估算。一旦活動基線化，其變更宜使用變更請求（見7.10）。同時，宜識別衝擊專案的新風險和其他事件。

7.6.3進度展開

宜根據所採用的交付方法安排活動。活動的層別宜適合於展開工作、分配資源、確定最終預算和管理控制，提供足夠的解決方案。除了活動網路圖之外，還可以採用其他的進度計畫表達格式。

宜制定進度展開方式，以決定：
a) 專案目標能否如期達成；
b) 關鍵路徑及其相關風險；
c) 對照預定義的基線進度計畫，在進度計畫中實現的實際進度。

進度計畫的制定和查證宜在整個專案中繼續進行。隨著工作的進展，專案的計畫發生了變化，預期風險發生或消失，新的風險被識別出來。如有必要，宜審查和修訂活動持續時間估算和資源估算，以制定經批准的專案進度計畫，該進度計畫可作為跟蹤進度的修訂基線。

7.6.4 控制進度計畫

一旦專案進度計畫和基線得到批准，宜控制專案工作，識別差異項目，並在必要時採取適當的預防和矯正措施。

專案經理宜瞭解在專案早期階段延誤的複雜效應及其對專案目標的衝擊。在決定對任何觀察到的進度延誤的回應時，宜考慮不同約束之間的權衡輕重，例如風險與成本（見4.2.4）。進度控制宜將進度目標重新調整到原始基線，或建立新的進度基線（見7.10），考慮到專案的約束，衝擊盡可能小。宜考慮在工作提前完成時，利用該等機會採取措施。

在控制進度時，重點宜放在：

a） 決定迄今取得的進展；
b） 將進度與批准的進度基線進行對比，以確定任何偏差；
c） 預測完工日期；
d） 實施適當的預防或矯正措施，以避免不利狀況耽擱進度。

宜根據以往趨勢和當前知識，定期制定和更新完工時的進度預測。通過應急或管理儲備各其他的項目管理策略，也可以加快進度。在管理進度時，可使用歷史資料和生產資料、進展資料、專案計畫、資源需求以及識別和記錄的風險來審查總體進度。

7.7 成本管理

7.7.1 概述

成本管理的目的是建立整個專案生命週期內應用的財務控制，便於在批准的預算範圍內交付專案。預算宜是專案計畫的一個組成部分（見7.2）。

成本管理宜包括估算每個工作單元的成本、制定預算、獲取資金和控制專案支出。掙值管理技術可用於監督成本以及預測未來績效，參考ISO 21508。

7.7.2 估算成本

估算成本宜包括制定完成每個專案活動所需成本的近似值。至少宜為第一階段以及整個專案確定成本估算。成本估算可以用多種度量單位表示，例如工時、設備小時數或貨幣價值。

當專案以多種貨幣進行成本估算時，則宜記錄所使用的匯率。應急儲備或管理儲備可用於處理不確定性，如果使用，宜在成本估算中明確說明。

7.7.3 制定預算

將預算分配給計畫工作單元，宜提供基於計畫的預算，以便與實際績效行比較。

宜估算專案的總成本，並確定預算，以確定何時需要資金以及何時預計產生成本。宜根據資金約束和要求，確定和建立管理和衡量成本績效的方法。編制預算時，宜確定成本績效的客觀衡量準則。在進行成本績效評鑑之前制定客觀的措施，可加強問責制，避免出現偏差。

專案成本估算與制定預算密切相關。未分配給活動或範圍內其他工作單元的管理儲備或應急儲備，可以創建並用於管理控制目的或支付不可預見的成本。宜清楚地確定管理儲備或應急儲備，以及如何使用和與之相關的風險類型。將預算資金分配給工作活動形成監督基線，並在批准變更請求時能夠重新確定預算基線。

7.7.4 控制成本

控制成本宜側重于確定當前成本的狀態，將其與成本基線進行比較，以確定偏離變異現象，預測完工時的預計成本，並實施適當的預防或矯正措施。

一旦工作開始後，宜累積績效資料，包括預算成本、實際成本和完工估算。為了評估專案的績效，有必要將成本與累積的計畫資料相結合，例如計畫活動的預估時程對照到當前和未來活動的預計完工日期。

在控制成本時，可以審查幾種資源，包括預算、實際成本和估算成本、預測成本、進展資料、活動清單，變更請求以及授權的變更、矯正措施和專案計畫。

監督著實際成本、預期的未來成本，以及相關的成本差異等，宜促使專案團隊採取適當措施，將專案保持在預算範圍內或提交申請追加資金。

7.8 風險管理

7.8.1 概述

風險管理的目的是提高實現專案目標的可能性。已識別的風險和處理每個風險的選項，宜是專案計劃的一個組成部分（見7.2）。

識別風險是專案團隊全體成員的責任，宜包括識別潛在風險來源及其特徵，如果發生該等風險，可能會對專案目標產生的正向衝擊或負向衝擊。風險管理宜包括在整個專案生命週期內識別、評鑑、處理、控制和應對風險。

7.8.2 識別風險

風險可以在整個專案生命週期內中識別，之前識別的風險可會改變或再次發生。識別風險時宜記錄風險。風險可能有多種來源，既可能是內部或外部。每個風險都應該有一個指定應對者。

註：風險記錄可稱為「風險登記冊risk register」、「風險日誌risk log」或組織內部使用的任何其他術語。

7.8.3 評鑑風險

宜評鑑每個風險的概率(probability)、後果和臨近度，並優先考慮進一步的風險應對行動。宜評鑑各個風險之間的相互關係和依賴性。
注1：後果也稱為「衝擊impact」。
注2：概率也稱為「可能性likelihood」。

7.8.4 應對風險

應對風險宜包括制定若干變通型選擇事項和不同措施，以增加機會並減少對專案的威脅。風險應對措施包括但不僅限於：
a) 接受；
b) 規避；
c) 降低；
d) 轉移；
e) 應急對策；
f) 盡量利用（狀況、情勢）；
g) 強化（自身、韌性）。

為應對特定風險而採取的措施宜與威脅或機會相適應，具有成本效益、及時，在專案前後環節下切合實際，並得到利害相關者的理解，並分配給適當的風險負責人。

剩餘風險可能是由於處理各種風險所採取的措施造成的。在處理風險時，偏離原來計畫時可能需要變更計畫或基線（見7.10）。

7.8.5 控制風險

控制風險宜包括通過確定是否採取了風險應對措施，以及該等措施是否達到預期效果，確保對負面風險的應對措施儘量減少對專案的干擾，而對正面風險的應對措施則最大限度地發揮有益的衝擊。應對措施將對專案的干擾降到最低，而正面風險的應對措施則使收益最大化。在控制風險時，可審查專案管理資訊，包括風險的相對優先順序、進展資料、專案計畫、變更請求和矯正措施。跟蹤風險的發展以及追蹤風險處理的有效性，宜屬控制風險的一個組成部分。

7.9 問題管理

7.9.1 概述

問題管理的目的是解決問題，以免對專案目標的實現產生負面衝擊。

凡涉及的各相關方宜識別問題，並在整個專案中予以解決。宜建立將問題逐級申報至適當管理層級的方法，以處理團隊無法解決的問題。

7.9.2 識別問題

問題發生時宜及時予以識別。大多數問題都須加以處理，以儘量減少其負面影響或利用其對專案的正面衝擊。在定義每個問題時，專案團隊宜包括圍繞該問題的相關事實。宜為專案利害相關者提出問題建立一種安全又可靠的方法。影響專案的問題宜在專案團隊各層級進行識別，並由專案團隊進行管理。涉及到的利害相關者宜明確定義和理解問題。

一旦發現問題，宜立即對其進行初步記錄和分析，以便對其確定優先順序，並首先處理對專案目標衝擊最大的問題。宜分配管理每個問題以解決問題的責任。記錄問題有助於獲取每個問題的詳細資訊，以便專案團隊可以查看問題的狀態以及誰負責解決問題。每個問題的詳細資訊可以包括標題或名稱、問題類型、識別出來問題的日期、問題描述、優先順序、衝擊摘要、措施步驟和當前狀態。

註：問題記錄可稱為「問題登記冊issue register」、「問題日誌issue log」或組織內部使用的任何其他術語。

7.9.3 解決問題

問題解決涉及記錄和處理已發生的事件或問題，該等事件或問題威脅到專案的成功，或代表著可利用的機會。宜建立將問題升級到適當管理層進行決策的方法，以根據團隊和其他利害相關者的建議處理問題。問題管理規劃和解決問題的方法宜納入到專案的治理和管理架構（見6.5.3），概述評估和解決問題所用的方法。

解決問題的決定和理由，宜傳達給適當的專案團隊成員、問題提出者和利害相關者。問題解決宜包含升級方法，當解決方案未出臺或所提供的解決方案被認為不切合實際或不符合利害相關者的要求時，該方法可用於提高認識或優先順序別。問題解決方案宜包括評估問題的影響以及解決問題所需的行動。宜記錄問題的解決情況，以供將來參考和學習。在解決問題時，可能需要偏離計畫或變更基線（見7.10）。

7.10 變更控制管理

7.10.1 概述

變更控制的目的是控制專案和交付物的變更，並正式接受或拒絕該等變更。

變更可能源於專案績效中發現的偏差，也可能源於任何利害相關者，包括決策者、執行管理層、最終用戶、供應商或團隊成員。或者，對風險或問題的處理時可能會導致變更。變更控制宜包括為專案建立一個架構，其中包括識別、評鑑、實施和關閉變更請求的活動。

註：評鑑包括確定變更對專案約束的衝擊（見4.2.4）。

7.10.2 建立變更控制架構

變更控制架構宜定義要使用的變更控制過程和工具。宜通過一套既定的綜合程序（如型態管理）來控制交付物的變更。

7.10.3 識別和評估變更請求

在整個專案中，有必要記錄變更請求，從目標、收益、利害相關者期望、範圍、資源、進度、成本、品質和風險等方面對其進行評鑑，並在實施前評鑑其衝擊並獲得授權。只宜執行授權的變更請求。

註：變更請求的記錄可稱為「變更登記冊change register」、「變更日誌change log」或組織內部使用的任何其他術語。

7.10.4 規劃變更請求實施

如果獲得授權，專案經理宜確定如何實施變更。對現有計劃的變更宜嚴格按照7.2中概述的規劃方法形成新的計畫。在適當情況下，專案經理宜查證相關合約是否仍然適用，如果不適用，則宜在變更合約的活動納入實施變更請求的計畫中（見7.17）。

7.10.5 實施和關閉變更請求

宜根據衝擊評鑑結果，批准、修改、拒絕和推遲變更請求。一旦批准了變更請求，宜將決定傳達給相關利害相關者，適當時更新專案檔案，並實施變更。宜記錄和跟蹤變更請求的狀態，直到其得到實施和關閉。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

專案管理指引（八之六）

 （續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

7 專案管理實務

7.1 概述

此章描述了在整個專案裡宜考慮的專案管理實務，並可在實施第6章所述綜合專案管理實務時使用。

該等實施如圖8所示。

根據專案的前後環節和和所使用的交付方法，該文件中描述的概念和實施的應用可能會因特點專案的側重點而異。

7.2 專案規劃管理

7.2.1 概述

專案規劃管理的目的是定義需求、交付物、產出、成果和約束，並確定如何實現專案目標。在制定專案計畫時，宜考慮不同的解決方案、交付方法和實施方案。

圖 8 專案管理實務與綜合專案管理實務的關聯

7.2.2 制定計劃

在可能的情況下，專案規劃宜作為一種協同活動，團隊成員就團隊的工作計畫提供建議。估計宜佐證說明。專案計畫可以包括：
a) 將可實現的收益（見7.3）；
b) 範圍：要交付的產出和成果（見7.4），同時考慮到品質（見7.11）；
c) 所需資源，如人員、材料、工具和設備以及其他組織（見7.5）；
d) 時間表：何時進行活動（見7.6）；
e) 成本（見7.7）；
f) 專案計畫中固有的風險（見7.8）；
g) 假設和約束。

宜定義活動與其他工作組件（如專案群和專案）之間的依賴關係。專案計畫宜包括並允許進行保證和決策活動。專案計畫可以基於層次結構，顯示每個工作組件在層次結構中的位置，並為工作包和活動分配單點責任。專案計畫宜在不同層級結構的不同級別進行查看，並顯示適合查看計畫者需求的詳細程度。

在專案的整個生命週期中，規劃宜是反覆運算的和漸進的，對於近期的工作比遠期的工作內容更詳細。隨著工作進展，可以細化和澄清範圍，以制定一個在可接受風險水準下交付的專案計畫。專案計畫可以包括當前確定性水準的指標，例如使用某個區間或信賴度指標。

7.2.3 監督計畫

專案計畫宜一致的且整合性。專案計畫宜足夠詳細，從而建立基線。該等基線可以反映專案計畫的任何方面，如要求、範圍、品質、時程、成本、資源和風險。基線計畫的變更宜以可控的方式進行（見7.10）。

一旦獲得批准，宜定期監督和予以分析計畫的基線的進展情況，並將其進行匯報（見7.15）。宜考慮到迄今為止的進展情況和現存的主要假設和風險，對未來活動進行預測。宜審查專案計畫，特別是在重大決策點之前（例如專案關卡）（見4.4）。

7.3 收益管理

7.3.1 概述

收益管理的目的是説明發起組織和顧客從專案成果中實現專案的預期收益，如營運論證案例或其他類似文件所述。如果收益的實現在專案範圍內，則收益宜成為專案計畫的一個組成部分（見7.2）。

專案目標和預期收益宜予以識別、分析、排出優先順序、文件化，並傳達給專案的利害相關者。宜定義計畫活動，以便於監督和控制預期收益。

7.3.2 識別和分析收益

宜在考慮潛在專案時（見6.2）開始識別和分析收益。收益主要由專案發起人與發起組織、利害相關者共同決定。收益宜包含在營運論證案例中，並可在支持文件中進一步詳細說明。專案交付物可以創造產出、組織與社會變革或成果，進而為發起組織或顧客實現收益。

在專案開發了營運論證案例後，專案發起人或其他授權機構，如專案管理委員會（見4.5），宜予以識別、分析、排出優先次序，並決定要實現的一系列更詳細的分項收益。

收益識別和分析宜包括但不僅限於：
a) 識別預期收益，並排出優先次序；
b) 識別預期收益可能產生的負面衝擊；
c) 識別整個專案生命週期內的附加收益；
d) 識別所需的任何組織與社會變革的程度；
e) 為要實現的每項收益識別利害相關者；
f) 使收益與策略目標和其他目標保持一致；
g) 定義績效衡量指標並匯報每項收益；
h) 確定實現收益的時間節點；
i) 查證規畫的產出和成果有可能實現所需的收益。

註：潛在專案在專案前期進行處理（見6.2和圖7）。

7.3.3 監督收益

監督收益包括（但不僅限於）下列事項：
a) 在整個專案生命週期內，監督實現成果的進展情況，以及他們對實現預期收益的衝擊；
b) 收集每項收益的績效量測事項；
c) 匯報和傳達預期收益的狀態。

專案計畫變更可能會衝擊預期收益。專案經理宜告知專案發起人計畫變更（見7.10）可能產生的衝擊。收益可以在專案期間、專案結束時或專案關閉後實現。在專案結束前，未來實現收益的責任（如有的話）宜移交給負責實現當前或未來收益的利害相關者。

7.3.4 維持收益

如果在專案範圍存在與規畫收益的偏差，則宜採取矯正，並在需要時採取預防措施。

7.4 範圍管理

7.4.1 概述

範圍管理的目的是促進交付物、產出和成果的創建，以實現發起組織或顧客的既定目標。範圍管理只允許正式批准的工作納入專案。該範圍宜是專案計畫的一個組成部分（見7.2）。

宜定義範圍（見7.4.2）。宜展開管理活動，以管理範圍的偏差，並確認須交付的範圍。

7.4.2 定義範圍

定義範圍宜明確專案計畫對發起組織或顧客的目標做出的貢獻。在未來決策中，以及在溝通專案的重要性及其目標和收益時，宜將定義的範圍作為一個考慮因素。範圍宜反映需求及其相關驗收準則，並宜隨著工作進展進行細化和澄清。

構成專案範圍的授權工作可以根據專案目標、對照式映射或工作分解式結構予以制定。若適當時，宜進一步詳細說明範圍，並將其分解為工作分解或其他類型的結構中的工作。分解須加以識別、定義和記錄所需的工作，是專案規劃的基礎（參考ISO 21511）。宜商定相關的驗收準則。

7.4.3 控制範圍

控制範圍宜包括當擴大範圍變更（見7.10）時產生最大限度地正向衝擊，及最大限度地縮小負面衝擊。宜將當前範圍的狀態與批准的基線進行比較，以確定任何偏差。控制範圍還宜關注影響範圍變更的因素，並控制該等變更對專案目標的衝擊。範圍變更請求宜以可控的方式進行，並與其他控制域整合在一起（見7.10）。

7.4.4 確認範圍交付

宜根據制定的驗收準則確認構成專案範圍的產出和成果的交付，包括：
a) 查證和確證專案的品質要求和品質標準已得到滿足（見7.11）；
b) 確認發起組織、顧客和其他利害相關者已準備好接收並在適當情況下使用專案的交付物；
c) 管理交付物的移交，以及在相關情況下，從專案團隊到發起組織或顧客的責任移交；
d) 獲得已完成移交的確認。
註：有關專案引起的組織與社會變革的管理，見7.14。

7.5 資源管理

7.5.1 概述

資源管理的目的是確定在品質、數量和最佳使用方面交付專案範圍所需的資源。資源須為專案計畫的一個組成部分（見7.2）。

資源可以包括人員、設施、設備、物料、基礎設施和工具。資源管理宜包括規劃、管理和控制資源，以確定實現專案目標所需的資源品質、數量和需要的最佳化事項。

參與資源管理的人員宜瞭解人力資源管理的關鍵方面，例如：專業能力、經驗、可獲得性、行為和文化方面。資源的需求和屬性，例如資源的來源、所需時間以及開始和結束日期，宜根據需要進行定義、記錄和更新。

由於不可避免的情況，例如設備故障、天氣、勞工騷亂、技術問題或其他工作的競爭性需求，難免可能發生資源可獲得性衝突。此種情況可能需要重新安排活動時程，並可能導致當前或後續活動的資源需求發生變更。宜規劃資源，使其在需要時可以獲得，並包括一個儲備容許量，用於及時干預適當的預防和矯正措施。宜制定程序，以識別重新分配現有資源或徵集額外資源可能導致的風險和問題（見7.8和7.9）。

7.5.2 規劃專案組織

工作中涉及的資源宜根據完成工作所需的角色和責任，進行合理配置。該等責任宜根據具體的專案組織進行定義，該組織可與適當的工作分解層級保持一致（見4.5）。

專案組織可以由各種因素定義和影響，如組織結構、政策、專案環境和專案類型。在規劃專案組織時，宜考慮專案利害相關者的需求、機會和要求。資源的規劃和選擇宜考慮多個因素，例如但不僅限於：內部或外部來源、專業能力、適用性、相關法律要求、參與的期限和時間、日曆、以及發展和訓練要求。

7.5.3 組建團隊

組建團隊包括獲取所需資源，並為他們提供展開工作的指導。宜確定工作地點、承諾、角色和責任，以及匯報要求。專案經理宜確定如何以及何時需要獲得專案團隊成員並將其分配到專案，以及如何及何時將他們從專案中釋放出去。在某些情況下，專案經理可能無法完全控制專案團隊成員的選擇。在相關情況下，工作包負責人宜參與選擇分配到其工作包的專案團隊成員。

通常宜在每個專案階段或工作包開始時成立一個團隊。如有必要，宜重新評鑑和調整團隊組成。在組建團隊時，專案經理宜考慮技能、專業知識、文化、成本和團隊動力等因素。

當組織內未獲得合適的資源時，宜考慮雇傭或資源外包（見7.17）。

7.5.4 開發團隊

開發團隊旨在幫助團隊成員以一種有凝聚力和協作性的方式共同工作。這種開發過程取決於專案團隊的專業能力，並可能需要以持續的方式提高團隊成員績效和互動，以增強團隊合作、動力和績效。

宜在專案早期制定可接受行為的基本規則，以儘量減少誤解和衝突。宜識別能力差距，並通過適當的訓練、輔導和其他舉措來彌補，包括採取措施提高團隊動力和職業成長。

7.5.5 管理團隊

管理團隊的目的宜是激勵團隊，保持積極的工作環境，讓團隊成員產生參與感，表現出最佳狀態並專注於他們分配的工作和專案目標。專案經理宜通過提供回饋、解決個人糾紛和鼓勵合作來最佳化團隊績效。

當發生衝突時，宜酌情採取適當的領導作為和管理風格，包括談判、自信、同理心和循證決策。

必要時，宜更新或修訂資源需求，提出並解決問題，如果超出專案經理的職權，則宜向上級反應。

宜收集資訊，作為人員績效和經驗教訓的輸入。如適用時，宜與工作包負責人、專案經理、專案發起人和個人直屬經理協商，進行團隊和個人評估及績效監督。

7.5.6 規劃、管理和監督實物資源

實物資源的可獲得性和使用宜進行規劃、管理和控制。為此，專案經理和團隊宜根據資源的可獲得性和專案要求，考慮和權衡最佳的「成本-收益」解決方案。物料、設備、設施、實驗室和工具等實物資源宜根據關鍵性、成本、可獲得性和交付週期等因素進行規劃。此種資源規劃通常宜與資源規劃、能力和預算相協調。

設備和物料資源的管理宜與專案時程（見7.6）相互協調，並考慮潛在的衝突情況，如不能獲得和未能交付的風險。宜考慮備用資源和資源配置。

宜檢查資源的績效和生產力，以及正在（或可能）實現目標的程度。必要時宜採取預防和矯正措施。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理—專案管理指引

（未完，見續篇）

專案管理指引（八之五）

（續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

6.6 控制專案

6.6.1 概述

控制專案（包括階段和工作包）的目的是根據商定專案計畫（含經授權的變更）來監督和衡量專案績效。專案經理宜以專案的初始規劃（見6.5.5）為基礎，增加設計和開發的活動、產出和成果的詳細資訊，並根據需要反映授權變更（見7.2）。

註：專案經理在控制專案方面的角色見4.5.6。

6.6.2 持續佐證說明

隨工作的進行，可以在專案多個階段針對不同的備選方案進一步佐證說明專案的理由。宜與專案發起人協商，更新營運論證案例，以反應專案前後環節和範圍的變化，然後在每個關卡或決策點確證是否繼續專案。

6.6.3 管理專案績效

專案經理宜在專案團隊的支持下，定期審查所要求的產出和成果，以達到要求。專案經理宜監督和查證專案團隊在承擔專案計畫中分配給他們的工作方面的績效，以便：

a) 將專案團隊的工作整合到後續的專案工作中；
b) 確定專案可能在可接受的風險水準內交付所要求內容，並建議和做出獲得授權且管制下的變更。

專案經理宜收集和分析進展和績效資料，以評估專案計畫相關的進展，包括：
—已完成的工作，實現的里程碑和產生的成本（見7.2）；
—計畫著或實現出的收益（見7.3）；
—管理著範圍（見7.4）；
—獲去足夠的資源來完成工作（見7.5）；
—管理進度和成本（見7.6和7.7）；
—識別和管理風險和問題（見7.8和7.9）；
—管理變更控制（見7.10）；
—工作品質（見7.11）；
—計畫和預測的利害相關者參與和溝通狀況（見7.12和7.13）；
—管理專案產出至發起組織或顧客的過渡，並為組織與社會變革做好準備和管理（見7.14）；
—匯報進展情況（見7.15）；
—保持資訊和文件的完整性和可用性（見7.16）；
—管理採購活動的狀況（見7.17）；
—總結新學習到的經驗教訓（見7.18）。

專案經理宜向專案發起人、專案團隊和選定的利害相關者提供一份與專案計畫一致的專案狀態和績效報告（見7.15）。宜包括對專案未來績效的預測。

專案經理宜管理專案內的各種技術性、行政支援和組織性活動及其介面。

宜記錄並實施預防和矯正措施，並在必要時提出和實施變更請求（見7.10），以使專案保持標的，繼續實現專案目標。

6.6.4 管理各個階段的啟動和關閉

在工作包領導人或其他主題專家的協助下，專案經理宜通過以下方式為專案每個階段的開始做好準備：
a) 準備或審查該階段的詳細計畫；
b) 審查治理和管理要求；
c) 與專案發起人確認專案仍然合理；
d) 修訂管理方式，以反映該階段所需的工作；
e) 獲得開始下一階段的授權。

一旦獲得授權開始該階段，專案經理宜調動團隊和其他資源並開始工作。

專案經理宜確認專案各階段的完成情況，包括但不僅限於：
—確認已完成的、遭到取消的或是暫停的採購；
—查證任何不完整的措施並記錄未解決的問題；
—釋放或轉換資源（如果不再需要）；
—根據組織的資訊歸檔政策，歸檔資訊和文件；
—查證已完成、已交付和已接受的產出和成果；
—記錄學習到的經驗教訓。

6.6.5 管理每個工作包的啟動、進展和關閉

專案經理宜通過以下方式照料著每個專案階段的工作包：
a) 在確保每個工作包的計畫和各個階段的整體計畫一致並整合後，對其進行查證和批准；
b) 確保工作包之間的整合工作和交付物得到規劃和實施，且達到要求；
c) 將每個工作包責任分配給工作包負責人；
d) 根據專案計畫或針對風險或問題啟動工作包；
e) 查證工作進展，包括解決任何風險、問題或變更請求；
f) 查證交付物的品質；
g) 確認工作包的完成、交付和關閉。

6.7 管理交付

管理交付的目的是確定所需的產出和成果，並計畫和實施其交付，以實現專案的成果和收益。

專案的工作組織成工作包，用於分配和控制各個團隊進行的工作。工作包宜分配給工作包負責人（見

4.5.8）。宜適當定義、規劃、監督和控制工作，宜積極管理品質。在專案環境中，工作方法和流程須

適合使用，以最大限度地提高成功的可能性。工作包負責人須按照第7章中制定的做法，根據專案批准的計畫，監督、測量和控制分配的工作。宜採取預防和矯正措施，並在必要時提出變更請求，以實現制定的工作目標。

工作包負責人宜通過（但不僅限於）以下交付管理其工作包的交付：
a) 規劃分配的工作包（見7.2至7.7）；
b) 動員團隊；
c) 處理風險、問題、變更請求和利害相關者的意見（見7.8、7.9、7.10和7.12）；
d) 管理供應商（如有的話）（見7.17）；
e) 使用適當和相稱的方法和技術開發所需的產出（見7.11）；
f) 查證和確證交付物；
g) 讓專案經理瞭解進度、升級式的風險、問題以及決策和指導請求（見7.15）；
h) 獲得和應用經驗教訓（見7.18）；
i) 一旦經專案經理確認工作包已完成，立即關閉工作包（見6.6.5）；
j) 維護所展開工作的記錄（見7.16）。
注1：有時輸出被稱為「資產assets」（見ISO 55000）。
注2：工作包負責人在管理交付方面的角色見4.5.8。

6.8 關閉或終止專案

關閉專案的目的是確定專案範圍的完成，在終止情況下關注未完成的活動，使專案後的收益得到實現，並管理剩餘資源和設施的遣散。在關閉專案之前，如果不是由於終止而導致時，則宜查證所有活動的完成情況，以確認該專案範圍已經完成，並且每個工作包已完成或是終止。同樣地，在適用的情況下，宜商定並接受任何剩餘的營運責任。

如果專案是專案群或專案組合的一部分，則宜將未完成的措施之跟蹤、風險和問題的責任移交給專案群經理或專案組合經理。如果專案不是現有專案群或專案組合的一部分，則宜確定是否將不完整的措施、風險和問題移交給適當的管理權責機構或其他指定人員，以進行後續的跟蹤和管理。宜審查為實現部分專案範圍而建立的所有合約，查證其狀態，並在適當情況下將其正式關閉（見7.17）。

專案經理宜與專案發起人、關鍵團隊成員和利害相關者進行諮商，進行審查關閉過程。審查關閉宜根據計畫評鑑績效，以及達到目標的程度。該審查宜正式記錄下來，正式文件化宜作為授權專案關閉的依據。專案發起人宜就任何關閉後審查的職權範圍和時間達成一致。

宜審查從整個專案學習到的經驗教訓，包括在類似專案和未來其他專案的管理中宜考慮的改進建議（見7.18）。此類審查可以是任何正式關閉審查的一部分，也可以作為單獨的活動進行。

宜告知利害相關者關閉的情況。宜採取措施，以實現專案產出的移交，並在移交期間任何相關的組織與社會變革管理措施，包括實現的收益。還宜採取措施，以實現持續性的收益。

在專案完成之前，專案發起人或發起組織可能會因為以下原因終止專案，包括但不僅限於：
a) 不再需要該專案或不再可行；
b) 與其相關的風險高到無法接受的程度；
c) 外部顧客不再需要專案產出。

除非存在特殊原因，否則終止專案宜包括與完成專案類似的活動，即使可能沒有要發佈最終的結果。

在專案終止的情況下，宜採取以下措施：
—確認並記錄已完成的活動，包括供應商所進行的活動；
—記錄未完成的活動；
—確認宜移交給顧客的交付物；
—確認並記錄顧客接收（或拒絕）已確定需要移交的交付物；
—記錄工作包的狀態；
—按照現行的組織政策，收集和歸檔專案檔案（見7.16）；
—釋放專案資源和設施；
—就任何持續的營運責任達成一致；
—根據需要關閉或終止工作令與合約。

註：專案經理在關閉或終止專案方面的角色見4.5.6。

6.9 專案後活動

專案後活動之目的是查證專案成果是可持續的，預期的收益已經實現。

凡屬專案群或專案組合，或某些需要結束後活動的專案，則專案發起人宜執行審查，以確定專案的成功程度，包括：
a) 達到既定目標；
b) 實現收益；
c) 實現組織或社會變革或成果，例如營運績效；
d) 實現可持續的變革，包括繼續滿足營運論證案例中設定的期望事項。

收益和組織與社會變革可能包括在專案範圍內，也可能不包括在專案範圍內。
宜吸取和交流學習到的經驗教訓（見7.18）。
註：發起組織在專案後活動的角色見4.5.2。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

專案管理指引（八之四）

 

（續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

5 專案管理必要條件

5.1 概述

所有組織都以正式或非正式的方式展開專案管理工作。在建立實施、維護和改進專案管理環境之前，組織宜考慮各種必要條件。此種環境有時被稱為「專案環境project environment」或「專案管理環境project management environment」。專案管理環境因組織而異。

組織內正式實施專案管理前，宜評鑑以下內容：
a) 現有和未來專案的類型、規模、重複率和複雜性；
b) 對組織的積極和消極衝擊，包括對組織的策略目標、願景、使命和其他方面的衝擊；
c) 為籌建實施專案管理的組織，包括人力資源需求和必要的組織結構、系統和流程變更；
d) 對顧客和其他利害相關者的衝擊。

5.2 實施專案管理的注意事項

根據組織或社會變革的規模和複雜性，專案管理在組織內的正式實施宜作為專案、專案群或專案組合的一部分進行管理。在考慮專案管理方法的正式實施時，組織宜考慮但不僅限於以下因素：
a) 識別出的正式專案管理需求和收益；
b) 整合其他相關工作並與策略和業務目標保持一致的能力；
c) 在組織治理、結構和文化內實行必需變革的容量；
d) 組織實施變革的資源能力，包括（但不僅限於）人力資源和預算；
e) 對內外部利害相關者的潛在衝擊；
f) 跨越組織之間區隔邊界的工作能力；
g) 將來專案方法實施時所需專業能力的可獲得程度；
h) 對組織內正在進行和計畫的活動的預算、已識別的風險、進度和要求的衝擊。

實施正式專案管理的營運論證案例，宜遵循4.3.2規定的指導內容。

5.3 專案管理環境的持續改進

執行階層和高階管理階層宜營造持續改進的環境和文化，以查證和維持組織內專案管理的持續適宜性、充分性、有效果性和有效率性。必要時，宜展開促進持續改進的活動，活動宜包括（但不僅限於）：
a) 建立組織專案管理架構的評估過程，重點查證與組織策略、業務和營運目標的一致性，以及總結和吸取經驗教訓的程度；
b) 評估專案管理架構和治理的有效性；
c) 實施識別出並經過協議同意的改進；
d) 實施已確定和議定的改進措施，及須要實施的調整事項；
e) 為當前和未來的專案收集和吸取經驗教訓；
f) 通過教育、訓練和輔導，培養員工的專案管理技能。

專案管理過程評估可以為組織提供資訊，以持續改進專案管理架構、方法和技巧，並可與5.4識別出來的架構結合使用。

資深管理階層、品質保證職能部門或專案辦公室(見4.5.7) 宜制定定期評估的時間表和方法，定期評估宜：
—促進專案管理過程、方法和技巧的持續改進，並定期評估組織內的專案管理成熟度；
—包括與受變革影響的人就如何在組織內進行專案管理進行溝通。

作為採行任何評估的一部分，宜諮詢專案發起人、專案經理及其團隊。

5.4 與組織流程和系統保持一致

專案治理架構宜與其他組織流程和系統保持一致，包括但不僅限於：
a) 組織治理；
b) 績效報告；
c) 適用程序和相關的交付方式；
d) 風險管理；
e) 專案組合和專案群管理；
f) 投資和財務管理；
g) 業務分析、策略和營運規劃；
h) 資訊與文件化管理；
i) 品質管制。

在協調專案管理實務和系統時，還宜考慮以下內容：
—職能和實體組織結構或其他主流結構；
—衝突的程式、流程、計畫和系統；
—溝通方式和週期；
—技術的可獲得性和獲取；
—組織營運前後環節；
—社會、經濟和環境特徵的平衡化與最佳化；
—行政支援和授權系統；
—可持續性和監督要求。

6 綜合專案管理實務

6.1 概述

綜合專案管理實務宜覆蓋專案實施時使用的實施，從專案前活動到專案啟動決策，從規劃和控制活動到專案後活動。此章識別展開專案，各個階段和其他專案活動或活動組時宜使用推薦的專案管理實務。此章實施借鑒了第4章所述的概念。

將第7章中識別的專案管理實務整合和調整為管理專案工作的統一方法，可能是專案成功的關鍵。

綜合專案管理實務的目的是使組織能夠：
a) 實現專案目標；
b) 在約束範圍內定義和管理專案範圍，同時考慮風險和資源需求；
c) 從每個參與和執行的組織中獲取支援，包括資源所有者、發起人、供應商、顧客、使用者和其他利害相關者的承諾。

管理專案宜採用整合型方法，考慮影響專案成功的各種因素，例如：各項角色、紀律、能力以及組織和環境因素。綜合專案管理實務宜與其他實施保持一致並相互關聯，如圖4所示。

專案管理方法的剪裁和應用，宜考慮到組織的需求、現行的風險水準、相關人員的能力以及專案的其他特殊性。宜根據相關組織政策對第6章和第7章的實施進行剪裁和應用。組織政策和專案管理實務之間的衝突宜與專案發起人協商解決。

整合型專案管理實務如圖7所示，包括專案前和專案後的活動。各項活動和相關角色之間的關係（見4.5）。6.2到6.9詳細描述了各項實務。

圖 7 整合型專案管理實務、關係和相關角色概覽

6.2 專案前活動

專案前活動的目的是發起組織查證該專案是否值得啟動。專案前活動是指在決定啟動專案之前須完成的活動。宜評估組織策略或業務需求產生了已識別出來的需求和機會，使資深管理階層能夠，例如組織管理、專案組合管理或專案群管理，以確定可以將部分或全部需求和機會轉化為實現收益的潛在專案。例如，該等需求和機會可以專注在新的市場強烈需求、當前的組織需求或新的法律要求。在正式授權啟動新專案之前，宜對需求和機會進行評估（見4.3.2）。

專案的目標、收益、合理性和投資進行佐證並詳細記錄，以便能夠決定是否啟動專案。此類文件可以用於確定需求和機會的優先順序排序。此種優先順序劃分可能涉及：
a) 組織策略或商業計畫的某些面向；
b) 更高層級的專案群或專案組合的需求；
c) 顧客的需求。

佐證說明的目的是獲得組織對所選中的專案投資之承諾和授權，同時瞭解其約束、風險和假設。

註：啟動專案的佐證說明可以在文件中定義，如職權範圍（terms of reference）、簡報、提案或初步營運論證案例（見4.3.2）。

宜進行評估，以確定專案是否宜於在組織、專案組合或專案群層面進行。此種評估宜基於多種準則，如定量、定性和財務準則、對齊組織策略、可持續性以及社會和環境衝擊。不同的組織、專案組合、專案群和專案的準則可能會有所不同，具體取決於面對的前後環節。

在授權啟動專案之前，發起組織宜：
—識別專案發起人和專案經理，並確定其最初的責任和職權；
—制定初步的治理安排；
—決定組織是否有資源和準備資金用於整個專案，或者至少用於第一階段，並相信可以隨著專案進展而獲得額外的資金進行其餘專案部分。

6.3 觀察專案

觀察專案的目的是發起組織確信專案團隊有能力實現專案目標，該專案仍然滿足組織的需求和專案利害相關者的期望，並且專案風險處於可接受的水準。

照管專案可以經由以下方式為之：
a) 參與關鍵決策；
b) 定期匯報；
c)保證性的審查和稽核；
d) 臨時地知會上一層級和及時干預。

儘管許多決策可以委派給專案發起人，但發起組織的高階管理者通常更適合保留一些決策。受專案外部因素（例如：經濟、社會和環境可持續性，以及資金或資源的可用性）影響的決策，只能在更高階層的位置做出決策，因為它們會衝擊其他專案和工作。發起組織宜隨時向專案發起人通報專案的最新前後環節情況，根據需要或要求提供指導和方向。發起組織宜使專案發起人有足夠的時間來有效地履行責任。

註：發起組織在照料專案方面的角色，見4.5.2。

6.4 指導專案

指導專案的目的是使專案在組織前後環節中持續具有相關性和客觀佐證。

在專案委員會的支持或照看下，專案發起人宜確定：
a) 組織的需求正獲得關注，願景和目標正在與策略假設相互溝通，並已制定衡量專案成功與否的準則；
b) 如果組織治理有要求，則該專案須持續加以客觀佐證，且營運論證案例須持續更新；
c) 就產出、成果和預期收益而言，解決方案達到組織的需求；
d) 採用適宜及具備專業能力的資源；
e) 當組織的客觀佐證未足以支撐時，專案即須終止。

註：專案發起人和專案委員會在指導專案方面的角色分別見4.5.4和4.5.3。

6.5 啟動專案

6.5.1 概述

啟動專案的目的是規劃專案、定義專案組織、動員專案團隊、定義專案治理和管理、識別利害相關者並查證專案的客觀佐證。宜考慮相關專案的經驗教訓。該等活動可以反覆運算，直到制定出可接受的解決方案和計畫為止，並可以在專案的後續階段進一步反覆運算。

注1：「啟動專案initiating a project」也可以稱為「開始專案starting a project」或「專案初始化project initiation」。

注2：在啟動專案方面專案經理的角色見4.5.6。

6.5.2 動員專案團隊

專案經理宜調動該專案所需的團隊、設施、設備和其他資源。專案團隊宜瞭解他們的角色以及專案的要求、假設、約束和潛在風險。專案工作宜在跨職能團隊中進行，並分配給有專業能力完成角色並有能力容量交付預期成果的人員。更多資訊見7.5。

6.5.3 專案治理和管理方法

宜定義治理和管理架構，為參與專案的個人提供指導和工作方法。治理和管理架構以及控制措施宜與要完成的工作及其預期的複雜性相稱和適當。

專案經理宜諮詢專案發起人，定義出專案啟動、指導、監督、控制和關閉的方式，同時符合治理要求（見4.3）。通常，這包括：
a) 專案生命週期（見4.4）；
b) 專案組織、角色和責任（見4.5）；
c) 第6章和第7章描述的進行管理活動的過程和方法；
d) 交付專案產出和成果的過程和方法（見6.7）。

專案管理方法可用一份文件、含一組輔助文件的總文件檔、或涵蓋特定實施（如風險或品質管制計畫的一組輔助文件予以描述（參考ISO 21505）。

註：專案管理方法文件的名稱可能有所不同。例如「專案管理計畫project management plan」、「專案啟動文件project initiation documentation」、「專案定義文件project definition document」、「項目實施計畫project implementation plan」、「專案章程project charter」、「專案職權範圍project terms of reference」等。具體專案管理實務的文件有時被稱為「管理計畫management plans」，例如「風險管理計畫或策略risk management plan or strategy」、「品質管制計畫或策略quality management plan or strategy」、「範圍管理計畫或策略scope management plan or strategy」。

6.5.4 初步專案佐證說明

專案啟動的佐證說明宜建立在專案前活動（見6.2）的初步查證基礎上，進一步深化專案佐證說明。該佐證說明宜記錄在營運論證案例中（見4.3.2）。營運論證案例可以隨著工作的展開，在多個專案階段中進行開發並更新營運論證案例，以反映專案前後環節和範圍的重大變化。

營運論證案例宜證明在可接受的風險水準內，與組織策略、財務可行性、商業活性和可交付的實用性相匹配。宜評鑑要採取的方法和選擇的解決方案的備選方案，並給出拒絕的理由。如果專案是專案群的一部分，則其營運論證案例可以包含在該專案群的營運論證案例中。

註：佐證說明專案實施的文件通常稱為「營運論證案例business case」，但實際使用的名稱可能因行業或使用的方法而有所不同。

6.5.5 初步專案規劃

專案的初步規劃宜根據專案生命週期制定里程碑、關卡或決策點，並至少結合專案的當前階段的詳細計畫。如果將過渡階段視為專案的一部分，則宜考慮將專案產出過渡至營運或顧客。在專案的早期階段，可形成多個備選方案，在專案後續階段進一步開發（見7.2）。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

德國巴伐利亞邦高科技議程（Hightech Agenda Bayern）概況（六之二）

（續前篇）

適合一般科技技術界。此文僅供個人參考與資訊喚回，尚非標準或官方內容。內文引用人工智慧平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱德國的巴伐利亞邦官方網站。 CC BY-SA 4。0。

乙：未來醫學的「人工智慧AI輔助診斷」與「醫療機器人」：

在德國巴伐利亞高科技議程（Hightech Agenda Bayern）中，「AI輔助診斷」與「醫療機器人」是「未來醫學（Medicine of the Future）」領域的核心策略。該議程總計投資超過 55億歐元，透過跨區域的「巴伐利亞AI生態系（Baiosphere）」將全邦打造成全球頂尖的醫療科技重鎮。

以下詳細解析慕尼黑（Munich）與紐倫堡-埃爾朗根（Nuremberg-Erlangen）兩大核心雙子星節點的分工、重點技術與具體應用：

一、 慕尼黑節點（Munich）：智慧醫療機器人與前沿手術整合

慕尼黑在巴伐利亞AI網路中被指定為「智慧機器人（Intelligent Robotics）」的中心，其核心目標是將AI、先進感知與機械手臂結合，直接應用於臨床手術與照護。
核心科研機構：

• 慕尼黑工業大學（TUM）及其附屬醫院（Klinikum rechts der Isar）。
• 慕尼黑機器人與機器智能研究所（MIRMI）。
• 慕尼黑大學（LMU）醫院與亥姆霍茲慕尼黑中心（Helmholtz Zentrum München）。

重點發展領域與具體項目：

1. ForNeRo 醫療機器人專案：由 TUM 領銜的 ForNeRo 研究計畫 獲得巴伐利亞研究基金會200萬歐元資助。該項目專注於將多元化的手術機器人系統與即時醫療影像（如術中 CT、MRI）進行無縫整合，讓機器人能在外科手術中提供極高精準度的輔助，減少人為失誤。

2. 微型與奈米醫療機器人（Nano and Microrobotics）：利用高科技議程增設的專屬教授席位，研發利用「DNA摺紙技術」製成、病毒大小的奈米機器人。未來這些微型機器人可進入人體血管，將藥物精準傳送至腫瘤部位，或在微觀層面進行細胞修復。

3. 大廠生態系協同：與總部位於慕尼黑的數位醫療大廠 Brainlab 密切合作，將影像引導手術（Image-guided surgery）軟體與硬體機器人深度結合，推動技術的快速臨床商品化。

二、 紐倫堡-埃爾朗根節點（Nuremberg-Erlangen）：AI 醫療診斷與數位健康樞紐

紐倫堡與鄰近的埃爾朗根共同構成了國際著名的「醫療谷（Medical Valley）」，在巴伐利亞高科技議程中被官方指定為「健康 AI 節點（Health Node）」。這裡側重於大數據、機器學習演算法以及智慧感測器的醫療診斷應用。
核心科研機構：

• 埃爾朗根-紐倫堡大學（FAU）：設立了專門的「生物醫學工程人工智慧學系（AIBE）」。
• 紐倫堡技術大學（UTN）：新創立的現代化大學，主力研發 AI 基礎模型。

重點發展領域與具體項目：

1. AI4health 診斷與影像研究：FAU 的 AIBE 學系 專注於開發「AI 輔助醫學影像診斷」。透過深度學習演算法分析 X 光、電腦斷層（CT）與核磁共振（MRI）影像，AI 能在幾秒鐘內識別出早期癌症細胞、心肌梗塞徵兆或腦中風病變，輔助醫生避免肉眼漏診。

2. 巴伐利亞 AI 基礎模型倡議（Bavarian AI Foundation Model Initiative）：由 UTN 領銜的跨學科倡議，正在開發醫療專用的「多模態大模型」。此模型能同時整合並分析病患的臨床病歷、基因數據、生物訊號與醫學影像，實現極度客製化的「個人化精準醫療」預測與療程規劃。

3. 數據整合中心與在地產業優勢：埃爾朗根大學醫院建立了數據整合中心，將區域醫療網路的病患數據結構化去隱私整合。更重要的是，全球醫療設備巨頭西門子醫療（Siemens Healthineers）總部位於此地，與學術界直接對接，讓智慧感測器與遠距醫療診斷系統能迅速落地。

三、 兩大城市的協同效應與未來願景

巴伐利亞高科技議程並非讓兩地孤立競爭，而是透過互補建立密不可分的「強強聯結」：

評比維度	慕尼黑（Munich）	紐倫堡-埃爾朗根（Nuremberg-Erlangen）
官方策略定位	智慧機器人與感知中心	醫療健康 AI 中心
核心優勢技術	手術機器人整合、奈米機器人、照護自動化	醫學影像 AI 識別、多模態大模型、智慧感測器
代表性企業夥伴	Brainlab、羅氏製藥（Roche）	西門子醫療（Siemens Healthineers）

願景總結：

這項龐大的科技投資旨在應對高齡化社會帶來的醫療資源短缺。透過紐倫堡開發的「超強大腦（AI 診斷演算法）」 與慕尼黑開發的「精準雙手（醫療機器人）」 相結合，巴伐利亞邦試圖建立一個從早期篩檢、精準診斷到自動化手術與術後照護的完整全自動化數位醫療鏈，保持其在歐盟乃至全球醫療科技市場的「冠軍聯賽（Champions League）」領先地位。

丙：醫療健康的「健康AI節點」與「醫療谷」

在「巴伐利亞高科技議程（HTA）」策略下，紐倫堡-埃爾朗根的「健康AI節點」與「醫療谷（Medical Valley）」深度融合，與慕尼黑的「智慧機器人中心」共同構成了德國最頂尖的數位醫療網路。

以下詳細梳理這兩個核心區域在微型機器人、AI4health、AI基礎模型以及 ForNeRo 專案中的重要研究方向、主導大學、核心教授及其生平與學術成就：

💡 核心總覽與快速檢索
紐倫堡-埃爾朗根（健康AI與醫療谷樞紐）
微型與奈米醫療機器人：[FAU 埃爾朗根-紐倫堡大學] Prof. Dr. Franziska Mathis-Ullrich
AI4health 診斷演算法與臨床實踐：[FAU] Prof. Dr. Florian Knoll & Prof. Dr. Bernhard Kainz
巴伐利亞 AI 基礎模型倡議：[UTN 紐倫堡技術大學] Prof. Dr. Wolfram Burgard（共同總主持人）
慕尼黑（智慧機器人與前沿手術中心）
ForNeRo 手術機器人整合計畫：[TUM 慕尼黑工業大學] Prof. Dr. Dirk Wilhelm（臨床與機器人主導） & [LMU 慕尼黑大學] 跨學科團隊

一、 紐倫堡-埃爾朗根節點：頂尖科學家與科研重點

1. 微型與奈米醫療機器人（Nano- und Mikrorobotiks）

承辦機構：埃爾朗根-紐倫堡大學（FAU）人工智慧生物醫學工程學系 (AIBE)
領進/主導教授：Prof. Dr. Franziska Mathis-Ullrich（手術規劃與機器人認知教授）
學者履歷：她是醫療機器人領域的青年領軍學者。博士畢業於全球頂尖的蘇黎世聯邦理工學院（ETH Zurich）多尺度機器人研究所（MSRL），導師是微型機器人泰斗 Bradley Nelson。隨後在卡爾斯魯厄理工學院（KIT）擔任終身軌教授，並於巴伐利亞高科技議程（HTA）啟動後，獲重金延攬至 FAU AIBE 學系。
科研成就與重點：她專注於「微創與奈米手術機器人」的感知與智慧控制。其研究重點是開發能夠進入人體血管、眼球或微小器官深處的磁控微型機器人，透過 AI 演算法精準預測人體組織的形變，從而實現自動化的微觀藥物遞送與精細手術。

2. AI4health 診斷演算法與臨床實踐（AI4health Algorithmen und Praxis）

承辦機構：FAU AIBE 學系 結合埃爾朗根大學醫院（Universitätsklinikum Erlangen）
領進/主導教授：
Prof. Dr. Florian Knoll（計算影像學教授）
學者履歷：奧地利格拉茲科技大學博士，隨後任職於美國紐約大學（NYU）朗格尼醫學中心（Langone Health）放射學系副教授，是全球醫療影像 AI 的一線權威，後透過 HTA 計劃受聘回德國。
科研成就：他引領了「快速核磁共振（Fast MRI）與 AI 重建」的革命。利用深度學習，他的演算法能將 MRI 的掃描時間縮短高達 4 倍以上，且重建出的醫學影像比傳統方式更清晰，大幅降低病患在儀器內的幽閉恐懼與檢查成本，目前該技術已與西門子醫療（Siemens Healthineers）深度整合落地。
Prof. Dr. Bernhard Kainz（醫學影像探索與分析教授）
學者履歷：曾任英國倫敦帝國學院（Imperial College London）終身制副教授，並於 2021 年起加入 FAU AIBE 學系。
科研成就：專精於即時臨床影像分析與安全 AI（Safe AI）。他開發的演算法主要應用於即時超音波引導與胎兒醫學影像識別，讓非資深醫生也能在 AI 輔助下精確診斷複雜的先天性疾病。

3. 巴伐利亞 AI 基礎模型倡議（Bavarian AI Foundation Model Initiative） 

承辦機構：紐倫堡技術大學（UTN）計算科學與人工智慧學系（CSAI） 
領進/主導教授：Prof. Dr. Wolfram Burgard（UTN 創系主任 / AI 與機器人講座教授）
學者履歷：全球人工智慧與自主機器人領域的殿堂級宗師。他是波昂大學博士，曾長期任教於弗萊堡大學，是德國科學院（Leopoldina）院士、IEEE Fellow 及 AAAI Fellow。他在機率機器人學（Probabilistic Robotics）上的奠基性著作是全球機器人科學家的必讀聖經。2022 年被特聘為新建紐倫堡技術大學（UTN） 的創始學系主席。
科研成就與重點：Prof. Burgard 與慕尼黑大學（LMU）的 Björn Ommer 教授（Stable Diffusion 創始人）共同出任「巴伐利亞 AI 基礎模型倡議」的科學總協調人。在健康節點中，他帶領團隊研發歐洲自主、多模態（Multimodal）醫療基礎大模型。這個模型能同時吃進病患的病歷、基因組學數據、生物訊號與高維度 3D 醫學影像，打破傳統單一診斷的藩籬，進行全方位的疾病預測。

二、 慕尼黑節點：手術室未來的開拓者

ForNeRo 手術機器人整合計畫（Seamless and ergonomic integration of robotics into clinical workflow）
承辦機構：慕尼黑工業大學（TUM）機器人與機器智能研究所（MIRMI） 與 人機工程學系
領進/主導教授：Prof. Dr. Dirk Wilhelm（TUM 醫療機器人學講座教授 / 微創手術資深外科主治醫師）
學者履歷：身兼雙重頂尖身分——他既是 TUM 醫學院附屬右岸醫院（Klinikum rechts der Isar）的資深外科醫生，也是高科技議程資助下設立的 TUM 醫療機器人學系主任。這種「醫工結合」的背景使他成為將實驗室技術帶入手術室的最佳人選。
科研成就與重點：他是巴伐利亞研究基金會資助的 ForNeRo 核心計畫主持人。
計畫細節與落地：ForNeRo 著眼於解決現代手術室的痛點——過去機器人體積龐大且與醫生流程脫節。Prof. Wilhelm 團隊在實驗手術室中，將多臂手術機器人（如 MIRO 系統與新興的 Neura Robotics 手術臂）與先進的感知環境（Sensory environment）和 AI 整合。AI 能自動識別當前的手術步驟、預判醫生拿取哪種手術刀、辨識被操作的器官，並在不干擾醫生的情況下主動調整機器人手臂的位置。該項目與 LMU 醫院及產業界巨頭 Karl Storz（內視鏡大廠）深度協同，大幅提升手術的流暢度與人體工學舒適度。

三、 總結：兩地在巴伐利亞 AI 生態系中的協同聯動

在巴伐利亞的整體佈局中，這幾位教授所主持的項目形成了一個強大的閉環：
紐倫堡（UTN - Burgard）開發底層的「醫療多模態大模型」，提供全邦醫院最強大的人工智慧運作大腦；
埃爾朗根（FAU - Knoll / Kainz / Mathis-Ullrich）利用這套大腦進行超快速的影像 AI 診斷和精準的血管內微型機器人控制；
慕尼黑（TUM - Wilhelm）則將這些診斷數據和 AI 實時感知能力，無縫裝載進大型手術室的機器人（ForNeRo）中，直接輔助外科醫生完成高難度手術。

這種由「巴伐利亞高科技議程」以數億歐元打造的頂級陣容，正是該區域成為全歐乃至全球醫療科技（MedTech）領頭羊的核心底氣。

參見：Bavaria High Tech Agenda (網站： www.hightechagenda.de/)

（未完，見續篇）

德國巴伐利亞邦高科技議程（Hightech Agenda Bayern）概況（六之一）

適合一般科技技術界。此文僅供個人參考與資訊喚回，尚非標準或官方內容。內文引用人工智慧平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱德國的巴伐利亞邦官方網站。 CC BY-SA 4。0。

概述：

🏛 計畫背景

2019年10月，巴伐利亞邦長索德爾（Markus Söder）在邦議會的施政聲明中，正式宣告啟動《巴伐利亞高科技議程》。

簡單說，這是一套由巴伐利亞（德Bayern，英Bavarian）邦政府主導、以技術創新驅動未來競爭力的「國家級投資計畫」。

💰 投資規模

巴伐利亞邦透過此計畫，總計投入約55億歐元，打造一場獨一無二的科技攻勢。
這個數字放在德國地方邦的層級，是相當罕見的豪賭，約略等同於台灣某些年度科技預算的規模。

🎯 六大核心主題領域

計畫聚焦於七個攸關未來的生活領域：

主題	內容
未來交通	自動駕駛、Hyperloop等新型移動技術
醫療健康	AI輔助診斷、醫療機器人
智慧城市	都市數位化、智能社區管理
高齡自主生活	輔助機器人、老年照護科技
能源安全	核融合研究、再生能源穩定供應
未來職場	新型態工作與創業生態系
農村振興	讓科技紅利普及至非都市地區

 

🔬 重點科技投資

人工智慧 在巴伐利亞各大學中設置了100個AI相關教席，以慕尼黑為機器人核心，並在維茨堡Würzburg （數據科學data science）、埃爾朗根-紐倫堡Erlangen-Nürnberg（醫學medicine, health）、因戈爾施塔特Ingolstadt （移動mobility）設立節點。

量子計算 加興的萊布尼茲計算中心（LRZ Leibnizrechenzentrum）被規劃成歐洲量子電腦quantencomputer的頂級基地，量子處理器將整合進超級電腦系統。2026年5月，歐洲首台量子電腦（Euro-Q-Exa）已在此正式啟動。

核融合 Nuklearfusion巴伐利亞聯合漢堡Hamburg、薩克森Sachsen等六個德國邦，成立核融合研究聯盟，目標是推動核融合從研究走向實際電廠應用。

👩‍🏫 人才策略：最重要的一環

高科技議程新增1,000個教授職位與13,000個學位名額，其中許多集中於AI與超級科技領域。
更特別的是「頂尖教授席次」計畫： 邦政府為少數頂尖學者提供每個教席最高500萬歐元的特別預算，延攬世界一流人才。

🏗 創新轉移機制

2023年啟動「Hightech Transfer Bayern」攻勢，在全邦設立15個技術轉移中心，投入逾1億歐元，目標是將研究成果落實到中小企業，尤其是農村地區。

📊 五年成績（2024回顧）

科學部長布魯姆（Markus Blume）在2024年10月的內閣報告中總結：「全巴伐利亞就是一座校園，而且是德國最好的。」他強調高科技議程是巴伐利亞因應時代轉型的成功回應，足以作為全德國的典範。

甲：上層規劃：巴伐利亞AI生態系（Baiosphere）：

「巴伐利亞AI生態系（Baiosphere）」是德國巴伐利亞邦政府在其總額 55 億歐元的「高科技議程（Hightech Agenda Bayern）」下創立的國家級人工智慧網路策略品牌。

Baiosphere 的核心宗旨是建立一個將頂尖學術科研、跨國巨頭、初創企業以及社會大眾緊密相連的強大網路，將巴伐利亞打造為全歐洲最具活力的 AI 研發、商業應用與負責任發展（Responsible AI）的國際核心重鎮。

以下詳細拆解 Baiosphere 生態系的四大支柱與核心架構：

一、 核心治理機構：推動生態系的「雙引擎」

Baiosphere 的運作並非鬆散的學術聯盟，而是由邦政府三大部門（科學與藝術部、數位事務部、經濟部）共同倡議，並設有明確的官方治理機構：
巴伐利亞 AI 局（Baiosphere Agency）：作為生態系的中央聯絡窗口，負責促進產學合作、推動技術轉移、營運媒合平台（Matchmaking Platform），並提升巴伐利亞 AI 在國際上的能見度。
巴伐利亞 AI 委員會（Bavarian AI Council）：由國際知名 AI 學者與企業領袖組成，定期發布《Baiosphere Monitor》等策略白皮書，為邦政府的科技政策提供具前瞻性的策略導向。

二、 基礎設施與科研實力（人才與資金支柱）

巴伐利亞政府透過「高科技議程」直接向 AI 領域注入超過 3.6 億歐元的專項資金，建立極高的競爭壁壘：
破紀錄的教授席位：在全邦各大高校增設了 130 多個全新 AI 專屬教授席位（Professorships），吸引全球頂尖科學家進駐。
龐大的人才庫：全邦開設了與 AI 相關的學位課程，提供超過 10,000 個學習名額，每年產出約 2,200 篇高水平科研論文。
頂尖研究聯盟：包含慕尼黑工業大學（TUM）、慕尼黑大學（LMU）、亥姆霍茲中心、弗勞恩霍夫研究所（Fraunhofer）及德國航空太空中心（DLR）等頂級機構。

三、 跨區域的「節點與網路（Hubs & Nodes）」架構

Baiosphere 採取「輻射狀」的地理分工，將不同城市的科研與產業優勢最大化，主要由四個核心節點（Hubs）與一個生產網路組成：

[ 慕尼黑總部 Munich ] (智慧機器人、大語言模型、MCML)
[ 紐倫堡-埃爾朗根 Erlangen ] (數位醫療、健康AI、醫療谷)	[ 烏茨堡 Würzburg ] (數據科學、生命科學、自動化)
[ 因戈爾施塔特 Ingolstadt ] (智慧移動、自動駕駛車聯網)

智慧機器人中心 —— 慕尼黑（Munich Hub）：
定位：整個生態系的地理與技術核心（2024年 CS-Robotics 全球機器人排名第二）。
重點：聚焦於智慧機器人（Intelligent Robotics）、機器學習基礎理論（如 LMU/TUM 共同創立的 慕尼黑機器學習中心 MCML）。
健康醫療 AI 節點 —— 紐倫堡-埃爾朗根（Health Node）：
定位：結合傳統「醫療谷（Medical Valley）」的優勢。
重點：聚焦於AI 輔助診斷、醫學影像識別與多模態醫療大模型，並擁有西門子醫療等企業支持。
智慧移動節點 —— 因戈爾施塔特（Ingolstadt Hub）：
定位：德國汽車工業重鎮（奧迪 Audi 總部所在地）。
重點：聚焦於自動駕駛、智慧交通網路（Mobility）、車聯網安全與工業 4.0 的 AI 應用。
數據科學與生命科學節點 —— 烏茨堡（Würzburg Hub）：
定位：由烏茨堡-施文福科技大學（THWS）的 CAIRO 中心等機構領銜。
重點：專注於將 AI 應用於數據科學、生命科學以及跨行業的技術落地。
AI 生產網路（AI Production Network）—— 奧格斯堡（Augsburg）：
專注於如何將 AI 技術落實到傳統製造業的生產線上，協助中小企業進行數位轉型。

四、 產業轉化與新創孵化（企業支柱）

Baiosphere 確保學術成果不會停留在紙面上，而是快速轉化為經濟價值：
兩大重量級平台：
appliedAI：歐洲領先的可信賴 AI（Trustworthy AI）應用平台，直接協助 BMW、西門子等巨頭以及中小型企業將 AI 導入其核心業務。
AI+MUNICH：專為 AI 新創公司設立的孵化專案，提供早期資金、技術對接與商業化指導。
巴伐利亞 AI 基礎模型倡議（Bavarian AI Foundation Model Initiative）：為應對 OpenAI 等美製大模型的競爭，生態系正全力資助研發屬於歐洲本土、符合高隱私標準的工業與醫療專用基礎大模型。

總結

Baiosphere 就像是巴伐利亞政府用政策與數億歐元資金灌溉出的一座「AI 熱帶雨林」。在這個生態系中，大學負責提供人才與演算法突破，Baiosphere Agency 負責牽線搭橋，而西門子、BMW 與無數新創企業則負責將 AI 實體化，最終形成一個從理論、硬體、軟體到法規（可信賴 AI）的完整閉環。

如果您對特定部分感興趣，我們可以繼續探討：
註冊 Baiosphere Matchmaking 平台 的跨國產學合作流程。
歐盟 AI 法案（AI Act） 規範下，Baiosphere 如何推動「可信賴 AI（Trustworthy AI）」。

參見：Bavaria High Tech Agenda (網站： www.hightechagenda.de/)

（未完，見續篇）