德國巴伐利亞邦高科技議程（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/)

（未完，見續篇）

專案管理指引（八之三）

（續前篇）

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

4.5 專案組織和角色

4.5.1 專案組織

專案組織是一個臨時結構，包括定義妥的專案中角色、責任和職權。通過名稱將個人分配給專案組織中的特定角色。專案組織宜：
a) 明確匯報路線；
b) 由專案發起人或專案委員會批准；
c) 與專案涉及的每個人進行溝通。
專案組織的設計可以取決於專案前後環節（見4.2）、組織環境（見4.4）和專案利害相關者（見4.5.10）。

宜為每個人詳細地定義專案組織，以瞭解他們的角色和責任，以及與他們一起工作的個人的角色和責任。在整個專案中，責任宜相互一致且可追溯。專案組織的設計和實施還宜考慮專案管理的非正式面向，例如組織文化、專案團隊成員的動力和協調，以及人際交往能力和行為水準。

專案組織結構的示例如圖5所示。宜定義專案組織內各個角色之間的關係，並可按照7.5中所敘述事項進行管理。
注1：當存在專案委員會時，可變更匯報路線以適應治理的安排。
注2：並非所有組織中都設有專案辦公室。

圖 5 專案組織結構示例

個人可以承擔多個角色，但擔任專案發起人角色的個人不宜同時擔任專案經理、工作包負責人或專案團隊成員的角色，因為可能存在利益衝突。

專案組織也可以包括顧客或顧客代表，以及供應商或外包商，如4.2.3中所述。根據所需完成的具體工作和所需的專業能力，專案組織可以在整個專案生命週期中發生變化，尤其是在各個階段交接處。

專案組織的角色和責任詳見4.5.2至4.5.11。

4.5.2 發起組織

發起組織是上層權責機構，宜向專案委員會或專案發起人提供指導和資源，應對不斷升級的風險和問題，並做出或參考超出專案委員會或專案發起人授權範圍的決策。專案發起人可以代表發起組織，因此可能沒有將風險和問題的上報的或尋求指導的上級權威機構。發起組織代表、實際擔任此職務的個人或主體取決於專案所處的前後環節。例如：

a) 對於專案組合內專案，上級權威機構可以是專案組合經理或總監；
b) 對於專案群內的專案，上級權威組織可以是專案群經理。
註：與發起組織相關的綜合專案管理實務內容見6.2、6.3和6.9。

4.5.3 專案委員會

如有需要，專案委員會宜通過向專案發起人提供方向和指導來為專案做出貢獻（見圖5）。相對於專案發起人，專案委員會角色的許可權因組織和專案而異。例如，專案委員會可以包括：
a) 代表專案發起人負責的上級權威機構或治理主體；
b) 或由專案發起人任職、向專案發起人提供高級建議的董事會。

專案委員會宜：
—監督專案進展和發展，以確保其為組織利益服務；
—通過會議形式協助策略決策、消除障礙，並解決問題。

如果專案是兩個或多個組織之間的結合，則專案委員會可以包括各個組織的代表（參考ISO 21505）。註：專案委員會的常用術語包括「專案指導小組」、 「專案指導董事會會」、 「專案指導委員會」或「治理委員會」等。

4.5.4 專案發起人

專案發起人對已定義的上級部門負責，以實現專案目標、交付所需的產出和成果，以實現所需收益。

專案發起人的責任宜包括但不僅限於：專案發起人宜承認或擁護營運論證案例，並對專案治理負責，包括審查、覆核和保證（參考ISO 21505）。此外，專案發起人的責任宜包括但不僅限於：
a) 查證專案在整個生命週期中的合理性；
b) 確認專案經理和團隊有技能並且有能力執行分配的工作；
c) 向專案經理提供決策、方向、建議和前後環節，以使營運論證案例中定義的陳述的商業需求能夠在專案或組織可接受的風險水準內得到滿足；
d) 確認組織為組織變革或社會變革做好了準備和承諾，並且確定變革的發生（見7.14）；
e) 解決升級的問題和風險；
f) 吸引關鍵的專案利害相關者；
g) 在其授權範圍內做出決定；
h) 將風險和問題升級到其授權範圍之外，擴展到更高級別的許可權；
i) 設定專案的文化和道德基調。

專案發起人通常是專案委員會的成員，代表專案委員會在日常工作或事先議定的專案管理活動中的利益和立場。在某些情況下，個人可以支援專案發起人，也可以履行既定責任來代表專案發起人行事。在此種情況下，宜在專案組織中定義責任分工。

注1：專案發起人常用術語包括「專案執行官project executive」、 「專案負責人project owner」、「產品負責人product owner representative」或「資深負責人senior responsible owner」等(見圖5)。
注2：與專案發起人相關的綜合專案管理實務，見6.4。

4.5.5 專案保證

雖然專案發起人對稽核、審查和保證等承擔最主要責任，但該等活動可分配給一名或多名人員，代表專案發起人行事，而且獨立于專案經理和項目團隊。

4.5.6 專案經理

專案經理對專案發起人或專案委員會負責，以完成定義範圍，並領導和管理專案團隊。專案經理的其他活動可能包括（但不僅限於）下列事項：
a) 建立與議定的治理方法一致的管理方法；
b) 激勵專案團隊；
c) 提供日復一日常規型監督和領導力；
d) 為團隊設定方法、責任、工作範圍和標的；
e) 根據專案計畫監督、預測和匯報專案總體進度（見7.2和7.15）；
f) 管理風險（見7.8）和問題（見7.9）；
g) 控制和管理專案變更 (見7.10)；
h) 按照相關合約的規定管理供應商績效（見7.17）；
i) 確保專案利害相關者按計劃參與（見7.12）和溝通（見7.13）專案；
j) 確證專案提供的產出和成果。

專案經理可以由專案管理團隊協助，其成員擔任特定的角色，例如排程、成本控制和品質保證。
註：與專案經理相關的綜合專案管理實務，見6.5、6.6及6.8。

4.5.7 專案辦公室

如有需要，專案辦公室宜有其明確的角色、責任和匯報線。專案辦公室可以執行各式各樣的活動來支持專案經理和專案團隊，包括但不僅限於：
a) 分析；
b) 制定出和行政支援治理；
c) 使專案方法和過程標準化；
d) 專案管理訓練；
e) 規劃和監督；
f) 資訊管理；
g) 提供行政支援。

此外，專案辦公室可以支持多個專案，可與專案群或專案組合管理辦公室結合，也可以執行專案群或專案組合管理辦公室的職能。

專案辦公室可以支持除專案經理之外的角色，例如專案發起人、專案委員會或專案團隊中的其他職位。專案辦公室可以承擔專案管理組織能力中心或卓越中心的角色，支援組織提高其專案管理的成熟度。

註：專案辦公室可以稱為「專案管理辦公室project management office」、 「專案支援辦公室project support office」，或其他組織批准的術語。

4.5.8 工作包負責人

工作包負責人對專案經理領導、管理和交付工作包中定義的指派的產出或成果。工作包負責人或團隊負責人可以是發起組織的一部分，也可以來自協力廠商組織，例如：供應商。工作包負責人的責任包括但不僅限於：
a) 確定工作包已按要求的品質、進度和預算完成；
b) 協助和審查重要的管理文件；
c) 對照工作包計畫，規劃、監督、預測和匯報總體進度；
d) 管理著去解決風險和問題，並向上呈報超出其決策許可權的風險和問題；
e) 控制工作範圍的變更，並向上請求超出其許可權的變更授權；
f) 管理和最佳化資源的使用；
g) 將最終產出移交給專案團隊或專案經理。

注1：專案經理可以承擔工作包負責人的角色。
注2：與工作包負責人相關的綜合專案管理實務，見6.7。

4.5.9 專案團隊成員

專案團隊成員執行專案活動，並對工作包負責人或專案經理負責完成其分配的活動和提供相應的交付物。

4.5.10 專案利害相關者

專案利害相關者是指對專案感興趣、可能影響、受到影響，或者是自認為會遭到影響的個人、團體或組織（見圖6）。專案利害相關者可以來自專案和組織的內部或外部。

圖 6 潛在的利害相關者示例

4.5.11 其他角色

宜確定其他角色，以適應所需工作，例如管理產出開發的角色。例子包括與敏捷交付、服務和營運管理、組織化與社會變革、溝通和各種工程學科相關的角色。

4.6 專案人員的專業能力

專案管理的專業能力可分為（但不僅限於）以下事項：
a) 技術型專業能力，指導、管理、規劃和交付專案的技術能力，包括該文件定義的概念和實施；
b) 行為型專業能力，與人際關係相關的行為能力，例如領導力、開發團隊、人員管理、輔導、談判和衝突管理等；
c) 在組織、合約和外部環境中與專案管理相關的業務和其他專業能力。

不參與專案管理的專案團隊成員宜具備在相關領域的專業能力，使其能夠履行分配到的責任。

宜將所需專業能力與現有專業能力的差距視為專案的約束或風險。宜審查並縮小專業能力差距。專業能力和技能可以通過持續的個人和專業發展來改進或提升。

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

（未完，見續篇）

專案管理指引（八之二）

（續前篇）

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

4 專案管理概念

4.1 概述

4.1.1 總體說明

此章描述了第6章和第7章所講述的《專案管理實務》以及在專案過程中進行的總體考量事項。圖1闡述一個專案產生的前後環節及其環境。《專案》可以是獨立的（stand-alone），也可以是《專案群》，或者是《專案組合project portfolio》的一部分 （見4.2.5），也可以跨越組織邊界，在不同組織之間形成專案。宜根據組織策略，識別出來的對象、記錄以及評估各種機會、威脅、弱勢和優勢，為未來的專案措施提供決策指導。在《營運論證案例business case》裡進一步審視、展現相關的機會和威脅。一份營運論證案例可形成一個或多個專案。專案的產出具有預期成果，為專案發起人組織以及內外部的利害相關者實現收益。

(圖一) 在治理、專案群管理和專案組合管理前後環節下的專案管理示意

4.1.2 專案

組織展開工作以實現特定目標。一般來說，這項工作通常可以分成營運和專案。營運和專案的不同之處在於：
a) 專案是臨時性的，專注於為發起組織、專案利害相關者或顧客獲取或增加價值或能力（capability）；
b) 營運則經由持續性的活動，專注於組織的持續化發展，例如，交付可重複性的產品和服務。

專案目標可以通過專案的交付物、產出、成果和收益的組合來實現，取決於專案的前後環節（見4.2）和專案治理（見4.3）提供的方向。專案的目標宜有助於利害相關者的成果和實現收益，包括發起組織、其他內部和外部利害相關者、顧客及其利害相關者。雖然很多專案具有相似的特性，但是每一個專案都是獨特的。各個專案相互之間可能發生的差異包括（但不僅限於）以下幾種因素：

目標	前後環節	期望的成果
提交的產出	利害相關者受到的衝擊	使用的資源
複雜性	約束（見4.2.4）	使用的過程或方法

4.1.3 專案管理

專案管理整合了實務各個面向，以指導、啟動、規劃、監督、控制和關閉專案，管理分配給專案的資源，激勵參與專案的個別人員，實現專案目標。專案管理宜通過一套過程和方法進行，該等過程和方法須設計為系統化形式，亦須包括該文件中描述的專案所需的實務條件或狀況。

4.2 前後環節

4.2.1 專案前後環節的衝擊

4.2.1.1 概述
專案的前後環節會影響專案的績效和成功的可能性。專案團隊宜考慮組織內部和外部的因素。

4.2.1.2 組織內部因素
組織內部的因素，例如：策略、技術、常規和專案管理的成熟度、資源可獲得性以及組織文化和結構，都可能對專案的成功產生衝擊。在調整適應專案管理方法，開發營運論證案例，執行可行性研究以及過渡到營運和顧客的設計時（適用時），宜考慮專案與其前後環節之間的關係及相互作用的效應。

4.2.1.3 組織外部因素
組織外部因素可以包括（但不僅限於）社會經濟、地理區域、政治、法規、技術和生態各種因素。該等因素可以通過額外的需求或約束，或者通過引入影響專案的風險，來對專案產生衝擊。儘管該等因素通常超出專案發起人或專案經理的控制或影響的容許能力（capability），但在指導時、合理佐證時（見4.3.2）、啟動時、規劃、監督時、控制和關閉專案時，仍宜考慮和規劃該等因素。

4.2.2 組織策略和專案

組織通常根據其願景、使命、價值觀、政策和組織內外部的因素來制定總體策略。專案是實現策略目標的一種方式。在識別組織的機會和威脅時，宜考慮潛在的產出和成果。圖2說明了從承接的專案中創造價值的過程。當專案產生的收益超過投入的資源時，便會產生正向價值。創造的價值可以是有形的或無形的。

圖 2 通過專案和專案群創造價值

4.2.3 顧客和供應商觀點

可以從兩個觀察角度執行專案：
a) 顧客或發起組織：組織掌握要求事項，可以承擔所有工作或將部分工作外包給供應商組織；
b) 供應商或外包商組織：該等組織的核心基礎或部分業務，是向其他組織提供服務或產品。

示例1：供應商或外包商提供服務或產品，作為一個營收型專案，可以包括規劃與建置道路、機場、鐵路和資訊技術系統。

在大多數情況下，供應商的專案範圍是顧客專案範圍的一部分。合約的每一個參與者宜注意自身在專案中的組織利益，並具備執行該專案的理由。顧客與供應商的關係可能引起參與者某種困惑，因為對於某些專案，此種關係可能是不同組織之間的或是組織內部的。在此種情況下，供應商的部分角色由外部的外包商或供應商，為來自另外一個部門或同一組織其他部門的顧客承擔。

示例2：一家公司的資訊技術部門可以使用製造部門的合約資源或合作夥伴進行軟體升級。在該等情況下，供應商-顧客的角色可以是多個向度的。

合約各方參與者宜明確區分下列事項：
—專案治理（見4.3）宜如何在合約劃定範圍的邊緣情況之兩側和跨邊界進行；
—組織的專案管理團隊結構（見4.5.1）；
—參與專案的合適人員；
—將來被採用的與交付所需的專案生命週期有關的工作實務。

4.2.4 專案約束

專案的產出和成果宜在確定的約束條件下實現，例如（但不僅限於）：
a) 完成專案的期限或目標日期；
b) 組織從財務上支援資金的可獲得性；
c) 批准並分配到各階段的預算；
d) 專案資源的可獲得性，例如未展開專案前的需求事項、相關的專案活動所須具備的適當技能、設施、設備、材料、基礎設施、工具和其他資源的人員；
e) 與員工健康和安全有關的因素；
f) 保全安全性；
g) 可接受的風險水準；
h) 專案及其產出的潛在社會、環境和生態的衝擊；
i) 法律、規則和其他的政府要求事項；
j) 最低程度須達到的品質標準。

各式各樣約束通常是相互關聯的，因此一個約束的更改可能會影響一個或多個其他約束。因此，宜瞭解、平衡並定期檢查該等約束的影響。

專案的主要利害相關者，尤其是決策者，宜就專案的約束和相對優先順序達成一致，為旨在促進成功的決策和後續行動奠定堅實的基礎。

4.2.5 獨立型、專案群部分或專案組合部分的專案

專案可以由專案群、專案組合元件組成，也可以是獨立型的（參考ISO 21503、ISO 21504）。專案與其他元件之間的關係，見圖3。

專案管理的原理在所有情況下都相同的，但是一個典型的區別是專案治理的工作方式，尤其是匯報和決策的水準。如果專案是專案群或專案組合的一部分，專案的目標和治理宜與該專案群或專案組合的治理保持一致（見4.3）。

圖3：專案組合、專案群和專案之間關係的示例

4.3 專案治理

4.3.1 治理架構

專案治理宜包括組織根據議定的營運論證案例進行指導、授權和控制專案的原則、政策和架構。治理宜提供以下主題的監督，例如：
a) 用於進行該文件中定義活動和實施的政策、過程和方法；
b) 管理架構，包括專案生命週期（見4.4）；
c) 角色和責任，包括決策許可權（見4.5）。

維持專案治理的責任通常由發起組織的治理主體分配給專案發起人（見4.5.4）或專案委員會（見4.5.3）。
專案治理宜是發起組織整體治理架構中的一個組成部分。

4.3.2 營運論證案例
營運論證案例為專案治理提供基礎。營運論證案例宜用來佐證說明專案執行和得以繼續的合理性，並且至少包括或參考以下內容：

a) 預估擬實現的目標；
b) 策略配合一致性和將會實現的潛在收益；
c) 定義衡量指標（metrics）以評估所創造的價值；
d) 組織可接受的風險水準；
e) 預算、進度和品質要求；
f) 潛在的營業以及對組織其他營運的干擾；
g) 專案利害相關者管理和關係管理；
h) 人力資源和物質資源的使用；
i) 所需的技能、知識和能力；
j) 目標範圍；
k) 情境介紹；
l) 建議的管理方法；
m) 通過變革維持業務和組織活動的能力。

4.4 專案生命週期

在定義出專案生命週期時，宜考慮以下因素：

a) 組織型式和專案治理；
b) 各式各樣風險；
c) 控制各種因素；
d) 專案的性質或特徵事項；
e) 其他組織型式和環境因素。

專案階段的數量和名稱取決於面對的專案類型、期望的治理和參雜在內的風險。各階段反映所採取的交付方法，例如預測型（predictive）、反覆運算型（iterative）、增量型（incremental）、自我調整型（adaptive）或者混合型（hybrid）。管理方法通常使用不同的字詞來表示階段，例如「步驟stages」、「反覆運算iteration」和「發佈release」。

每個階段宜有明確給定的開始和結束。專案生命週期的每個階段宜都有與決策、關鍵交付物、產出或成果相關的特定里程碑。每個階段之前都宜有一個決策點。該等決策點通常稱為「關卡gates」，是專案治理的重要面向。宜定義專案開始某一個階段所需的準則，但可能因組織環境、具體使用的專案生命週期和既定的專案治理而有所不同。在某些情況下，專案階段可能會前後重疊。

宜定義專案的決策點和階段，如圖4所示，並且可以根據組織和外部環境、資金、所需收益、風險和約束條件而有所不同。圖4進一步闡述了專案生命週期、綜合專案管理實務（見第6章）和專案管理實務（見第7章）之間的關係。
注1：在某些情況下，各階段可能重疊。
注2：階段（phases）有時被稱為「步驟stages」。

圖 4 專案生命週期、綜合專案管理實務和專案管理實務之間的關係

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

（未完，見續篇）

專案管理指引（八之一）

 

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

該文件係基於ISO 21500:2012的修改版（即2021年版本）而撰寫的指引文件，更新事項如下述：
a）專案管理的邊界擴展到專案發起人機構的專案監督和指導工作；
b）新增專案成果和專案收益的有關內容；
c）新增專案的組織級前後環節的因素；
d）新增專案組織的角色和責任；
e）新增專案生命週期決策點、門禁的描述，擴充了專案管理業務；
f）新增專案前和專案後的工作描述；
g）內容形式從基於過程性的描述轉變為按業務和基於事實陳述的描述（參見附錄A）。

簡介

該文件提供專案管理中重要的概念與實務指引，對於專案的成功交付產生衝擊。
該文件的目標讀者群包括（但不限於此）：
a）執行階層及資深管理階層人員，提供更深入的專案管理之理解，並協助他們給予專案經理及專案相關人員適當的支持與指導；
b）參與專案治理、指導、保證、稽核及管理的個人，如專案贊助人、專案董事會、稽核員及專案經理；
c）專案經理與專案團隊成員，建立共同的基礎，以理解、執行、比較、評估及溝通專案所採用的實務；
d）國家或組織專案管理標準、流程與方法的制定者。
此外，該文件對參與支持的個人也非常有用：
—投資組合與計畫的治理、指導與管理；
—專案團隊、計畫與專案辦公室或類似組織架構；
—專案、計畫與組合管理的學術研究；
—與專案管理相關的職能，如財務、會計、人力資源管理、採購及法務。

目錄

1 範圍

該文件給出了專案管理的指導性內容，適用於企業與事業單位、機關和社團等不同組織的各式各樣目的、承接與交付成果方式、使用的生命週期模型、複雜程度、規模、成本或持續時間的專案。

註：交付成果方式可能是適合於各種差異之產出類型的各種方法或過程，例如預測型、增量型、反覆運算型、適宜型或混合型，包括敏捷方法。

該文件概括描述歷年來視為行之有效且獲得良好結果的專案管理前後環節。該文件並未給出專案群、專案組合的指引。僅在專案管理前後環節下描述共同適用的管理主題和內容。

3. 辭彙及術語

3.1	基線 baseline 對績效進行監督和控制的比較參考依據。
3. 2	收益benefit 創造的優勢、價值或其他正向影響。
3.3	營運論證案例 business case 用於支持對專案（3.20）、專案群（3.18）或專案組合（3.15）做出承諾的決策所提供的書面佐證說明。 註：按行業和專案階段，具體可形成立項佐證說明報告、專案建議書、商業計畫書、投資計畫書、可行性研究報告、開題報告、實施方案、方案報告、任務書等。
3.4	變更申請 change request 提議專案（3.20）做出變更的文件。
3.5	配置管理 configuration management 對控制（3.6）、關聯和維護文件化、規格和實際屬性的程序應用方式。
3.6	控制 control 將實際績效與規劃績效加以比較，分析偏差，並根據需要採取適當的矯正和預防措施（3.17）的活動。
3.7	矯正措施 corrective action 修正工作績效以使績效符合計畫的指導/方向和活動。
3.8	關鍵路徑 critical path 決定專案（3.20）或其中的各個階段最早可能達成日期的活動之前後順序。
3.9	交付物 deliverable 專案（3.20）需要產出的獨特且可查證的元素。
3.10	治理 governance 組織受到指導與控制的原則、政策及架構。
3.11	問題 issue 專案（3.20）期間發生的事件，需要將之解決，使專案（3.20）能夠繼續進行。
3.12	機會 opportunity 可能產生正面衝擊的風險事件。
3.13	成果 outcome 使用專案（3.20）產出（3.14）所出現的變化。
3.14	產出 output 構成專案（3.20）結果的有形或無形交付物（3.9）的總合成果。
3.15	組合portfolio 為促進管理以實現策略目標而將專案組合元件（3.16）聚集在一起的集合。
3.16	組合元件 portfolio component 專案（3.20）、專案群（3.18）、專案組合（3.15）或其他相關工作。
3.17	預防措施 preventive action 消除潛在不符合或其他潛在不期望情況的原因所採取的措施。 駐：採取預防措施以防止不符合發生，而採取矯正措施（3.7）以防止不符合再次發生。
3.18	專案群 programme 為實現收益（3.2）以協調的方式管理的一組專案群的組成物件（3.19）。
3.19	專案群組成物件 programme component 專案（3.20）、專案群（3.18）或其他相關工作。
3.20	專案 project 實現一個或多個既定目標所付出的臨時性努力。 補充說明： 一個「專案」就是為了達成某個特定目的，在一段有限的時間內，透過有計劃、有組織的付出努力來完成一系列獨特任務的過程。它與日常營運活動的區別在於其「臨時性」和「獨特性」，且需要一群人付出努力而達成專案目標。
3.21	專案保證 project assurance 使發起組織和專案發起人（3.26）相信專案（3.20）有可能實現其目標所採取的有計劃和有系統的必要措施。
3.22	專案治理 project governance 授權和指導專案（3.20）實現規劃設定目標的原則、政策和程序。 補充說明： 「專案治理」，是從經營層面設計橫跨多個專案管理與控制機制的相關知識。目的在確保企業內形形色色目前運作中專案能夠在預定的時間、預算和品質範圍內完成。
3.23	專案生命週期 project life cycle 從專案（3.20）開始到結束所定義的一組階段。 補充說明： 專案生命週期是指專案從構想到完成所經歷的結構化流程，通常分為五大階段：啟動、規劃、執行、監督與結束。
3.24	專案管理 project management 指導和控制（3.6）達成規劃設定目標的協調活動。
3.25	專案範圍 project scope 授權完成規劃設定目標的工作。
3.26	專案發起人 sponsor 負責獲取資源和執行決策以使專案成功的人。
3.27	專案利害相關者 stakeholder 對專案（3.20）、專案群（3.18）或專案組合（3.15）的任何方面有利益或可能影響、受其影響或認為自己受其影響的個人、群體或組織。
3.28	威脅 threat 可能產生負面衝擊的風險事件。
3.29	工作分解結構 work breakdown structure 將專案（3.20）或專案群（3.18）所定義的工作範圍逐層分解為更低層級工作單元而形成的結構。
3.30	工作包 work package 具有合宜定義出來的範圍、交付物（3.9）、時間表和成本的一組活動。

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


（未完，見續篇）

醫療器材維護管理計劃概要（五之五）

  （續前篇）

ISO/TS 5137:2026

適合一般醫療保健服務產業界，器材與設備維護、維修者，具備基礎教育背景的讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

補充說明：

機械設備檢查表示例：

機構部件	檢查內容
潤滑系統	潤滑油位是否位於正常範圍 潤滑油是否明澈、清潔 潤滑油管路是否洩漏、滲出 潤滑點是否已按時施加潤滑劑
冷卻系統	冷卻液位是否位於正常範圍 冷卻液是否清潔 冷卻風扇是否正常運轉、無雜音 冷卻管路是否洩漏
傳動系統	皮帶或鏈條是否鬆弛或損壞 齒輪箱油位是否正常 軸承是否過熱或有異音
緊固件	螺栓、螺母、防振墊片等緊固件是否鬆動 緊固件是否有缺失、故障
安全防護裝置	安全防護罩是否完整 緊急停止按鈕是否有效 安全警示標識是否清晰

 

電氣設備檢查表示例：

電氣元件	檢查內容
電源線路	電源線是否老化或破損 接線端子是否鬆動或腐蝕 是否有漏電現象
控制面板	指示燈是否正常 按鈕和開關是否靈敏 儀表顯示是否準確
電機	電機外殼是否清潔 電機軸承是否過熱或有異音 電機接線是否牢固
保護裝置	保險絲或斷路器是否正常 過載保護裝置是否有效 接地線是否連接良好 安全警示燈號是否正常運作
散熱系統	散熱風扇是否正常運轉 散熱片是否清潔 排汽通風口是否堵塞
緊急應變	當 MMIS 系統失效（斷電或當機）時，是否有「紙本備援作業程序」，確保維護紀錄不中斷

 

液壓設備檢查表示例：

液壓部件	檢查內容
液壓油	油位是否在正常範圍內 油質是否清潔，有無雜質或水分 定期進行油品分析
液壓泵	泵浦運轉時是否有異常噪音或振動 泵浦的壓力是否穩定 泵浦是否有洩漏現象
液壓閥	閥門動作是否順暢 閥門是否有洩漏現象 電磁閥是否正常運作
液壓缸	活塞桿是否有刮傷或鏽蝕 液壓缸是否有洩漏現象 液壓缸動作是否平穩
管路與接頭	管路是否有變形或損壞 接頭是否鬆動或洩漏 固定管路是否牢固

8 量測、分析與改進

8.1 維護/維修流程的量測

HDO應採用適當的方法來監督及適時衡量維護/維修管理計畫流程。該等方法將展現流程達成預定成果的能力。若未達成預期成果，將視情況採取矯正及矯正措施。

8.2 資料分析

BES應定期檢視維護/維修紀錄，並建立流程與程序，以確保持續改進。

收集到的資料將予以分析，以進一步改進結構與流程。

8.3 不符合醫療器材的管制

8.3.1 一般

未符合適當安全與性能要求，且未依HDO定義準則通過測試或檢查的醫療器材，應予以識別並加以管制，並防止使用該器材。

HDO應制定文件化程序，定義醫療器材的識別、文件化、分隔、評估及處置的控制及相關責任與權限。

不可使用不符合的醫療器材。

醫療器材的狀態（如：可以/不可使用）應清晰可見。

8.3.2 回應不符合產品的措施

HDO應以下列一種或多種方式處理不符合產品：
a. 採取措施消除偵測到的不符合；
b. 受到特許才得以授權使用

HDO應確保只有在提供合理佐證說明、取得核准且符合適用法規要求時，才會以特許方式接受不符合產品。該等佐證說明應由風險分析與客觀證據支持。特許權接受紀錄及授權者身份應予保存。

8.4 不良效應與事件調查與通報

所有涉及醫療器材故障的不良效應與事件都應予以調查，相關單位（包括BES）應全力配合HDO。如適用時，報告應提交給HDO所在地的主管機關、器材製造商或授權代表（AR）。

受影響的醫療器材、其配件及耗材應停止使用，做出標記並存放於防護合宜的區域。

完成調查後，HDO應就所有與受到影響之醫療器材波及者、相關的事件提交書面報告，並在適當情況下提供副本給製造商或AR，並向主管機關報告。

BES或HDO應獲悉係稱醫療器材受到調查時的任何法規單位做出的要求。

8.5 警戒、安全、現場矯正行動及召回通知

在收到警示、安全、現場矯正及召回通知後，HDO 或 GES 應通知使用者並對受影響的醫療器材採取適當措施。

在適當情況下，醫療器材應從使用場所予以隔離，由採取矯正措施直到完整結束為止。BES應視情況向相關者傳達有關醫療器材故障及錯誤的相關資訊。

8.6 內部稽核

HDO應於預定時間的期間進行內部稽核，以決定係稱計畫的效率。稽核應確認管理計畫已實施下列事項：
a. 符合計畫與文件化記載的安排事項;
b. 符合該文件的要求;
c. 達到 HDO 制定的維護/維修管理計畫要求
d. 達到適用的法規要求
e. 有效果地實施與維護

HDO應訂定文件化程序，說明規劃及執行稽核，和記錄與報告稽核結果的責任與要求。

內部稽核亦應確保以下事項
a. 醫療器材正依照製造商建議合宜地使用著。
b. 醫療器材的功能確已依照文件內容所描述的方式運作著。
c. 遵守相關國家法規要求;
d. 維護/維修工作依照文件化記載的程序進行;
e. 所有流程均予以記錄並維持。

稽核及其結果的紀錄，包括稽核流程與受稽核領域的識別及做出的結論，皆須加以保存。

負責稽核區域的管理單位應確保在沒有必要不須拖延的情況下，採取必要的矯正與矯正措施，以消除偵測到的不符合及其根本原因。後續追蹤活動應包括對所採取措施的核實及查證結果的報告。

8.7 醫療器材更換計畫

HDO應評鑑醫療器材須予替換的考量，並依照器材的預期用途，包括診斷/治療方式與技術的進展，以及病患安全。應執行風險分析並記錄全部內容。

醫療器材的更換應進行相關的規劃及文件化，並可考慮以下事項：
a. 病患安全、危害/危險、召回
b. 醫療器材維護/維修狀態、備件/物料供應、技術支援可獲得性、近期或未來維護/維修費用，
c. 或者逕行淘汰:
1. 同一醫療器材的新型號設計帶來更佳的變更，從而具有更佳的效率與容量；
2. 引入醫療器材服務的新概念；
3. 新的安全要求使既有的醫療器材較不安全；
4. 備件/物料已不再供應；
5. 基於維護/維修歷史的醫療器材可靠性顯示趨勢下行，即故障頻率愈來愈短；
6. 未達到績效水準；
7. 醫療器材對服務提供的衝擊，即對病患照護程度必須盡善盡美；
8. 替代性的醫療器材；
9. 更換成本；若係稱器材已逾越製造商建議的醫療器材壽命；
10. 現今技術水準已經過若干改進。

8.8 諮詢服務

BES應在醫療器材整個生命週期內，向HDO建議以下維護/維修條款：
a. 挑選醫療器材；
b. 安裝、測試與調試、操作與維護/維修；
c. 升級與修改；
d. 停止使用醫療器材；
e. 更換醫療器材；
f. 任何不良事件；
g. 評定醫療器材的狀況；
h. 拆解並銷毀處理。

（全文竟）