首页资源分类嵌入式系统 > CMMi-SVC_V1.2_繁体中文

CMMi-SVC_V1.2_繁体中文

已有 445110个资源

下载专区

上传者其他资源

文档信息举报收藏

标    签:CMMiSVC_V1 2_繁体中文

分    享:

文档简介

CMMi-SVC_V1.2_繁体中文

文档预览

適用於服務的能力成熟度整合模式 , 1.2 版 CMMI 產品團隊 為了更佳服務的流程改善 2009 年 2 月 技術報告 CMU/SEI-2009-TR-001 ESC-TR-2009-001 在著作權下可無條件流通. 適用於服務的能力成熟度整合模式 1.2 版 本報告是為以下單位所準備的 SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 報告中的想法與研究結果,並非以美國國防部官方的身份來解釋,而是針 對科學和科技資訊交換領域所發行的。 此文件由美國國防部贊助。軟體工程學院是由美國國防部提供官方基金所 成立的研究發展中心。 卡內基美隆大學版權所有 2009 無擔保 卡內基美隆大學軟體工程學院係以文件交付時的狀況提供文件。卡內基美 隆大學對任何明示、默示的事情不做任何擔保,其中包括但不限於符合特 定用途的擔保和適售性,尤其是使用此文件所產生的結果。卡內基美隆大 學對於任何關於免除專利,商標或著作權侵害不做任何擔保。 使用此報告內的任何商標不能以任何方式侵害商標所有人的權利。 內部使用。複製此文件或利用此文件衍生的文件,只要版權及無擔保的聲 明包含於所有的複製文件及衍生文件內,可允許於內部使用。 外部使用。複製此文件或利用此文件衍生的文件於外部或商業用途,應向 軟體工程學院授權中心提出申請。 此文件是卡內基美隆大學軟體工程學院,官方提供資金成立的研究發展中 心,執行聯邦政府合約號碼 FA8721-05-C-0003 所產生。美國政府擁有免 技術權利金政府使用許可,以全部或部分或任何方式使用,複製或公布此 文件。或根據版權許可條款 252.227-7013 允許他人做相同的事。 有 關 於 購 買 SEI 報 告 複 本 的 資 訊 , 請 拜 訪 我 們 網 站 的 出 版 品 部 分 (http://www.sei.cmu.edu/publications/)。 CMMI-SVC 中文版發刊詞 適用於服務的能力成熟度整合模式 1.2 版 網路與資通訊技術快速發展下,企業無不運用資訊科技強化服務以增 加競爭力;而全球專業機構評比各國經濟競爭力的重點方向也逐漸從製造 業轉向服務業,因此服務的質與量已成為一個國家經濟發展成敗的關鍵因 素。如何有效率、有系統的進行 IT 服務系統發展與管理,如何精進服務 效能,再藉由資通訊平台推動「服務外銷」,達到業務全球化的發展目 標,成為我國乃至全球關注的焦點。 美 國 卡 內 基 美 隆 大 學 軟 體 工 程 學 院 SEI(Software Engineering Institute),針對軟體系統的研發、採購與維運,提出了三套標準流程模 式,分別是 CMMI-DEV、CMMI-ACQ 及 CMMI-SVC。CMMI-DEV 規範 軟體開發程序,CMMI-ACQ 則針對採購商與供應商提出採購管理流程, 而 CMMI-SVC 則是從服務的觀點,描述服務作業應該有的流程特性,並 針對組織提供給內外部客戶的服務做成熟度評比,其主要訴求就是如何提 高服務績效和服務水準。 資訊工業策進會於 2009 年取得了 SEI 授權,以 15 個月的時間翻譯 出版 CMMI-SVC v1.2 中文版,過程中除經內部嚴密審查外,並由產官學 各界先進組成委員會進行外部審查,最後再依 SEI 規範要求,經過獨立審 查方得完成。在此要向本書的翻譯小組及全體審查委員致敬,特別感謝他 們對本書出版所付出的心力。CMMI-SVC v1.2 中文版的出版,必將有助 於我國軟體產業服務化之發展,並有效提高服務績效與品質。 財團法人資訊工業策進會 執行長 柯志昇 2010 年 3 月 前言 i 適用於服務的能力成熟度整合模式 1.2 版 CMMI-SVC 中文版序 服務業是推動世界經濟成長的重要推手。發展並改善成熟的服務實務 是達成績效、提高顧客滿意度並增加獲利的關鍵要素。CMMI 模式是最佳 實務的集合,能協助組織改善流程。第一個 CMMI 模式(CMMI-DEV)是由 產業、政府和 SEI 組成的產品小組所發展,提供發展產品與服務所需之流 程改善。第二個 CMMI 模式(CMMI-ACQ)提供組織在採購產品或服務的流 程改善指引,随著這 2 個 CMMI 模式的成功,適用於服務的能力成熟度 整合模式(CMMI-SVC)也發展出來,以滿足組織在服務交付上尋找改善流 程的需求。 CMMI-SVC 以「CMMI Model Foundation」為基礎,並與數個服務 組織合作修調 CMMI 以便服務業使用。此模式的最佳實務著重於對客戶及 使用者提供有品質的服務活動。CMMI-SVC 有 24 個流程領域。其中包括 16 個基礎流程領域(可與其他 CMMI 模式共用)、1 個共用的流程領域(供 應商協議管理)、6 個服務特定的流程領域以及 1 個附加的流程領域。這 6 個服務特定的流程領域聚焦於能力與可用度管理、服務持續性、服務交 付、事件解決方案與預防、服務移轉、服務系統發展及策略服務管理。服 務系統發展為附加的流程領域。 資訊工業策進會一直是台灣倡導 CMMI 流程改善制度的推手,多年 來擔任 CMMI-DEV 與 CMMI-ACQ 的中文化工作,貢獻全球華人世界。 SEI 感激並再度感謝資訊工業策進會延續以往的熱忱,促成 CMMI-SVC 中文版的發行。 軟體工程學院 執行長 Dr. Paul Nielsen 2010 年 3 月 ii 前言 CMMI-SVC 中文版序 適用於服務的能力成熟度整合模式 1.2 版 發展服務業,可以提升產業附加價值、強化核心競爭優勢、創造更多 就業機會,服務業是全球經濟成長重要的推手。「服務經濟」(Service Economy)已然成型並成為全球經濟趨勢,更是世界各國未來經濟成長的 主要動能。然而資訊科技日新月異與無所不在的特性,讓服務提供者與服 務使用者在如何有效運用與管理 ICT,藉以提升競爭力的議題上面臨重大 挑戰。這時 CMMI –SVC 在上述的議題中則可提供如何提高服務績效和服 務水準的實務作法,從 CMMI 模型架構上逐漸提升服務管理與服務交付的 能力度或成熟度。 CMMI-SVC 為 美 國 卡 內 基 美 隆 大 學 軟 體 工 程 學 院 SEI (Software Engineering Institute)彙集來自政府單位與產業界最佳執行方法的研究成 果,範圍涵蓋 IT 服務管理並充分運用 CMMI 共通模型架構、觀念及流程 領域特性編製而成,除原本 16 個基礎流程領域外,針對服務作業的特性 另外提供能力與可用度管理、事件解決方案與預防、服務持續性、服務交 付、服務系統發展、服務系統轉換及策略服務管理共 7 個流程領域,除讓 服務供應商可應用 CMMI 最佳實務來改善給客戶及使用者的服務品質與績 效外,CMMI-SVC 也可用來進行服務相關流程的評鑑,提供致力於改善 流程活動的組織作為參考。 資訊工業策進會在獲得 SEI 授權翻譯 CMMI-SVC v1.2 後,立即籌組 翻譯小組執行任務,並以同儕審查、跨組審查會議及討論的方式完成初 稿,隨後邀請業界先進擔任外部專家進行審查與內容建議,最後再經獨立 審查小組確認,並參照各方意見修正後方才定稿。CMMI –SVC v1.2 中 文版已製作完成,可作為全球資訊軟體產業在衡量並提升服務水準與品質 的參考,在此謹向所有參與人員致敬,並再次感謝他們的貢獻。 財團法人資訊工業策進會 創新應用服務研究所 所長 楊仁達 前言 2010 年 3 月 iii 適用於服務的能力成熟度整合模式 1.2 版 中文版參與人員 指導人員 呂正華 經濟部工業局 謝戎鋒 經濟部工業局 王子儀 經濟部工業局 外部審查 楊仁達 財團法人資訊工業策進會 樂以媛 台灣科技化服務管理協會副秘書長 朱延平 東海大學 陳振楠 關貿網路(股)有限公司 彭永興 工業技術研究院 行政院研考會 財政部財稅資料中心 國立成功大學資訊工程研究所 獨立審查 洪肇奎 國立成功大學 翻譯團隊 林文質 財團法人資訊工業策進會 歐世文 財團法人資訊工業策進會 林栩傑 財團法人資訊工業策進會 陳蕙琪 財團法人資訊工業策進會 iv 前言 前言 目的 前言 適用於服務的能力成熟度整合模式 1.2 版 CMMI 模式是最佳實務的集合,能協助組織改善流 程。第一個 CMMI 模式是由產業、政府和 SEI 組成的 產品小組發展出來的。為經由概念到維護和處置,包 含整個產品生命週期,在發展產品和服務時,期望改 善流程。接續發展組織的成功的 CMMI 模式,随著 CMMI 模式對發展組織的成功,對 CMMI 模式解決服 務產業的需要已被界定。 服務產業是全球經濟成長重要的推手。發展與改善成 熟服務實務的指引是績效、客戶滿意及經濟社群收益 的主要貢獻者。CMMI 服務模式(CMMI-SVC)即是為滿 足此需要而設計。 在 CMMI Steering Group 的同意下,Northrop Grumman 贊助並帶領產業的志願人士。這個小組,與 SEI 合 作 ,發展了服務群集的起始草案。 CMMI-SVC 1.2 版模式是自 CMMI1.2 版的架構與框架 產生出的最佳實務的集合。這個集合包含了從政府及 產業的服務最佳實務。CMMI-SVC 是基於「CMMI 糢 式基礎」或 「CMF 」(擧例,模式組件適用於所有 CMMI 模式及群集),也與數個服務組織合作,在服務 產業中採用 CMMI。 CMMI-SVC 模式提公服務提供者組織,應用 CMMI 最 佳實務指引。在此模式中的最佳實務主要焦點在提供 給客戶及最終使用者品質服務的活動。CMMI-SVC 整 合對服務提供者而言很重要的各類知識。 為提供服務,藉由整合各類知識,CMMI-SVC 提供各 類的最佳實務。適用於發展的 CMMI (CMMI-DEV)被 v 適用於服務的能力成熟度整合模式 1.2 版 致謝 視為是發展服務系統的參考,此服務系統是用來支援 服務交付[SEI 2006a]。在這些範例中,服務系統是 龐大且複雜的,而 CMMI-DEV 模式可用來有效地使用 在發展此類系統。(參見詞彙定義一節中「服務系 統」的定義) 許多菁英參與 CMMI 1.2 產品系列的產品團隊,三個主 要參與這個發展的群組是推動組、產品團隊、建構管 制委員會。 推動組指引及核准產品團隊的計畫,提供 CMMI 專案 重要議題的諮詢,確認包含各種不同有興趣的社群。 推動組監督服務群集的發展,瞭解到提供最佳實務範 例對服務提供者的重要性。推動組提供指引發展 CMMI-SVC 模式,並附有訓練教材。 產品團隊撰寫、審查、修訂、討論及認可 CMMI 產品 系列的架構及技術內容,包括架構、模式、訓練及評 鑑教材。發展活動是根據各種不同的來源。這些來源 包含推動組提供的每一份釋出文件的 A-規格與指引, 來源模式、自使用者端收到的變更請求,及自試用者 及其他關鍵人員所收到的意見。 服務諮詢組負責在產品小組最後發展 CMMI-SVC 階段 時,對重要的設計決定提供意見。包含來自服務產業 的專家,此小組確保產品小組的方向符合產業所需, 可跨越眾多形式的服務與組織。 參與發展 CMMI-SVC 1.2 版的各組人員,列於附錄 C。 CMMI-SVC 公布後,建構管制委員會是一個管理變更 的 正 式 機 制 , 對 於 所 有 的 CMMI 模 式 、 SCAMPI MDD、Introduction to CMMI 訓練課程變更的正式機 制。因此,此群組經由審查所有被提議的基準變更, vi 前言 讀者群 本文件的組織 適用於服務的能力成熟度整合模式 1.2 版 以及只核准滿足已界定議題及符合下一個版本準則的 變更,來確保產品系列生命週期的完整性。 CMMI-SVC 的讀者群包括任何在服務提供者環境中對 流程改善有興趣的人。無論你是否熟悉能力成熟度整 合模式的內容或是你正在尋求資訊以開始進行你的改 善工作,CMMI-SVC 都可供你使用。這模式亦可供欲 使用參考模式來進行服務相關流程評鑑的組織採用 1。 此份文件共含 3 部分: z 第一單元:關於適用於服務的 CMMI z 第二單元:一般目標、一般執行方法以及流程領域 z 第三單元:附錄與詞彙 第一單元,關於適用於服務的 CMMI,包含以下 5 章: z 第一章,「簡介」,提供 CMMI 與服務群集 2、流程 改善的概念、流程改善所使用的歷史模式以及不同 的流程改善方法的廣泛概觀。 z 第二章,「流程領域組件」,描述 CMMI-SVC 流程 領域下的所有組件。 z 第三章,「試著合而為一」,組合模式組件與解釋 成熟度等級及能力度等級的概念,以及描繪出重要 的服務概念。 1 評鑑是經由受過專業訓練之團隊針對一到多個流程進行審視,並使用一個參考模式(例如:CMMI-SVC) 來當做決定優勢與劣勢的基準 2 群集被定義成用於相關領域的架構模式、訓練教材及評鑑教材的組件集合(例如服務與發展) 前言 vii 適用於服務的能力成熟度整合模式 1.2 版 z 第四章,「流程領域間的關係」,對 CMMI-SVC 流 程領域的意義與互動關係提供更深的剖析。 z 第五章,「使用 CMMI 模式」,描述服務提供組織 導入與使用 CMMI-SVC 的路徑,進行流程改善及建 立標竿實務。 第二單元,「一般目標、一般執行方法以及流程領 域」,包含所有 CMMI 模式必要的及期望的組件。它 也包含相關有助益的組件,包括細部執行方法、註 釋、範例與典型的工作產品。 第二單元包含 25 節。第一節包含一般目標與一般執行 方法。其餘的 24 節,每一節都描述一個 CMMI-SVC 流程領域 3。 為了使這些流程領域容易找到,流程領域是以縮寫字 的字母順序排列。每一節均包含目標、最佳執行方法 與範例的描述。 第三單元「附錄」包含 4 個部份: z 附錄 A,「參考資料」,提供參考資訊以便你可以 找到有關於 CMMI-SVC 的原始紀錄,例如報告、流 程改善模式、產業標準及書籍等。 z 附錄 B,「縮寫字」,定義本模式中使用的縮寫 字。 z 附錄 C,「CMMI-SVC 專案的參與者」,包含參與 CMMI-SVC 1.2 版本發展的人員及組織名單。 z 附錄 D,「詞彙」,定義 CMMI-SVC 所使用的許多 術語。 viii 前言 如何使用本文件 適用於服務的能力成熟度整合模式 1.2 版 無論你是剛接觸流程改善與 CMMI,或是已經熟悉 CMMI,第一單元都可以幫助你瞭解為什麼 CMMISVC 是用來改善服務流程的最佳模式。 剛接觸流程改善的讀者 假如你不熟悉流程改善或是 CMM®的內容,我們建議 你先開始閱讀第一章,「簡介」。第一章將會給你一 個流程改善的整體概念,並且解釋 CMMI 是什麼。 接下來,瀏覽第二單元,包含一般目標、一般執行方 法和特定目標及特定執行方法,以察覺包含在此模式 下的最佳執行方法之範圍。將注意力放在每一節要開 始前的目的與簡介說明。 在第三單元,在開始使用 CMMI-SVC 時,仔細察看附 錄 A 的參考文獻以及挑選部份你認為有助於你閱讀的 額外原始資料。徹底閱讀縮寫字與詞彙以熟悉 CMMI 的用語,然後,回到第二單元做更細部的閱讀。 有流程改善經驗的讀者 假如你剛接觸 CMMI,但是有其它流程改善模式的經 驗,例如軟體能力成熟度模式或 ISO9000,你可以立即 認知到它們在結構和內容有許多相似之處。 我們建議你閱讀第一單元來瞭解 CMMI 與其它流程改 善模式的差異。若你已有其他模式的經驗,你可以選 擇想要先行閱讀的部份。簡略的閱讀第二單元中,你 已經試行過的模式中所瞭解的最佳執行方法。藉由確 前言 ix 適用於服務的能力成熟度整合模式 1.2 版 認熟悉的資料,可以讓你瞭解什麼是新的、什麼是現 在已經存在的,或你已經知道熟悉的內容。 接著下來,審視詞彙以瞭解相同名稱術語與你所知道 的流程改善模式的定義可能有差異。許多內容是重複 的,但是他們可能有些差異。 熟悉能力成熟度整合模式的讀者 假如你在之前已經審視或是使用過 CMMI 模式,你可 以很快的認識 CMMI 所討論的內容以及所呈現的最佳 執行方法。 額外資訊與讀者回饋 目前有許多 CMMI 的資料,例如 CMMI 模式的背景和 歷史,以及使用 CMMI 模式的好處。許多資料來源都 被 列 在 附 錄 A , 也 公 布 在 CMMI 網 站 — http://www.sei.cmu.edu/cmmi/。 歡迎任何有關改善 CMMI 的建議,有關如何提供回饋 的資訊,請參閱 CMMI 網站: http://www.sei.cmu.edu/cmmi/models/changerequests.html 。 如果有任何問題,請送電子郵件到 cmmi-comments@sei.cmu.edu x 前言 目錄 關於適用於服務的能力成熟度整合模式 1.2 版 前言……………………………………………………………………… i 目的…………………………………………………………………. v 致謝………………...……………………………………………... vi 讀者群............................................................................................... vii 本文件的組織................................................................................... vii 如何使用本文件................................................................................ ix 剛接觸流程改善的讀者........................................................... ix 有流程改善經驗的讀者........................................................... ix 熟悉能力成熟度整合模式的讀者............................................ x 額外資訊與讀者回饋........................................................................ x 第一單元: 適用於服務的能力成熟度整合模式............................................................. 15 1 簡介..............................................................................................16 有關能力成熟度模式.................................................................16 能力成熟度整合模式的演進.....................................................19 能力成熟度整合模式架構.........................................................19 適合於服務的能力成熟度整合模式.........................................20 2 流程領域組件 - 必要的、期望的與有助益的組件...................23 必要的組件.................................................................................23 期望的組件.................................................................................23 有助益的組件.............................................................................24 第二單元相關的組件........................................................................24 流程領域.....................................................................................25 目的.............................................................................................26 簡介.............................................................................................26 相關流程領域.............................................................................26 特定目標.....................................................................................27 一般目標.....................................................................................27 特定目標與執行方法摘要.........................................................27 特定執行方法.............................................................................28 典型的工作產品.........................................................................28 細部執行方法.............................................................................28 一般執行方法.............................................................................29 一般執行方法的詳細說明.........................................................29 補充.............................................................................................30 支援助益的組件................................................................................30 註釋.............................................................................................30 目錄 11 適用於服務的能力成熟度整合模式 1.2 版 範例............................................................................................... 31 參考資料....................................................................................... 31 編碼系統.............................................................................................… 32 印刷慣例...........................................................................................….. 32 3 試著合而為一………………………………………………….….. 35 瞭解等級........................................................................................... 35 連續式與階段式表述的結構........................................................... 36 瞭解能力度等級............................................................................... 39 能力度第 0 級:不完整級…………………………………….. 40 能力度第 1 級:執行級.............................................................. 40 能力度第 2 級:管理級.............................................................. 40 能力度第 3 級:調適級.............................................................. 40 能力度第 4 級:量化管理級...................................................... 41 能力度第 5 級:最佳化級.......................................................... 41 能力度等級的進展...................................................................... 42 瞭解成熟度等級............................................................................... 43 成熟度第 1 級:初始級.............................................................. 44 成熟度第 2 級:管理級.............................................................. 44 成熟度第 3 級:調適級.............................................................. 45 成熟度第 4 級:量化管理級...................................................... 46 成熟度第 5 級:最佳化級.......................................................... 46 成熟度等級的進展...................................................................... 47 流程領域........................................................................................... 48 對等的階段式................................................................................... 53 使用 CMMI-SVC 時該瞭解的關鍵概念......................................... 58 服務.............................................................................................. 58 服務系統...................................................................................... 59 服務協議...................................................................................... 62 服務請求...................................................................................... 62 服務事故...................................................................................... 63 專案.............................................................................................. 64 4 流程領域間的關係……………………………………………….. 67 驅動服務建立與交付的關係........................................................... 68 驅動服務管理的關係....................................................................... 69 5 採用能力成熟度整合模式............................................................... 71 你的流程改善計畫........................................................................... 72 影響你計畫的選擇........................................................................... 72 能力成熟度整合模式....................................................................... 73 使用能力成熟度整合模式的評鑑................................................... 74 能力成熟度整合模式的評鑑需求................................................... 75 SCAMPI 評鑑方法........................................................................... 75 12 目錄 關於適用於服務的能力成熟度整合模式 1.2 版 評鑑考量....................................................................................... 76 能力成熟度整合模式的相關訓練............................................... 77 第二單元: 一般目標與一般執行方法及流程領域..........................................................79 總覽................................................................................................... 80 流程制度化....................................................................................... 80 已執行流程................................................................................. 81 已管理流程................................................................................. 81 已調適流程................................................................................. 82 量化管理流程............................................................................. 83 最佳化流程................................................................................. 84 流程間的關係............................................................................. 85 一般目標及一般執行方法............................................................... 86 應用一般執行方法......................................................................... 172 支援特定執行方法的流程領域..................................................... 172 容量與可用度管理................................................................................... 179 原因分析與解決方案............................................................................... 200 建構管理................................................................................................... 212 決策分析與解決方案............................................................................... 227 整合的專案管理....................................................................................... 238 事故解決方案與預防............................................................................... 263 度量與分析............................................................................................... 283 組織創新與推展....................................................................................... 303 組織流程定義........................................................................................... 322 組織流程專注........................................................................................... 339 組織流程績效........................................................................................... 356 組織訓練................................................................................................... 368 專案監控................................................................................................... 382 專案規劃................................................................................................... 395 流程與產品品質保證............................................................................... 429 量化專案管理........................................................................................... 437 需求管理................................................................................................... 461 風險管理................................................................................................... 470 供應商協議管理....................................................................................... 491 服務持續性............................................................................................... 510 服務交付................................................................................................... 527 服務系統發展........................................................................................... 553 服務系統移轉........................................................................................... 585 策略服務管理........................................................................................... 599 目錄 13 適用於服務的能力成熟度整合模式 1.2 版 第三單元: 附錄............................................................................................................. 612 附錄 A:參考書目......................................................................................613 附錄 B. 縮寫字...........................................................................................617 附錄 C: 適用於服務的能力與成熟度整合模式專案參與人員.............623 CMMI-SVC 1.2 版模式團隊.......................................................... 623 CMMI-SVC 1.2 版 訓練團隊......................................................... 624 CMMI-SVC 1.2 版 品質團隊......................................................... 625 CMMI 服務顧問諮詢委員會......................................................... 625 CMMI 推動組................................................................................. 626 推動組成員............................................................................... 626 官方推動組成員........................................................................ 626 推動組支援:採購.................................................................... 627 推動組支援:建構管制委員會................................................ 627 附錄 D:詞彙..............................................................................................628 14 目錄 關於適用於服務的能力成熟度整合模式 1.2 版 第一單元:適用於服務的能力成熟度整合模式 簡介 15 適用於服務的能力成熟度整合模式 1.2 版 1 簡介 服務產業是推動世界經濟成長的重要推手。發展及改 善成熟的服務實務是展現績效、客戶滿意及經濟社群 獲利的關鍵。適用於服務的能力成熟度整合模式 (CMMI-SVC)即為此需要而設計。 CMMI-SVC 有 24 個流程領域。其中包括 16 個基礎流 程領域、7 個服務流程領域及 1 個附加。(進一步參閱 第 2 章的「附加」) 所有的 CMMI-SVC 模式均專注於服務提供者的活 動。7 個流程領域專注於服務的執行方式,說明容量 與可用度管理、服務持續性、服務交付、事故解決方 案與預防、服務轉換、服務系統發展及策略服務管理 流程。 有關能力成熟度模式 在 SEI 的協助組織發展與維護品質產品及服務的研究 中,SEI 發現組織可以專注改善經營的數個面向。圖 1.1 說明組織一般會專注的 3 個重要面向:人員、程 序與方法,以及工具與設備。 16 目錄 關於適用於服務的能力成熟度整合模式 1.2 版 圖 1.1:3 個重要的面向 但是什麼將一切都結合在一起呢?答案是你組織中所使 用的流程。流程允許你調校你執行的經營方式,允許你 解決擴大規模,並提供一個方式,將知識融入,使事情 做得更好。流程允許你善用你的資源與檢視經營趨勢。 這不是說人員與技術不重要。我們現今生活的世界,技 術每幾年就會有一定程度的改變。同樣地,人員在事業 生涯中一般會在多家企業工作。我們生活在一個動態的 世界。專注於流程,提供了處理在變動的世界中所需要 的基礎建設與穩定性,也使得人員的生產力可以擴大, 並且使用技術,讓自身更具競爭力。 製造業早就認知到流程的效果與效率之重要性。今日, 許多製造業與服務業已認知到品質流程的重要性。流程 藉由協助人員更聰明地工作,而非費力地工作,以及一 致性的改善,來幫助組織人員達成經營目標。有效的流 程也是一個提供導入與使用新技術的載具,以達成組織 的經營目標。 簡介 17 適用於服務的能力成熟度整合模式 1.2 版 在 1930 年代,瓦特.蕭華德開始利用統計品質管制原 理,致力於流程改善 [Shewhart 1931]。這些原理被威 廉.愛德華.戴明[Deming 1986]、菲力普.克勞斯比 [Crosby 1979]、約瑟夫.朱蘭[Juran 1988]重新調整。瓦 玆 . 韓 福 瑞 [Watts Humphrey] 、 羅 恩 . 雷 迪 斯 [Ron Radice]及其它人開始延伸這些原理,導入在 IBM 與 SEI 韓福瑞[Humphrey 1989]的軟體工作中。韓福瑞的書「管 理軟體流程,Managing the Software Process」提出基本 原理與觀念的描述,有許多成為能力成熟度模式(CMM) 的基礎。 SEI 認定流程管理的前提是「一個系統或產品的品質會 高度受到發展與維護它的流程品質影響」,並且定義 CMMs 來具體化這個前提。這個前提裡的信念在全世界 的品質活動中都可以得見,國際標準組織/國際電子技術 委員會(ISO/IEC)標準的內容就是一個證據。 能力成熟度模式專注於改善組織的流程。它們包含一到 多個原則中有效率流程的必要元素,並且描述由特定 的、不成熟的流程到有組織的、成熟的流程的品質改善 與效率。 SEI 首先針對軟體組織設計了第一套能力成熟度模式, 並 出 版 一 本 書 「 The Capability Maturity Model: Guidelines for Improving the Software Process 」 [SEI 1995]。 如今,能力成熟度模式是一個幾乎在一個世紀以前的原 理應用在持續不斷的流程改善循環中。這個流程改善方 法的價值已經通過時間考驗。組織已有了提升生產力與 品質、改善產品時程,以及更精確與可預測時程與預算 的經驗[Gibson 2006] 。 18 目錄 關於適用於服務的能力成熟度整合模式 1.2 版 能力成熟度整合模式的演進 圖 1.2 說明已整合到 CMMI 1.2 版的模式。發展一套 整合的模式不只包含結合現行的模式材料。使用可以 提昇共識的流程,CMMI 產品小組建立了一個框架可 適用於不同的群集。 History of CMMs CMM for Software V1.1 (1993) INCOSE SECAM (1996) Systems Engineering CMM V1.1 (1995) Software CMM V2, draft C (1997) Software Acquisition CMM V1.03 (2002) EIA 731 SECM (1998) Integrated Product Development CMM (1997) CMMI for Acquisition V1.2 (2007) Vv11..0022 ((22000000)) Vv1.1 (2002) CMMI for Development V1.2 (2006) CMMI for Services V1.2 (2009) 圖 1.2 能力成熟度模式之歷程1 能力成熟度整合模式架構 CMMI 能力成熟度整合模式架構提供產生能力成熟度 整合 CMMI 模式、教育訓練及評鑑組件所需的結構。 為了允許使用能力成熟度整合 CMMI 架構中不同的模 式,模式組件被分類為一般適用於所有能力成熟度整 合 CMMI 模式或適用於特定模式。而一般模式組件被 稱為「能力成熟度整合 CMMI 模式基礎」或 「CMF」。 1 EIA 731 SECM 是電子產業聯盟標準 731, 或系統工程能力度模式。INCOSE SECAM 是系統工程能力 評估模式國際聯盟(EIA 2002)。 簡介 19 適用於服務的能力成熟度整合模式 1.2 版 CMF 的組件對於從能力成熟度整合模式 CMMI 框架 產生的每一個模式都是必要的部份。那些組件和材料 結合,則適用於特定領域(例如:服務、發展)而產 生出一個模式。有些材料是各領域共享,有些是只針 對一個領域。 「群集」是指組件的集合用來建構某個興趣領域(例 如:服務、發展)的模式、訓練教材及評鑑材料。在服 務群集所使用的模式的名稱會以「 適用於服務的能力 成熟度整合模式」或「CMMI-SVC」作為開頭。 適合於服務的能力成熟度整合模式 CMMI-SVC 自 CMMI 與其他著重在服務的標準及模 式中提出概念與執行方式,包括: • Information Technology Infrastructure Library (ITIL) • ISO/IEC 20000: Information Technology—Service Management • Control Objects for Information and related Technology (CobiT) • Information Technology Services Capability Maturity Model (ITSCMM) • Information Technology Infrastructure Library (ITIL) • ISO/IEC 20000: Information Technology—Service Management • Control Objects for Information and related Technology (CobiT) • Information Technology Services Capability Maturity Model (ITSCMM) 熟悉這些以服務為導向的模式和標準,並不需要以瞭 解 CMMI-SVC, 而 CMMI-SVC 這個群集也不是用來 確認他們的架構。然而,這些標準和模式的知識提供 對 CMMI-SVC 模式和內容更豐富的瞭解。 20 目錄 關於適用於服務的能力成熟度整合模式 1.2 版 服務群集包含建立、交付與管理服務所需的活動。如 同在 CMMI 內容中所定義的,服務只是無形的、不可 儲存的產品。而 CMMI-SVC 已被發展到適用於更廣 泛的定義,CMMI-SVC 的目標與執行方法也因而與組 織所關心的服務的交付有潛在的相關,包括如國防、 資訊技術、健康照護、金融和交通等領域的企業。 CMMI-SVC 早期的使用者在其發展和試行階段的報 告,交付的服務十分不同就像訓練、運籌、維護、庇 護、草坪照顧、書籍分類、研究、諮詢、稽核、獨立 驗證與確認、人力資源、財務管理、健康管理與資訊 技術服務等。 服務群集包含專案管理、流程管理、服務建立、服務 交付與支援、支援的流程等執行方法。所有的 CMMI-SVC 模式採用其他群集的 CMMI 模式的許多 資料。因此,若熟悉其他的 CMMI 群集,也會發現 CMMI-SVC 內容許多相似之處。 在 CMMI-SVC 內容中, 「專案」係涵括所有滿足與 客戶的服務協議的資源。因此,在這內容中專案管理 的概念即近似其他標準與模式中的服務管理,雖然可 能無法完全一致。 組織有興趣評估與改善流程以發展交付服務的系統, 可以使用 CMMI-DEV 模式。此方式特別建議給組織 已使用 CMMI-DEV,或為交付服務必須發展與維護 複雜的系統。然而,CMMI-SVC 模式提供另一項替代 方案,以更直接的方式評估與改善服務系統的發展, 這可能較適合在特定內容。 簡介 21 2 流程領域組件 關於適用於服務的能力成熟度整合模式 1.2 版 這一章說明每一個流程領域、一般目標與一般執行方 法的組件。瞭解這些組件的意義,對於有效使用第二 單元的資訊是重要的。假如你不熟悉第二單元,在閱 讀本章之前,你可能要快速瀏覽一般目標與一般執行 方法的章節以及相關流程領域的章節,以針對內容與 版面編排取得一般性的理解。 必要的、期望的與有助益的組件 CMMI 模式組件被群組成三個類型—必要的、期望的 與有助益的—反映出如何解釋它們。 必要的組件 必要的組件是說明一個組織要滿足某一個流程領域所 需要達成的成果。這個成果必須很明顯地被一個組織 的流程所執行。必要的模式組件在 CMMI 中是特定目 標及一般的目標。目標滿足是在評鑑中決定某流程領 域是否有達成的基礎。 期望的組件 期望的組件說明一個組織要達成某一個必要的組件所 需要執行的作法。期望的組件用來指引要執行改善或 評鑑的個人與團體。期望的組件在 CMMI 中是特定與 一般的執行方法。 在目標被認定已滿足之前,執行方法或其可行的替代 方案,都必須表現於組織已規劃和已實行的流程之 內。 流程領域組件 23 適用於服務的能力成熟度整合模式 1.2 版 有助益的組件 助益的組件提供細部描述以協助組織瞭解必要的組件 與期望的組件。細部執行方法、典型的工作產品、一 般執行方法詳細說明、目標和執行方法的標題、目標 和執行方法的註解、範例及參考資料都是助益的模式 組件的例子。 CMMI 的詞彙並不是 CMMI 模式之必要的、期望的及 助益的組件。你必須以詞彙中之術語在模式組件出現 時的上下文來詮釋它的意義。 第二單元相關的組件 與第二單元有關的模式組件彙總如圖 2.1 所示說明它 們的關係。 圖 2.1 能力成熟度整合模式的組件 下面章節提供 CMMI 模式組件的詳細說明。 24 流程領域組件 流程領域 關於適用於服務的能力成熟度整合模式 1.2 版 流程領域是一個領域下相關執行方法的集合,當它們 共同執行時,滿足一系列視為對改善該領域是重要的 目標。 流程領域組件 有 24 個流程領域以首字母縮寫方式依序排列: • 容量與可用度管理(CAM) • 原因分析與解決方案(CAR) • 建構管理(CM) • 決策分析與解決方案(DAR) • 整合專案管理(IPM) • 事故解決方案與預防(IRP) • 度量與分析(MA) • 組織創新與推展(OID) • 組織流程定義(OPD) • 組織流程專注(OPF) • 組織流程績效(OPP) • 組織訓練(OT) • 專案監控(PMC) • 專案規劃(PP) • 流程與產品品質保證(PPQA) • 量化專案管理(QPM) • 需求管理(REQM) • 風險管理(RSKM) • 供應商協議管理(SAM) • 服務持續性(SCON) 25 適用於服務的能力成熟度整合模式 1.2 版 目的 • 服務交付(SD) • 服務系統發展(SSD)2 • 服務系統移轉(SST) • 策略服務管理(STSM) 目的說明流程領域的目的,是助益的組件。 例如,組織流程定義流程領域的目的是「組織流程定 義(OPD)的目的是建立與維護一套可以使用的組織流 程資產與工作環境標準」。 簡介 流程領域的簡介是說明流程領域所涵蓋的主要觀念, 是有助益的組件。 例如,在專案規劃流程領域的簡介例子是「規劃始於 定義產品及專案的需求」。 相關流程領域 相關流程領域列出與流程領域有關的流程領域參考資 料,並反映流程領域間高層級的關係。相關流程領域 是有助益的組件。 專案規劃流程領域之相關流程領域章節的參考資料例 子「有關界定與分析風險,請參考風險管理流程領 域,以獲得更多的資訊」。 5「流程領域」是在一個區域中相關連的最佳執行方法群集,當被共同實行時,會滿足一組被認為重 要且具有顯著改善該區域的目標。我們將會在第 2 章詳述這個概念。 26 流程領域組件 特定目標 關於適用於服務的能力成熟度整合模式 1.2 版 特定目標描述必須用來滿足該流程領域唯一的特徵。 特定目標是必要的模式組件以及被使用在評鑑中判斷 某個流程領域是否滿足。 例如,建構管理流程領域的其中一個特定目標是「建 立與維護基準的完整性」。 只有特定目標下的說明是必要的模式組件。特定目標 的標題(前有目標編碼)與該目標有關的任何註釋視 為有助益的模式組件。 一般目標 一般目標之所以稱為「一般」是因為相同的目標說明 可適用於多個流程領域。一般目標描述必須能夠呈現 執行流程領域流程制度化的特徵。一般目標是必要的 模式組件,被使用在評鑑中判斷一個流程領域是否滿 足。(一般目標與一般執行方法的詳細描述,請參考 一般目標與一般執行方法章節)。 一般目標的例子是「流程制度化為已定義流程」。 只有一般目標下的說明是必要的模式組件。一般目標 的標題(前有目標編碼)及任何與目標有關的註釋被 視為助益的模式組件。 流程領域組件 特定目標與執行方法摘要 特定目標與執行方法摘要提供特定目標高層的摘要。 特定目標是必要的組件,特定執行方法是期望的組 件,特定目標與執行方法摘要是有助益的組件。 27 適用於服務的能力成熟度整合模式 1.2 版 特定執行方法 特定執行方法是一種活動的說明,它對達成相關的特 定目標是重要的。特定執行方法說明達成流程領域特 定目標期望結果的活動。特定執行方法是期望的模式 組件。 例如,專案監控流程領域的一個特定執行方法是「依 專案計畫所界定的承諾,監督承諾」。 只有特定執行方法下的說明是期望的模式組件。特定 執行方法的標題(前有執行方法編碼)及任何與該特 定執行方法有關的註釋,被視為有助益的模式組件。 典型的工作產品 典型的工作產品章節列出特定執行方法所產出的範 例。這些範例稱之為「典型的工作產品」,是因為除 了這些具代表性的範例之外,還有其他的工作產品也 是有效的,但未被列出。典型的工作產品是有助益的 模式組件。 例如,專案監控流程領域中特定執行方法「監督專案 規劃參數的實際值」的一個典型的工作產品是「重大 偏差的紀錄」。 細部執行方法 細部執行方法是一個詳細說明,提供解釋與執行特定 或一般執行方法的指引。細部執行方法可能以規範的 28 流程領域組件 關於適用於服務的能力成熟度整合模式 1.2 版 文字描述,但是實際上是一個助益的模式組件,只提 供可用於流程改善的想法。 例如,專案監控流程領域中特定執行方法「採取矯正 行動」的一個細部執行方法是「決定與文件化所需解 決已界定議題的適當行動」。 一般執行方法 一般執行方法之所以稱為「一般」是因為相同的執行 方法可適用於多個流程領域。一般執行方法被視為達 成相關的一般目標之重要活動。一般執行方法是期望 的模式組件。 例如,一般目標「流程制度化為已管理的流程」下之 一般執行方法「提供足夠的資源執行流程、發展工作 產品與提供流程服務」。 只有一般執行方法的說明是期望的模式組件。特定執 行方法的標題(前有執行方法編碼)與該執行方法有 關的任何註釋,被視為有助益的模式組件。 一般執行方法的詳細說明 一般執行方法詳細說明是助益的模式組件,它出現在 一般執行方法之後,提供指引以說明一般執行方法要 如何應用於流程領域。 例如,一般執行方法詳細說明出現在一般執行方法之 後,專案規劃流程領域的一般執行方法「建立與維護 規劃與執行專案規劃流程的組織政策」的詳細說明是 「這個政策建立估計規劃參數,決定內部與外部承 諾,與發展管理專案計畫的組織期望」。 流程領域組件 29 適用於服務的能力成熟度整合模式 1.2 版 補充 補充可以是有助益的內容、特定執行方法、特定目標 或是流程領域,以延伸模式範圍或強調使用上的特定 觀點。在本文件中,所有的附加都與服務系統發展流 程領域相關。 服務系統發展流程領域是一個附加。另一個附加的範 例是在整合專案管理流程領域的參考資料,在特定執 行方法 1.1,細部執行方法 6 出現「在專案定義流程 執行同仁審查」。此附加描述: 「有關執行同仁審 查,請參考服務系統發展流程領域,以獲得更多的資 訊。」 支援助益的組件 在很多地方,需要進一步的資料來描述一個概念。這 種助益的資料是以下列組件方式提供: • 註釋 • 範例 • 參考資料 註釋 註釋是緊密附帶在任何其它模式組件的文字。它可能 提供細節、背景或原由。註釋是助益的組件。 例如,在原因分析與解決方案流程領域中,伴隨特定 執行方法「實行行動建議」的註釋是「只有證明為有 價值的變更才應該被考慮廣泛實行」。 30 流程領域組件 範例 關於適用於服務的能力成熟度整合模式 1.2 版 範例包含文字與項目清單的組件,通常用框線加以區 隔。範例會緊密附帶在任何其它組件中,並提供更多 的例子,以釐清觀念或說明活動。範例是助益的組 件。 下面在流程與產品品質保證流程領域中,伴隨在細部 執行方法「當它們在專案中無法解決時,文件化無法 遵循的爭議」下之特定執行方法「溝通,並確保無法 遵循的爭論已解決」的範例。 解決專案中無法遵循爭論之方法的範例: ● 修正不符合。 ● 變更所違反的流程描述、標準或程序。 ● 取得無法遵循的豁免書。 參考資料 參考資料是指到相關流程中附加或是更詳細的資訊。 參考資料會緊密伴隨在任何其它模式組件。參考資料 是助益的模式組件。 例如,在量化專案管理流程領域的特定執行方法「穩 定巳定義流程流程」下,所伴隨的參考資料「有關組 織流程資產館,應該包含已知與所需能力的流程元 件,請參考組織流程定義流程領域,以獲得更多的資 訊」。 流程領域組件 31 適用於服務的能力成熟度整合模式 1.2 版 編碼系統 特定及一般目標以流水號的方式編碼。每一個特定目 標的編碼以 SG 開頭(例如:SG1)。每一個一般目標的 編碼以 GG 開頭(例如:GG2)。 特定與一般的執行方法也以流水號的方式編碼。每個 特定執行方法的編碼以 SP 開頭,其後有數字 x.y (例 如:SP 1.1)。x 對應特定目標的編號,而 y 是特定目 標之下特定執行方法的序號。 以專案規劃流程領域的特定執行方法編碼為例,第一 個執行方法的編碼是 SP 1.1,第二個是 SP 1.2。 每個一般執行方法的編碼以 GP 開頭,其後有 x.y (例 如:GP 1.1)。 x 是對應一般目標的編號,y 則是一般目標之下一般 執行方法的序號。例如,GG2 下的第一個一般執行方 法的序號是 GP2.1,第二個是 GP2.2。 印刷慣例 本模式的印刷慣例是設計來協助你有效地選擇與使用 你所需要的部份。我們描述的模式組件格式允許你在 頁面中快速地找到它們。 圖 2.2 和 2.3 是第二單元中流程領域的範例頁面。它 們顯示不同的流程領域組件,並以標記讓你可以識別 它們。注意組件在印刷上的差異,你就可以容易地識 別出每一個。 32 流程領域組件 流程領域名 流程領域類別 簡介 關於適用於服務的能力成熟度整合模式 1.2 版 成熟度等級 目的 流程領域組件 圖 2.2: 決策分析與解決方案之範例頁 33 適用於服務的能力成熟度整合模式 1.2 版 特定目標 特定執行方式 細部執行方式 說明 說明 一般工作 產品 範例箱 參考 圖 2.3: 原因分析與解決方案之範例頁 34 流程領域組件 關於適用於服務的能力成熟度整合模式 1.2 版 3.試著合而為一 既然已經向您介紹 CMMI 模式的組件,你需要瞭解它 們如何合而為一,以符合你的流程改善需要 。在本章 中,我們介紹等級的概念並說明如何組織與使用流程 領域。也討論在服務相關工作中導入 CMMI 模式的幾 個重要概念。 CMMI-SVC 沒有特別說明一個專案或組織必須遵循特 定的流程,或每天必須交付一定數量的服務或必須達 成特定的績效目標-而只是現有的流程足夠地解決服 務相關的執行方法。為決定現行的流程是否足夠,專 案或組織須將其流程對照到本文件的流程領域。 將流程對照到流程領域可使服務提供者追踪,在導入 流程時是符合 CMMI-SVC 模式。並不企圖每一個 CMMI-SVC 的流程領域可以套用到組織或專案的一個 流程。 瞭解等級 CMMI 使用等級,說明組織建議的演進途徑,組織想 要改善發展與維護產品與服務的流程。等級也是評鑑 3中評等活動的產出。評鑑可以在全公司(通常是小 型)或是小群組中執行,小群組就像是專案群組或是 公司內的一個部門。 CMMI 支援兩種改善途徑。一個途徑是針對組織所選 擇的一個流程領域(或多個流程領域),使組織能夠 漸進地改善流程。另一個途徑是組織漸進地解決連續 的一組流程領域,使組織改善一組相關的流程。 3有關評鑑,參考 CMMI 評鑑需求及流程改善定義文件之標準 CMMI 評鑑方式(SEI 2006C, SEI2006B) 試著合而為一 35 適用於服務的能力成熟度整合模式 1.2 版 這兩種改善途徑與 2 種等級類型有關:能力等級與成 熟等級。這些等級對應到「表述(representations)」流 程改善的 2 個方式。這 2 個表述使用的兩種等級類型 有關連。對於連續式表述,我們使用術語「能力度等 級」。對於階段式表述,我們使用術語「成熟度等 級」。 無論你選擇哪一種表述,等級的概念都是相同的。等 級改善的特徵從一個不清楚定義的狀態到使用量化資 訊決定與管理改善的狀態,這個改善必須符合組織經 營目標 為達到一個特定等級,組織必須滿足一個流程領域或 一組流程領域中所有適當的目標。無論是能力度等級 或是成熟度等級,它們被當做改善的目標。 這兩種表述也提供執行流程改善方法,以達到經營目 標。這兩種表述提出相同的必要內容與使用相同的模 式組件。 連續式與階段式表述的結構 圖 3.1 說明連續式與階段式表述的結構。當你看到這 兩種表述的架構,對您而言立刻注意到其差異。階段 式表述使用成熟度等級,然而連續式表述使用能力度 等級。 36 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 試著合而為一 圖 3.1 連續式與階段式表述的結構 在你比較這兩種表述的相似性後,有什麼是讓你有印象 的。這兩種表述有許多相似的組件(例如:流程領 域、特定目標與特定執行方法),並且這些組件有相 同的層級與結構。 37 適用於服務的能力成熟度整合模式 1.2 版 圖 3.1 從高層觀點中來看,並不明顯的是連續式表述 專注在以能力度等級度量的流程領域能力,以及階段 式表述專注在以成熟度等級度量的組織成熟度。這些 CMMI 面向(能力度/成熟度)係使用在標竿學習與評 鑑活動,並且指引組織的改善工作。 • 能力度等級應用於個別流程領域的組織流程改善的 達成。這些等級是一個能在該流程領域增加改善流 程的方式。有六個能力度等級,編號為 0 到 5。 • 成熟度等級,應用於跨流程領域的組織流程改善的 達成。這些等級是預測下一個執行的專案之一般產 出的方式。有五個成熟度等級,編號為 1 到 5。 表 3.1 為六個能力度等級與五個成熟度等級的比較。 注意到這兩種表述中,有 4 個等級的名稱是相同的。 差異之處在於階段式表述並沒有成熟度第 0 級,而在 第 1 級,能力度等級稱之為「已執行的 (performed) 」,而成熟度等級則稱為「起始級 (initial) 」。所以,其開始點是不同的。 表 3.1:能力與成熟度等級的比較 等級 連續式表述的能力 階段式表述的成熟 度等級 度等級 等級 0 不完整級 無 等級 1 執行級 初始級 等級 2 管理級 管理級 等級 3 調適級 調適級 等級 4 量化管理級 量化管理級 等級 5 最佳化級 最佳化級 38 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 連續式表述著眼於選擇特定的流程領域進行改善,以 及該流程領域期望的能力度等級。在這個背景下,一 個流程是否是已執行或不完整是重要的。所以,名稱 「不完整」做為連續式表述的開始點。 由於階段式表述關心組織的整體成熟度,無論個別流 程是已執行或不完整都不是主要焦點。所以,名稱 「初始」做為階段式表述的開始點。 能力度等級與成熟度等級兩者均提供一個度量方式, 以度量組織能夠且實行改善他們的流程到多好。然 而,流程改善的相關方法是不同的。 瞭解能力度等級 為支援使用連續式表述,所有的 CMMI 模式在它們的 設計與內容中反映能力度等級。 有六個能力度等級,標示由編號 0 到編號 5 如下: 0 不完整級 1 執行級 2 管理級 3 調適級 4 量化管理級 5 最佳化級 當一般目標均被滿足時,流程領域的能力度等級即達 成。事實上,能力度等級第 2 級到第 5 級有意地使用 與一般目標 2 到 5 相同的術語,因為每一個一般目標 與執行方法反映出目標與執行方法的能力度等級的意 義(關於一般目標與執行方法的更多資訊,請參看第 試著合而為一 39 適用於服務的能力成熟度整合模式 1.2 版 2 單元一般目標與一般執行方法段落)。每一個能力 度等級簡短說明如下: 能力度 0 級: 不完整級 「不完整流程」是指一個沒有執行或部分執行的流 程。無法滿足流程領域的一個或多個特定目標,以及 因為沒有制度化部分執行流程的理由,這個等級沒有 一般目標。 能力度第 1 級:執行級 能力度第 1 級流程特徵為「已執行流程」。已執行流 程是滿足流程領域特定目標的流程,它支援與促使所 需的工作提供服務。 由能力度第 1 級所導致的重大改善可能會隨著時間而 失去,因為它們沒有被制度化。應用制度化(CMMI 能力度第 2 級到第 5 級的一般執行方法)可以確保維 持改善。 能力度第 2 級:管理級 能力度第 2 級流程特徵為「已管理流程」。已管理流 程是一個已執行的流程(能力度第 1 級),具有基本的 基礎建設支援流程。它會根據政策規劃與執行流程; 任用具備技能的人員,並給予足夠的資源以產出可控 制的產品;納入相關的關鍵人員;監督、控制及審 查;並評估遵循流程說明的程度。能力度第 2 級所反 映的流程規範,確保現有的執行方法能在有時間壓力 的情況下,仍維持運作。 能力度第 3 級:調適級 能力度第 3 級流程特徵為「已調適流程」。已調適流 程是一個已管理流程(能力度第 2 級),是根據組織 40 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 的調適指引調適組織標準流程而得,並提供工作產 品、度量與其他流程改善資訊至組織流程資產。 能力度第 2 級與第 3 級間的重要差異在標準、流程說 明與程序的範圍。在能力度第 2 級中,每一個流程特 定案例(例如,特定專案)中標準、流程說明與程序可 能頗有差異。能力度第 3 級,專案的標準、流程說明 與程序是由組織標準流程中調適而得,以符合特定專 案或組織單位。除了調適指引允許的差異外,因而更 具一致性。 在能力度第 3 級的其他重要差異是,流程通常敍述的 比能力度第 2 級還要嚴謹。一個已調適流程清楚地說 明目的、輸入、允入準則、活動、角色、度量、驗證 步驟、產出物及允出準則。在能力度第 3 級中,透過 瞭解流程活動之互動關係及工作產品與流程的詳細度 量,更主動地管理流程。 能力度第 4 級:量化管理級 能力度第 4 級流程特徵為「已量化管理流程」。已量 化管理流程是一個已調適流程(能力度第 3 級),使用 適當的統計和其它量化的技術進行控制。建立品質和 流程績效的量化目標,並以該目標為管理流程的準 則。以統計的術語瞭解品質和流程績效,並在整個流 程生命週期受到管理。 試著合而為一 能力度第 5 級:最佳化級 能力度第 5 級流程特徵為「最佳化流程」。最佳化流 程是一個已量化管理流程(能力度第 4 級),利用瞭解 流程中的共同變異原因,改善流程。最佳化流程以漸 進與創新的改善,專注於持續改善流程績效。 41 適用於服務的能力成熟度整合模式 1.2 版 記住,能力度第 2 級到第 5 級使用相同的一般目標 2 到 5 的術語,這些術語的詳細說明,顯示在第 2 單元 的一般目標與一般執行方法段落。 能力度等級的進展 流程領域能力度等級的達成,是憑藉一般執行方法或 在流程領域中相關流程之適當替代方案的應用。 達到一個流程領域之能力度第 1 級,等同於說該流程 領域相關的流程是「已執行流程」。 達到一個流程領域之能力度第 2 級,等同於說有政策 可以指出你會執行這個流程。有執行計畫、提供資 源、指派責任、執行訓練、控制執行流程相關之所選 擇的工作產品等等。換句話說,一個能力度第 2 級的 流程是有規劃與監督的,就像任何專案或支援活動一 樣。 達到一個流程領域的能力度第 3 級,被認為有一個組 織標準流程存在於流程領域中,並且可以根據專案需 要調適。因為它們根據組織標準流程調適,所以組織 流程更具一致性的定義與應用。 達到一個流程領域的能力度第 4 級,認為這個流程領 域是一個關鍵的經營驅力,此驅力是組織想要使用量 化與統計技術執行管理。這個分析使組織對所選擇之 子流程的績效更加透明,使組織在市場上更有競爭 力。 達到一個流程領域的能力度第 5 級,是認為你所選擇 的子流程穩定,並且你想要降低流程的共同變異原 因。記住,變異在任何流程中是自然發生的,因此雖 然改善所有流程在概念上是可行的,但是將所有流程 都改善至第 5 級是不經濟的。再說一次,你將專注於 那些會幫助你,符合你經營目標的流程。 42 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 瞭解成熟度等級 為支援使用階段表述,所有的 CMMI 模式在其設計與 內容中反映成熟度等級。成熟度等級包含預先定義的 一組流程領域與相關的特定與一般執行方法,以改善 組織整體績效。組織的成熟度等級提供一個方式,在 一個專案領域或是一組專案領域下,預測組織績效。 當組織流程改善工作專注於可管理數目的流程領域, 而且組織改善逐漸增加那些領域的熟練度,經驗顯示 組織會做到最好。 成熟度等級在組織流程改善中是一個已定義的演進水 準。每一個成熟度等級會使一個重要的組織流程子集 合變得成熟,為提升到下一個成熟度做準備。憑藉達 成度量成熟度等級預先定義的一組流程領域中特定與 一般目標。 有五個成熟度等級,每一個等級都是進行下一個等級 的基礎,標示由編號 1 到 5: 1. 初始級 2. 管理級 3. 調適級 4. 量化管理級 5. 最佳化級 試著合而為一 記住,成熟度第 2 級到第 5 級使用相同術語,如同能 力度第 2 到第 5 級。這是有意的,因為成熟度等級與 能力度等級的概念是互補的。成熟度等級的使用特徵 43 適用於服務的能力成熟度整合模式 1.2 版 為一組相關流程領域的組織改善,而能力度等級特徵 為個別流程領域的組織改善。 成熟度第 1 級:初始級 在成熟度第 1 級中,流程通常是特製的且混亂的。組 織通常沒有提供穩定的環境維持流程。這些組織的成 功,往往依賴組織成員的能力與英雄主義,而不是使 用一套經過證實的流程。即使混亂,成熟度第 1 級的 組織也經常提供可運作服務;不過它們經常會超過專 案的預算和時程。 成熟度第 2 級:管理級 成熟度第 2 級中,專案建立組織的基礎,藉由制度化 基本的專案管理、支援及服務建立與交付實務,成為 有效的服務提供者。專案定義導案策咯、產生專案計 畫及監控專案,以確保依計畫交付服務。服務提供者 與客户建立協議,並發展與管理客户與契約需求。制 度化建構管理及流程與產品品質保證,服務提供者也 發展度量與分析流程績效的能指能力。 成熟度第 2 級中,專案、流程及服務已管理。服務提 供者確保依據政策規劃流程。為執行流程,服務提供 者提供足夠的資源,賦予責任執行流程,訓練人員執 行流程,並確係指定的流程工作產品納入適當層級的 建構管理。服務提供者界定及納入相關的關鍵人員並 定期監控流程。定期評估遵循流程說明的程度並提供 高階管理。能力度第 2 級所反映的流程規範,確保現 有的執行方法能在有時間壓力的情況下,仍維持運 作。 44 試著合而為一 成熟度第 3 級:調適級 關於適用於服務的能力成熟度整合模式 1.2 版 在成熟度第 3 級,服務提供者使用已調適的流程管理 專案。他們堅持專案管理及服務最佳執行方法的原 則,例如服務的持續性及事故的解決與預防,加入標 準流程組中。服務提供者驗證所選定的工作產品符合 他們的需求,並確認服務以確保能符合客戶及最終使 用者的需要。這些流程完整地具體描述與瞭解,並說 明在標準、程序、工具和方法中。 組織的標準流程是成熟度第 3 級的基礎,被建立後, 也要持續改善。這些標準流程被用來建立跨組織的一 致性。專案根據調適指引調適組織標準流程,建立已 調適流程。(請參考詞彙「組織標準流程」的定義) 成熟度第 2 級與第 3 級間的重要差異在標準、流程說 明與程序的範圍。在成熟度第 2 級中,每一個流程案 例(例如;特定專案)中標準、流程說明與程序可能 有很大的差異。成熟度第 3 級中除了調適指引允許的 差異外,專案的標準、流程說明與程序均自組織標準 流程調適而得,以符合特定專案或組織單位,因而流 程更具一致性。 其它成熟度第 3 級的重要差異是,流程通常說明得比 成熟度第 2 級還要嚴謹。一個已調適流程清楚地說明 目的、輸入、允入準則、活動、角色、度量、驗證步 驟、輸出,允出準則。在成熟度第 3 級中,流程透過 瞭解流程活動之互動關係及流程、工作產品與服務的 流程詳細度量,以更主動的管理流程。 成熟度第 3 級中,組織必須進一步使成熟度第 2 級的 流程領域變得成熟。在成熟度第 2 級未解決的一般目 標 3 的一般執行方法,可應用於達成成熟度第 3 級。 試著合而為一 45 適用於服務的能力成熟度整合模式 1.2 版 成熟度第 4 級:量化管理級 成熟度第 4 級,服務提供者對品質及流程績效建立量 化目標,並用於管理流程。量化目標是基於客戶、最 終使用者、組織與流程執行者的需要。品質與流程績 效在統計的術語中可以被瞭解,並在流程生命週期受 到管理。 對所選擇的子流程,搜集與統計分析流程績效的特定 度量。當選擇流程或子流程分析時,很重要的是瞭解 不同的流程與子流程之間的關係,及其對服務提供者 交付產品的績效。這個方式協助確保量化的與統計的 管理可以應用到最具整體價值的經營。績效模式用來 設定服務提供者的績效目標,以及達到經營目標。 成熟度第 3 級與第 4 級的重要差異在流程績效的可預 測性。在成熟度第 4 級中,流程績效使用統計與其它 量化技術控制及量化預測。成熟度第 3 級中,流程通 常僅量化預測。 成熟度第 5 級:最佳化級 成熟度第 5 級,組織根據流程變異的共同原因的量化 瞭解,持續改善它的流程。(參考詞彙「流程變異的 共同原因」的定義)。 成熟度第 5 級透過漸增與創新流程及技術改進,專注 於持續改善流程績效。如此也強化了服務提供者的能 力以符合其品質與流程績效目標。 建立組織量化流程改善目標,且持續修改以反映經營 目標的變動,以及用作管理流程改善的準則。依量化 流程改善目標,度量與評估推展流程改善的影響。已 定義流程與組織標準流程是可度量的改善活動目標。 成熟度第 4 級與第 5 級的重要差異在所解決的流程變 異類型。在成熟度第 4 級中,組織關心解決流程變異 的特殊原因,以及提供結果的統計預測。雖然流程可 46 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 能產出可預測的結果,然而這個結果可能不足以達成 所建立的目標。在成熟度第 5 級中,組織關心流程變 異的共同原因,以及變更流程(轉移流程績效的平均 值或降低內在有經驗的流程變異),以改善流程績 效,並且達成已建立的量化流程改善目標。 成熟度等級的進展 組織可以逐漸達成組織成熟度的改善。先由專案層級 達成,持續到較高層級-整個組織層級的持續性流程 改善-使用定量和定性資料做決策 既然已改善的組織成熟度與一個組織可以達到的預期 結果之改善範圍有關,它也是預測組織下一個專案一 般結果的一個方法。例如:在成熟度第 2 級,組織經 由建立良好的專案管理流程,已由無特定章法提升到 有制度可循。當組織達成所設定之成熟度等級所有流 程領域的一般及特定執行方法時,就提升了組織成熟 度,並獲得流程改善的好處。因為每一成熟度等級都 是下一個等級的基礎,嘗試略過某一個成熟度,通常 會有反效果。 同時,你必須瞭解流程改善的工作應該專注於組織經 營環境的需要,在較高成熟度等級的流程領域可能解 決組織或專案的目前需要。例如:尋求自成熟度第 1 級升級到成熟度第 2 級的組織,通常被建議成立一個 流程組,但是此流程組卻是屬於成熟度第 3 級的「組 織流程專注流程領域才會說明的內容。雖然流程組並 不是組織成熟度第 2 級組織之必要特徵,但是流程組 可以是一個有效方法,以協助組織達到成熟度第 2 級。 試著合而為一 47 適用於服務的能力成熟度整合模式 1.2 版 這種情況有時候稱為「建立成熟度第 1 級的工程流程 組,以帶動組織到成熟度第 2 級」。成熟度第 1 級的 流程改善活動可能主要依賴流程團隊成員的洞察力和 能力,一直到擁有支援較專業及廣泛改善的基礎建 設。 組織可以在任何時間著手於特定的流程改善,甚至在 準備進入成熟度等級所建議的特定執行方法之前即可 著手。然而在這些情況下,組織應該瞭解到這些改善 的成功是有風險的,因為能讓這些改善成功的基礎並 未建置完成。面對壓力時,缺乏適當基礎的流程可能 會在最需要它的時候失敗。 倘若缺乏成熟度第 2 級管理階層的執行方法,則已調 適流程,這是成熟度第 3 級組織的特徵,就可能會發 生問題。例如:管理階層可能會承諾一個未經妥善規 劃的時程,或是無法控制基準需求的變更。同樣地, 許多組織蒐集了成熟度第 4 級所需詳細的資料,但卻 因為流程與度量定義的不一致,而無法詮釋這些資 料。 流程領域 兩種表述針對流程領域的觀點是不同的。圖 3.2 比較 流程領域如何使用在連續式與階段式表述中之觀點。 48 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 圖 3.2: 流程領域在連續式與階段式的表述 試著合而為一 連續式表述使組織能夠選擇那些流程領域或是一組有 互相關連的流程領域,選擇流程改善努力的專注以為 組織及其經營目標帶來最大利益。雖然因為流程領域 49 適用於服務的能力成熟度整合模式 1.2 版 間的相依性,使得組織在選擇上有一些限制,但是組 織仍然有相當多的自由選擇。 倘若缺乏成熟度第 2 級管理階層的執行方法,則已調 適流程,這是成熟度第 3 級組織的特徵,就可能會發 生問題。例如:管理階層可能會承諾一個未經妥善規 劃的時程,或是無法控制基準需求的變更。同樣地, 許多組織蒐集了成熟度第 4 級所需詳細的資料,但卻 因為流程與度量定義的不一致,而無法詮釋這些資 料。 為支援使用連續式表述,流程領域組織成 4 種類型: 流程管理、專案管理、工程與支援。這些類型強調流 程領域間存在的關係。 當你選擇流程領域時,你也必須選擇在這些流程領域 中流程需要成為多少成熟度(也就是:選擇適當的能 力度等級)。能力度等級與一般目標及執行方法支援 個別流程領域相關的流程改善。舉例來說,一個組織 可能希望努力於某個流程領域達到能力度第 2 級,以 及在另一個流程領域達到能力度第 4 級。當一個組織 達到一個能力度等級時,它將這些相同流程領域中的 一個設為下一個能力度等級的目標,或是決定擴大視 野及解決更大數量的流程領域。 選擇流程領域與能力度的組合一般在「目標摘要 」中 描述。目標摘要定義所有必須要解決的流程領域及其 每一個目標能力度等級。這個摘要管理組織中流程改 造工作的目標和執行方式。 大多數組織在最低情況下會將能力度第一級當做目 標,它要求流程領域的所有特定目標均需達成。所 以,將高於能力度第一級當做目標之組織,會專注於 組織內所選擇流程的制度化,實行相關的一般目標與 執行方法。 50 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 階段式表述提供由成熟度第 1 級到第 5 級之預先定義 的改善路徑,涉及達成每一個成熟度等級流程領域之 目標。為了支援階段式表述,流程領域群組成成熟度 等級,指出實行哪些流程領域以達成每一個成熟度等 級。例如,成熟度第 2 級中,有一組流程領域是組織 要用來指引它們流程改善的,直到達成所有流程領域 的目標。一旦達成成熟度第 2 級,組織會專注於成熟 度第 3 級的流程領域等等。每一個流程領域的一般目 標也是預先定義的。一般目標 2 應用在成熟度第 2 級,而一般目標 3 應用於成熟度 3-5 級。 表 3.2 提供 CMMI-SVC 的流程領域清單與其相關的類 別及成熟度等級。 試著合而為一 51 適用於服務的能力成熟度整合模式 1.2 版 流程領域 容量與可用度管理 原因分析與解決方案 建構管理 決策分析與解決方案 整合專案管理 事故解決方案與預防 度量與分析 組織創新與推展 組織流程定義 組織流程專注 組織流程績效 組織訓練 專案監控 專案規劃 流程與產品品質保證 量化專案管理 需求管理 類別 專案管理 支援 支援 支援 專案管理 服務建立與交付 支援 流程管理 流程管理 流程管理 流程管理 流程管理 專案管理 專案管理 支援 專案管理 專案管理 成熟度等級 3 5 2 3 3 3 2 5 3 3 4 3 2 2 2 4 2 52 試著合而為一 風險管理 供應商協議管理 服務持續性 服務交付 4服務系統發展 服務系統移轉 策略服務管理 專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 3 專案管理 2 專案管理 3 服務建立與交付服務 2 建立與交付 服務建立與交付交付 3 服務建立與交付服務 建立與交付 3 服務建立與交付交付 3 對等的階段式 對等的階段式是一個比較使用連續式表述與階段式表 述之結果的方式。在本質上,假如你在連續式表述中 使用能力度等級度量所選擇流程領域相關的改善,你 如何將它與成熟度等級做比較呢?這有可能嗎? 到目前為止,我們沒有討論詳細的流程評鑑。 SCAMPISM 方法5用來評鑑使用 CMMI 的組織,其中 一項評鑑結果是評等 [Ahern 2005]。假如評鑑使用連 續式表述,評等就是能力度等級摘要。假如評鑑使用 階段式表述,評等就是成熟度等級(例如:成熟度等 級 3)。 能力度等級摘要是流程領域清單,以反映每一個流程 領域達成的能力度等級。這個摘要使組織能夠追蹤其 流程領域的能力度等級。當它呈現組織每一個流程領 域的實際進展時,這個摘要是一個達成摘要。或者, 4 服務系統發展流程領域是補充資料 5 流程改善的標準 CMMI 評鑑方法(SCAMPI)在第 5 章描述。 試著合而為一 53 適用於服務的能力成熟度整合模式 1.2 版 當它呈現組織的已規劃流程改善目標,這個摘要是一 個目標摘要。圖 3.4 說明目標摘要與達成摘要。每一 個長方條灰色的地帶呈現已經達成的。未遮蔽的部份 呈現有待完成的,以符合目標摘要。 圖 3.3 達成摘要與目標摘要的例子 達成摘要與目標摘要的比較,使組織能夠規劃與追蹤 每一個所選擇的流程領域的進展。當使用連續式表述 時,維護能力度等級摘要是明智的。 目標階段是一個循序的目標摘要,以說明組織要遵循 的流程改善路徑。當建立目標摘要時,組織應該專注 一般執行方法與流程領域的從屬關係。假如有一般執 行方法依賴某個流程領域,當該流程領域未實行時6, 無論執行一般執行方法或是提供必要產品,一般執行 方法可能會比較沒有效果。 6有關一般執行方式和流程領域之間的依存關係,參考第二單元的一般目標及一般執行方式之表 6.2 54 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 雖然有許多理由使用連續式表述,但是能力度等級摘 要所提供的評等能力,對於提供組織一個一般性的方 式與其它組織進行比較是有限的。如果每一個組織選 擇相同流程領域,能力度等級摘要可能會有用。然 而,成熟度等級可以用於每一年組織比較,而且已經 提供一組預先定義的流程領域。 因應這個情況,建立對等的階段式。對等的階段式組 織能夠使用連續式表述的評鑑,以轉換能力度等級摘 要到相關的成熟度等級的評等。 更有效用來描述對等的階段式的方式,是提供一個連 續的目標摘要,每一個都是對等於階段式表述中的成 熟度等級評等。這個結果是目標階段,它對等於階段 式表述的成熟度等級。 圖 3.4 顯示當使用連續式表述來對等於成熟度等級的 第 2 級到第 5 級之必須達成的目標摘要一覽。每一個 能力度等級欄位遮蔽的區域呈現對等於成熟度等級的 目標摘要。 試著合而為一 55 適用於服務的能力成熟度整合模式 1.2 版 名稱 建構管理 度量與分析 專案監控 專案規劃 流程與產品品質 保證 需求管理 服務交付 供應商協議管理 容量與可用度管 理 決策分析與解決 方案 整合的專案管理 事故解決方案與 預防 組織流程定義 組織流程專注 組織訓練 風險管理 服務持續性 服務系統發展 服務系統移轉 縮寫 CM MA PMC PP PPQA MC C C C C L L1 L2 L3 L4 L5 2 2 目標 2 摘要 2 2 2 REQM 2 SD 2 SAM 2 CAM 3 DAR 3 IPM 3 IRP 3 OPD 3 OPF 3 OT 3 RSKM 3 SCON 3 SSD 3 SST 3 目標 摘要 3 56 試著合而為一 名稱 縮寫 關於適用於服務的能力成熟度整合模式 1.2 版 MC C C C C L L1 L2 L3 L4 L5 策略服務管理 STSM 3 組織流程績效 量化專案管理 OPP 4 目標 QPM 4 摘要 4 組織創新與推展 OID 5 目標 原因分析與解決 CAR 5 摘要 5 方案 圖 3.4 目標摘要與對等的階段式 試著合而為一 以下概述對等的階段式規則: • 達成成熟度第 2 級,所有成熟度第 2 級指定的流 程領域,必須達到或高於能力度第 2 級。 • 達成成熟度第 3 級,所有成熟度第 2 與第 3 級指 定的流程領域,必須達到或高於能力度第 3 級。 • 達成成熟度第 4 級,所有成熟度第 2、第 3 與第 4 級指定的流程領域,必須達到或高於能力度第 3 級。 • 達成成熟度第 5 級,所有流程領域,必須達到或 高於能力度第 3 級。 這些對等的階段式的規則與表格是完整的。但是你可 能會問為什麼目標摘要 4 及 5 沒有擴展至 CL4 與 CL5。這個理由是成熟度第 4 級的流程領域,說明選 擇的子流程已穩定為基礎,組織與專案的品質與流程 績效目標在某種程度上。不是每一個流程領域,都會 被選擇進行處理,以及 CMMI 並沒有預先假設哪一些 流程領域,會被選擇進行處理。 57 適用於服務的能力成熟度整合模式 1.2 版 所以,一個流程領域之能力度第 4 級的達到無法預先 決定,因為這個選擇依賴組織中成熟度第 4 級之流程 領域的實行。所以,圖 3.5 並沒有顯示目標摘要 4 擴 展至 CL4,雖然有些流程領域會達到能力度第 4 級。 成熟度第 5 級的情況與目標摘要 5 是相似的。 對等的階段式之存在,應鼓勵連續式表述的使用者, 建立目標摘要以擴展至能力度第 3 級以上。該目標摘 要在某種程度上,由組織的選擇所決定,以符合組織 經營目標。 使用 CMMI-SVC 時該瞭解的關鍵概念 到目前為止,這概念和術語,例如流程領域、能力度 和對等的階段式,對所有的 CMMI 模式而言是共同 的。然而,有一些額外的術語特別用於 CMMI-SVC 模式中。雖然都在詞彙中已定義,每一個所採用詞 彙,儘可能地包含在各種背景下的意義,以便它們可 以適用在一些額外的討論以確保模式資料的概念不被 誤解。 服務 這些術語最重要的是「服務」這個字本身。在詞彙中 將之定義為:一個無形的、不可儲存的產品。此定義 準確地說明「服務」的意義範圍,它不是強調一些可 能的承租物或在 CMMI 內容中概念的誤解。 第 1 點要強調的是服務是一種產品,這樣的一個定 義。許多人總是認為產品和服務是 2 個相互獨立的類 別。在 CMMI 模式中,產品和服務不是分開的類別: 服務被視為一個特別的產品種類。對產品的參考資料 也可視為服務的參考資料。如果你發現需要參考產品 的類別,不是 CMMI 資料的服務,你可使用「商品 (goods) 」,如同一般常用且易懂的 「商品與服務 58 試著合而為一 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 (goods and services) 」(為了歷史原因,部份的 CMMI 模式偶而依舊使用「產品與服務(products and services) 」。然而,這樣的使用是為了想提醒讀者, 服務在討論中是被涵括進來的。 第 2 個可能在服務和流程間的造成困惑的是,特別因 為 2 個專門名詞都涉及一個主體,一個本質是無形 的、不可儲存的,而且2者的概念從本質上來說是相 關聯的。然而,在 CMMI 模式中,流程是活動,而服 務是展現出這些活動的可用的成果。例如,一個提供 訓練服務的組織展現的訓練流程(活動),是為讓參 與者更具知識。這個事件(更有知識)的可用狀態是 訓練提供者交付或意欲交付的服務。如果這訓練流程 已進行,但參與者不能變得更有知識(可能因為此訓 練設計得不好,或受訓者不具備重要的基本知識), 那麼此訓練-可用的成果-已沒有確切地交付。服務 是流程的結果(是所有資源一部份的展現),而不是 流程本身。 最後一個可能對「服務」這個字感到困惑的一點是, 服務很顯然是來自資訊技術的背景,特別是那些對服 務導向架構(SOA)或軟體即服務(SAAS)熟悉的 人。在軟體文件中,服務是一個較大的自動化系統的 方法、組件或模組(building blocks)的想法。而不是系 統產生的結果。在 CMMI 模式,服務是可用的無形且 不能儲存,由服務系統運作產生的結果,可能有也可 能沒有自動的組件。為完全解決這個困惑,對服務系 統概念的瞭解是必須的。 服務系統 服務經由服務系統的運作而交付,「服務系統 」在詞 彙中將之定義為:滿足服務需求的整合與相互依賴的 組件資源的組合。在服務系統中使用「系統 」這個字 可以建議給那些不同的資訊技術,含有硬體、軟體和 59 適用於服務的能力成熟度整合模式 1.2 版 60 其他的 IT 組件的服務系統。這個解釋是有限制性 的。而它也可能是服務系統的組件以資訊技術執行, 也可能是有一個服務系統使用少量或完全不使用資訊 技術。 在本文中,「系統」一字應被更廣泛地解釋為:「一 個平常互動或互相依賴的一組零件,構成一個整 體」,一個典型的字典定義。由人們所發展的系統也 通常有一個預設的統一目的,以及一個以預設的方式 去運作或執行的能力。考慮一個包裹交付系統、一個 保健系統或一個教育系統做為服務系統,擁有許多各 類的整合及互動的組件資源的範例 有一些仍與這個解釋有差距,因為他們可能覺得他們 交付服務不是系統化的,沒有確切的「組件 」,或是 太小或太難以系統的觀點來檢視。對某些具有不成熟 的執行方式的服務提供者組織而言,確實有此困難, 部份的困難可被追蹤到,在服務系統的定義中,對 「資源(resources) 」太狹隘的解釋。 整個服務系統內容中包含所有服務交付的需求,包括 工作產品、流程、工具、設施、消耗性項目及人力資 源。部份資源可能屬於客戶或供應商,部份可能是暫 時的(也就是這些資源只在有限時間中是屬於服務系 統的一部份)。但所有的這些資源在交付服務,以某 些形式被需要時,即變成服務系統的一部份。 因為大範圍的各類資源及其彼此之間的關係,服務系 統可能是一個大且複雜的,擁有許多設備和組件的 (例如,保健服務系統、運輸服務系統)。可替代 地,一個服務系統可能是主要由人和流程組成(例如 獨立的驗證服務)。因為每一個服務提供者組織使用 CMMI-SVC 模式必須至少有人和流程的資源,他們應 該可以成功地採用服務系統概念。 那些很少從大系統觀點的服務交付方式,考慮方法、 工具和人力的服務提供者可能需要多花點心力去重組 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 他們對服務交付的想法,來適應此觀點。如此做的好 處很多,然而,因為重要的以及不經意的資源及其相 互關係在第一次時將變得顯而易見。這個重要想法會 使服務提供者組織有效率地改善其運作,不會有意外 或資源浪費在未完整處理的問題上。 試著合而為一 61 適用於服務的能力成熟度整合模式 1.2 版 服務協議 服務協議是服務提供者和客戶間共同瞭解的基礎,也 說明對彼此關係的期待。在詞彙中對「服務協議 」的 定義是一個「服務提供者和客戶間對於承諾的交換價 值,一個有約束力的、白紙黑字的記錄 」。服務合約 可以各種形式出現,從簡單的「菜單式 」的載明服務 和價格、到參考條件和規格的精美列印的規劃表、到 複雜的包含於法律合約中的文件的一部份。不管他們 包含什麼,最重要的是,服務協議以一個形式紀錄下 來,服務提供者和客戶都可使用及瞭解,以將誤解減 到最小。 「已承諾的交換價值」隱含著協議中的每一方同意提 供其他方所需要的或所想要的。一般的情形是,對服 務提供者提供所需的服務和對客戶相對地付出金錢, 但很多其他形式的協議是有可能的。例如,一個組織 間的操作等級協議(OLA),在同一個企業中,當需要 某項服務時,可能只要客戶組織去通知服務提供者組 織。由政府、公立單位或非營利組織提供公共服務的 服務協議,可能只需將可提供的服務文件化,並確認 最終使用者必需遵照哪些步驟以取得服務。在某些情 形,服務提供者需要或想要從客戶或最終使用者獲得 的只是啟動服務交付的特定資訊。 參見術語額外討論的詞彙「服務協議」、 「服務等級 協議」、 「客戶」、及「最終使用者」。 服務請求 就算是已有服務協議,客戶和最終使用者必須能通知 服務提供者對於特定的服務交付內容的需求。在 CMMI-SVC 模式中,這些通知被稱做「服務請求」, 它們可以以任何可接收的形式進行,包括面對面的討 論、電話、各種形式的手寫媒體,以及甚至訊號(例 如,按一個鈕叫巴士到巴士站)。 62 試著合而為一 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 不管它是如何進行溝通,一個服務耍要求確認一個或 多個期望的服務。這個服務要求的起源者希望能在現 行的服務協議範圍中。這些要求通常由客戶及最終使 用者當有需求時,不斷地被提出。在這個情形下,服 務要求是服務交付的重要部分;它們是主要的驅動事 件,促使服務遞送發生。(當然,原始的要求者可能 不清楚此要求是否在服務協議的範圍內) 有時特定的服務請求可能直接放在服務協議中。將服 務請求放入服務協議中通常是服務會重複地或持續地 呈現的情形(例如,一項有特定預計清潔時程的清潔 服務,一個交流管理服務必須在服務協議的有效期內 提供 99.9%的交流可供性)。即使在這種情形,特定 的服務要求也可能在需要時提出,而服務提供者應隨 時準備交付服務以回應兩類型的要求。 服務事故 即使有最好的規劃、監督及服務交付,一些不願發生 的事件可能會發生。有一些服務交付的例子可能有低 於預期或低於可接受的績效或品質,或可能完全不成 功。CMMI-SVC 模式對於這些困難稱之為「服務事 故」。在詞彙中將「服務事故」定義為,一個實際或 潛在的,對服務干擾的指標。「事故」這個單字使用 在「服務事故」上,以使內文中的意義更清楚。 像是要求,事故需要由服務提供者認可與回應。但不 像要求,則事故是無預期的活動,雖然有一些型態的 事故可能可以預期。不論是否他們可被預期,事故也 必需由服務提供者來解決。在某些服務型態和服務提 供者組織,服務要求和事故都會經由一般流程、人事 和工具被管理和解決。CMMI-SVC 模式與這類的方式 相容,但不要求它,因為它並不適用所有類型的服 務。 63 適用於服務的能力成熟度整合模式 1.2 版 使用“具潛力的”在服務事故的定義上是經深思熟慮且 有意義的。其意義是事故並不總是必須涵括確實的阻 礙或失敗的服務遞送。一個服務可能效率不佳或不成 功也一樣是事故,因為事故在未來也可能效率不佳或 不成功。(客戶抱怨是全世界都會用來舉例的事故型 態,因為這是服務遞送不妥當的一項指標)。事故的 觀點通常都會被監督的,但它是重要的:無法說明和 解決服務潛在的阻礙可能導致最終成為阻礙,並可能 無法滿足服務協議。 專案 當參照到跨 CMMI 模式的概念,「專案 」這個名詞 就必須在 CMMI-SVC 模式的內容中做一些特別的澄 清。可能在這個模式中沒有其他的單字,也有可能引 起誤解、問題,甚至是反對。 在先前使用其他 CMMI 模式的經驗,或一向視自己的 工作是專案型工作的一部份的人,可能會想其困難在 哪裏。CMMI 詞彙定義「專案」是一個,有一個或多 個給客戶或最終使用者產品或服務的一組被管理的相 互關係資源,而且專案有一個確定的開始(例如:專 案起始)以及典型地依照規劃運作。這些是在很多對 「專案」的定義中,所具備的特色。所以為什麼有問 題?為什麼在一些服務提供者組織中,採用「專案規 劃」或 「專案管理」會有困難? 一個簡單的原因是,許多人從事或瞭解專案有一個確 定的結束以及一個確定的開始;這些專案被專注在一 個特定的時間,完成一個目標。事實上,在 CMMI 模 式先前版本(1.2 版之前)的詞彙中,特別將一個確定的 結束視為「專案」定義的一部份。這比較舊及較嚴格 的定義反應了 CMMI 的原意(以及在它之前的其他的 成熟模式),其主要專注在發展上,通常產生一些期 望的結局,一旦整體目標已達到。當一些服務遵循同 樣的型式,很多專案會不斷地執行,而沒有預計的確 64 試著合而為一 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 定結束 時間(例如,典型的公共服務,想要不定期提 供給私人企業的服務)。服務提供者在這些內容中, 依照此定義,自然地描述他們服務交付的工作為一個 「專案」。 然而,在最近的 CMMI 模式 1.2 版,專案的定義被稍 微地調整,以減少其限制,部份允許將名術語簡單地 引用到服務型態的所有範圍。專案必須要被規劃,但 它們不需要去規劃結束,而這個較寛鬆的定義可以因 此使服務交付(CMMI 模式使用者希望阻止所有專案 都必須有結束點的想法)的內容合理。 就算有這個調整,有些人仍難將服務交付視為一個 「專案」,通常其言外之意是試著依照原先的計畫完 成所有的目標。很多服務的交付是回應過去所建立的 小的、獨立的目標-個別的服務需求-如此便不在事 先決定的里程碑。在這種情形下,服務提供者通常不 會去考慮到要完成的單一目標。因此,使其工作的安 排像是一個專案,會被認為是不妥當的。 為了這個理由,CMMI-SVC 模式明白地解釋「專案」 一詞包含滿足與客戶的服務協議中所有資源。滿足服 務協議變成當管理個別的服務需求時的全面的目標。 規劃人力以滿足服務協議可以使用工作結構、資源配 置及時程的表格,以及其他典型的專案規劃工作產品 及流程。若你認為服務協議是展現出專案的範圍,那 麼在服務內容中使用「專案」一字就不會有太多問 題。 此外,在詞彙中包括了備註,解釋一個專案可能包含 數個專案。這些額外的備註意指彼此相關的數組服務 協議或服務協議包含數個客戶皆可被當成專案,就如 在一個服務協議的範圍界定數組工作。例如,一個新 版本服務系統的發展或新服務交付能力轉換到一般運 作,也能視為專案。 65 適用於服務的能力成熟度整合模式 1.2 版 最後,當然,組織將使用適用的、熟悉的及有用的術 語,而 CMMI-SVC 模式不需要求這種方式必須更 改。然而,所有的 CMMI 模式需要一個簡單的方式可 以一致地、清楚地參考到可以組織工作以達成顯著目 標的基本資源群組。關於詞彙的定義和先前的討論, 「專案」這個名詞仍是適合且有效果的,雖然它的意 義已隨著時間增加了範圍。這個採用並不令人意外, 因為 CMMI 模式本身也隨著時間在增長範圍,未來也 會繼續如此。CMMI-SVC 使用者強烈地被鼓勵去考慮 他們也採用別的思考方式,來反應較大的彈性,因此 可獲得不同方式改善服務的好處。 66 試著合而為一 關於適用於服務的能力成熟度整合模式 1.2 版 4 流程領域間的關係 本章我們將描述流程領域間的關係,以協助你從服務 提供者的觀點來看流程改善,以及構築在其他流程領 域導入而建立的流程領域。 各種流程領域間的關係,包括從一個流程到另一個流 程的資訊及成果,在本章中將以圖表及描述來說明, 協助你以較寬廣的觀點來看流程導入及改善。 成功的流程改善的啟始必須由組織的經營目標主導。 例如,一個一般經營目標是減少回覆客戶的時間。由 這個目標所導出的流程改善目標可能是改善事故管理 流程。那些改善有賴於服務交付及事故解決方案與預 防流程領域的最佳執行方法。 雖然我們在本章中將流程領域群組化,以簡化他們之 間關係的討論,無論流程領域的的群組、類別或階 層,流程領域間時常相互作用及相互影響。例如,在 決策分析與解決方案流程領域(成熟度第 3 級的一個 支援流程領域)包含了特定的執行方法,此特定執行 方法為在服務持續流程領域(一個成熟度第 3 級的服 務建立及交付流程領域)使用的正式評估流程,以選 擇對組織而言很重要且必須在服務持續計畫中涵括的 功能。 流程領域間的關係 瞭解在 CMMI 流程領域中的關鍵關係,可以協助你以 有用及有生產力的方式採用 CMMI。流程領域間的關 係在每個流程領域的參考資料中描述得更為詳細,特 別是在第二單元的每個流程領域的「相關流程領域」 一節。請參考第 2 章以取得更多的參考資訊。 CMMI-SVC 模式的流程領域有許多相互關係,基於資 料的轉換或分享、工作產品及其他相關執行方法的資 源。本節只著重在確認涵括在服務特定流程領域的關 係。這些關係最好依照功能去瞭解,並隨之依成熟度 及流程領域等 2 個類別分成二個群組。 • 建立及交付服務 67 適用於服務的能力成熟度整合模式 1.2 版 • 管理服務 流程領域關係描述如下圖,著重在為釐清而說明的關 鍵依存關係;不是所有流程領域間可能的互動都有呈 現出來,也不是所有的流程領域都被呈現出來。在圖 表中省略的流程領域(主要是流程管理與支援流程領 域)與其他流程領域的潛在關係則有呈現出來,而他 們的囊括使著重於關鍵 CMMI-SVC 的關係產生困 難。 驅動服務建立與交付的關係 圖 4.1 顯示服務交付能力建立相關的流程領域,由與 客戶服務協議的需求所驅動,服務交付也一樣。 68 流程領域間的關係 策略服 務管理 STSM 關於適用於服務的能力成熟度整合模式 1.2 版 S策tra略te服gic S務er需vic求e Needs 客C戶u/s最tom終e使r/ E用n者d User 事故In狀cid態ent Status S服er務vi型ce C錄atalog 服務Se需rv求ice 契約/服務協 Requirements 服S務e型r錄vice Catalog Co議ntract / Service Agreement 服S務er價vi值ce Value 服Se務rv需ice R求equests 導D入e服p務lo系yed 統 Service System 服 交S務 付D 服S務er議vice 題Issues 需求 R狀eq態uest Status 事R故Iensc回pid應oennste 訊In息formation 事故解決方 事案故方解案決與方預 案防方案IR與P預 防 確V認al服ida務ted 系SS統yesrvteicme 服務系統移 轉SST 操作O與pe服ra務tio遞n送s 資an料d Service Delivery Data 移轉T計ra畫nsition 服Re務qS需ueirr求veimceents Plans 服S務系S統D發 展 標準S服ta務nd需ar求d Service Requirements 服務S需er求vice Requirements 矯正措C施orrective Actions 修修改改R資Ce資源ov限源inss制e限td與ra制服Rin務與etss門服oa檻u務nrdce 門S檻ervice Thresholds IRP = Incident Resolution and Prevention SD = Service Delivery SSD = Service System Development SST = Service System Transition STSM = Strategic Service Management 管P理ro服c務es之s 流Ar程ea領s域for Managing Services 圖 4.1:建立與交付服務的關鍵流程領域關係 在圖表中所描述的流程領域均屬於服務的建立與交付 流程領域類別。請注意服務交付流程領域在這些關係 中是處於主要的角色。 驅動服務管理的關係 流程領域間的關係 圖 4.2 說明在專案層級的服務管理相關的流程領域。 在這圖表中除了服務交付外,大部份所呈現的流程領 域是在專案管理流程領域類別。此圖表與「服務管 理」相關而不是與「專案管理」相關的原因是,服務 69 適用於服務的能力成熟度整合模式 1.2 版 交付流程領域屬於「專案管理」及「服務建立與交 付」,但只能是 CMMI 模式中單一流程領域類別。因 為服務交付正式地被分類在「服務建立與交付流程領 域」類別中。其涵括在此圖中意義「專案管理」不足 以更廣的呈現。 契約Co/n服tra務ct協/ S議ervice Agreement 客Cu戶s/to最m終e使r /用En者d User 審查 Reviews 需求管理 REQM 服務S需er求vice Requirements 契C約on/t服rac務t /協Se議rvice Agreement 專案P監M督C與管控 服S務D 專案計畫 持C續o需nti求nuity 遞送 專案計畫 Requirements Project aa Plan Capacity and A能va力ila與bi可lity利用 Re度qu需ire求ments 服務 SC持O續N Co持 計Pntlai續 畫nnuity 專案Pr計oje畫ct Plan 能力與可利 用C度A管M理 服務Se需rv求ice Requirements 服R務eqS需ueirr求evmiceents 運Op作er與at服ion務s 遞an送d S資e料rvicDeaDtaelivery R資e源so分ur析ce Analysis 專案 規P劃P M度ea量su需re求ment Needs Re修vi改se的d R資e源so限urce C制on和st服ra務int門s a檻nd Service Thresholds 矯正C措orr施ective Actions CAM = Capacity and Availability Management PMC = Project Monitoring and Control PP = Project Planning REQM = Requirements Management SCON = Service Continuity SD = Service Delivery Process Areas for Establishing and 建立與交付D服eli務ve流ri程ng領S域ervices 圖 4.2:服務管理的關鍵流程領域關係 圖 4.2: 服務管理的關鍵流程領域關係 70 流程領域間的關係 關於適用於服務的能力成熟度整合模式 1.2 版 5 使用 CMMI 模式 現今產品的複雜度要求組織如何用一個整合觀點從事 經營。企業利用多個部門或群組產出產品與服務, CMMI 可以降低跨企業的流程改善成本。 為了達到整合的觀點,CMMI 架構包含一般術語、一 般模式組件、一般評鑑方法與一般訓練工具。本章節 說明組織如何使用 CMMI 產品系列,改善它們的品 質、降低它們的成本及最佳化它們的排程,除此之外 判斷它們的流程改善計畫工作滿意程度。 採用能力成熟度整合模式 研究顯示對於流程改善起步最有影響的,是透過有力 高層管理者的贊助,建立強大的組織支援。為了得到 高層管理者的贊助,很重要的是要讓高階管理者發覺 別人使用 CMMI 進行流程改善的績效結果是很有助益 的[Gibson 2006]。 有關於 CMMI 績效結果的進一步資訊,請參考 SEI 網 站:www.sei.cmu.edu/cmmi/results.html 高階管理者一旦承諾成為流程改善贊助者,就必須主 動參與以能力成熟度整合模式為基礎的流程改善工 作。高階管理贊助者的執行活動包含(但是沒有限 制)以下: • 影響組織採用 CMMI。 • 選擇最佳的人員來管理流程改善工作。 • 親自監督流程改善工作。 • 成為流程改善工作顯而易見的提倡者與發言人。 採用能力成熟度整合模式 71 適用於服務的能力成熟度整合模式 1.2 版 • 確保提供足夠的資源使得流程改善的努力能夠成功 在充份的高階主管者贊助後,下一步驟為建立一個強 大、技術上能勝任的流程組,此流程組代表相關的關 鍵人員,以指引流程改善工作。 對於交付品質服務為任務的組織,流程組可能包含代 表跨組織之不同專業領域的工程師,以及其它根據經 營需求以促進改善之被選擇的成員。舉例來說,系統 管理者可能會專注於資訊科技的支援,然而銷售代表 可能專注於整合客戶的需要。這兩種成員可能會對流 程組有很大的貢獻。 一旦你的組織決定採用 CMMI,規劃可以由一個改善 方法開始,例如 IDEALSM(初始、診斷、建立、行動 與學習)模式[McFeeley 1996]。有關於 IDEAL 模式的 進一步資訊,請參考 SEI 網站:www.sei.cmu.edu/ ideal/ideal/ 你的流程改善計畫 使用 CMMI 產品系列,協助建立你的組織流程改善計 畫。針對這個目的使用 CMMI 產品系列可以是相當非 正式流程,涉及瞭解與應用 CMMI 最佳實務於組織 中,或者,它可以是一個需要廣泛訓練、建立流程改 善基礎建設、評鑑等的正式流程。 影響你計畫的選擇 應用 CMMI 到你組織的流程改善,你必須做出三個選 擇: 1. 選擇組織的單位 72 採用能力成熟度整合模式 2. 選擇模式 3. 選擇表述 關於適用於服務的能力成熟度整合模式 1.2 版 選擇要納入你的流程改善計畫中的專案是重要的。如 果你選擇的群組過大,可能會使初始改善時所花的工 作量太多。選擇也應該要考慮到群組的同質性。(例 如:儘管他們都是軟體工程師,但是他們是否都是工 作在相同產品或是經營線等等)。 因為 CMMI 模式的建立方式,選擇要使用哪種表述的 流程有一些指引。如果你的組織喜歡成熟度等級與階 段式表述,你的改善途徑已經定義好了。若你的組織 喜歡連續式表述,你幾乎可以選擇任何流程領域或是 一組流程領域來指引改善,當在做這些選擇時,雖然 應該考慮流程領域之間的相互依存性。 在流程改善計畫與活動進展時,其它重要的選擇也必 須決定,包含該使用哪個評鑑方法、應該評鑑哪個專 案、如何確保員工訓練和應該訓練哪些員工。 能力成熟度整合模式 CMMI 模式說明已決定的最佳執行方法,組織發現這 些執行方法有助於生產力與有用於達到它們的經營目 標。 無論你的組織是哪種類型,應用 CMMI 最佳執行方法 時,你必須使用專業判斷,針對你的現況、需求和經 營目標來解釋它們。雖然流程領域描述一個組織承諾 流程改善的特徵,你必須使用 CMMI、你的組織、經 營環境與特定情況的深入的知識,解釋流程領域。 當你開始使用 CMMI,改善你的組織流程時,將你真 實世界的流程與 CMMI 流程領域對應。這個對應幫助 採用能力成熟度整合模式 73 適用於服務的能力成熟度整合模式 1.2 版 你初始判斷,以及之後追蹤你組織符合你所使用 CMMI 模式的等級,並界定改善的機會。 解釋執行方法時,考慮使用哪些執行方法,以及決定 這些執行方法如何滿足流程領域目標的程度是重要 的。CMMI 模式並沒有明確規定或暗指某些特定流程 適合任何組織或專案。相反地,CMMI 對於規劃與執 行組織經營目標,所選擇要改善的流程說明最基本的 必要準則。 CMMI 執行方法有目的使用非特定的片語,如「相關 的關鍵人員」、「適當的」、「如有需要」來相容於 不同組織和專案的需要。專案的特定需要也可能會在 生命週期中不同時間點上有所差異。 使用能力成熟度整合模式的評鑑 很多組織發現度量它們進展的價值,藉由執行評鑑, 然後獲得成熟度等級評等或是能力度等級達成摘要。 這些評鑑通常為一到多個下列理由而執行: • 要決定組織流程對應到 CMMI 最佳執行方法到怎 樣程度,以及界定要進行改善的領域。 • 為了向外部客戶與供應商報告組織流程對應到 CMMI 最佳執行方法的程度。 • 為了符合一個或多個客戶在合約上的需求。 組織使用 CMMI 模式評鑑,必須遵循 Appraisal Requirements for CMMI(ARC)文件上的需求定義。 這些評鑑方式專注在界定改善機會與比對 CMMI 最佳 執行方法及組織內部流程。評鑑團隊使用 CMMI 模式 與符合 ARC 之評鑑方法來指引它們的組織評估,而 74 採用能力成熟度整合模式 關於適用於服務的能力成熟度整合模式 1.2 版 且報告他們的結論。然後這些評鑑結果被使用(例 如:流程組)以規劃組織的改善。 能力成熟度整合模式的評鑑需求 ARC 文件說明數個評鑑類型的需求。一個完整可標 竿學習的評鑑類型被定義成評鑑類型 A,較不正規的 方法被定義成評鑑類型 B 或 C。ARC 文件是設計用 以協助跨評鑑方法的一致性,以及幫助評鑑方法之發 展者、贊助者及使用者瞭解其他相關方法的權衡選擇 取決於評鑑目的與環境性質,一個類型可能會優先其 它類型。有些時候,自我評量、初始評鑑、快速察 看、小型評鑑、漸增評鑑或是外部評鑑是適當的,然 而其它時候一個正式基準比較評鑑是適當的。 以 ARC 的需求為基礎,一個特定的評鑑方法宣告為 ARC Class A、ARC Class B 或 ARC Class C 評鑑方 法。這個 ARC 的需求是在設計這個方法時,由方法 發展者所處理。 更多有關於 ARC 的資訊可以利用 SEI 網站 www.sei.cmu.edu/cmmi/appraisals/index.html SCAMPI 評鑑方法 一 般 已 接 受 用 來 執 行 CMMI 模 式 評 鑑 的 方 法 為 SCAMPI 評鑑方法,SCAMPI 方法定義文件(MDD)定 義確保評鑑等級一致性的規則,對於跨組織的基準比 較,評鑑必須確保一致性的等級,特定成熟度等級的 採用能力成熟度整合模式 75 適用於服務的能力成熟度整合模式 1.2 版 達到或是一個流程領域的滿足對於不同被評鑑組織而 言都必須代表相同的情況。 SCAMPI 評鑑家族包含 Class A、Class B 與 Class C 評鑑方法。SCAMPI A 是最嚴謹以及唯一會產出評鑑 等級的方法。SCAMPI B 針對模式範圍提供另一種選 擇,但是執行方法的特性描述是固定於一個尺度上以 及針對已被執行的一般方法上實行。SCAMPI C 根據 使用者定義的尺度提供廣大的選擇,包含針對流程執 行規劃方法特徵。 評鑑考量 更多有關於 SCAMPI 方法的資訊可以利用 SEI 網 站。 www.sei.cmu.edu/cmmi/appraisals/index.html 選擇會影響以 CMMI 為基礎的評鑑包含以下所述: • CMMI 模式 • 評鑑的範圍,包含要評鑑的組織單位、要調查的 CMMI 流程領域以及要評鑑的成熟度等級與能力等 級。 • 評鑑方法 • 評鑑團隊成員 • 由要評鑑的個體選擇要進行訪談的評鑑參與者。 • 評鑑產出(例如:評比或是特定案例發現)。 • 評鑑限制條件(例如:現場審查時間)。 76 採用能力成熟度整合模式 關於適用於服務的能力成熟度整合模式 1.2 版 SCAMPI MDD 容許在評鑑中使用預定選項選擇。這 些評鑑選項是設計用來幫助組織調準 CMMI 以符合其 經營需求與目標。 SCAMPI 評鑑計畫與結果的文件化必須包含評鑑選擇 的說明、模式範圍與選擇的組織範圍。這份文件會確 認評鑑是否有符合基準比較的需求。 當組織想要針對多個部門或群組進行評鑑時,CMMI 整合方法使得模式的規模經濟與評鑑訓練成為可能。 評鑑方法可以針對多個部門提供個別或是整合的結 果。 針對 CMMI 產品組的評鑑準則和用於評鑑其它流程改 善模式的準則相同,這些準則包含以下: • 高階管理支持 • 專注在組織經營目標 • 訪談的機密 • 已文件化評鑑方法的使用 • 使用流程參考模式(例如:CMMI 模式)作為基礎 • 團隊合作方法 • 專注於流程改善的活動 能力成熟度整合模式的相關訓練 無論你的組織現在是流程改善的新手或是已經熟悉流 程改善模式,訓練是組織能力中採用 CMMI 的關鍵元 素,SEI 及其夥伴提供一系列基本課程,但是你的組 織可能想要利用內部教育來補充這些課程,這個方法 允許你的組織專注於提供更大的經營價值的區域。 採用能力成熟度整合模式 77 適用於服務的能力成熟度整合模式 1.2 版 SEI 及其夥伴提供 Introduction to CMMI 課程,這個 課程提供一個 CMMI 模式的基本簡介。SEI 也提供 Intermediate Concepts of CMMI 課程給那些規劃要成 為熟悉 CMMI 之採用與評鑑的人。舉例而言,在流程 組中將要指引改善的人、想要教授 Introduction to CMMI 課程的人。目前有關於 CMMI 的訓練資訊可以 利用 SEI 網站 www.sei.cmu.edu/cmmi/training/index.html。 78 採用能力成熟度整合模式 關於適用於服務的能力成熟度整合模式 1.2 版 第二單元:一般目標與一般執行方法及流程領域 一般目標與一般執行方法 79 適用於服務的能力成熟度整合模式 1.2 版 一般目標及一般執行方法概述 總覽 本節詳細的描述 CMMI 所有的一般目標及一般執行方 法-直接說明流程制度化的模式組件。一般執行方法 詳細說明出現在一般執行方法之後,以表達這些執行 方法如何獨特的應用於流程領域中。 流程制度化 80 制度化在流程改善中是很重要的觀念。在一般目標及 一般執行方法描述中,制度化意指流程已根深蒂固在 工作的執行,以及執行流程的承諾與一致性。 當壓力來時,制度化流程仍被維持。然而,當流程需 求及目標變更時,流程的執行也需要變更以確保仍然 有效。一般執行方法說明這些制度化觀念的活動。 制度化的等級包含於一般目標中,並以個別目標相關 的流程名稱來表達,如表 6.1 所示。 表 6.1 一般目標及流程名稱 一般目標 GG 1 GG 2 GG 3 GG 4 GG 5 流程的發展 已執行流程 已管理流程 已調適流程 量化管理流程 最佳化流程 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 在接下來的流程描述中,描述流程制度化的發展。 已執行流程 已執行流程是一種流程,為必要完成的工作以產生工 作產品,並滿足流程領域的特定目標。 已管理流程 已管理流程是已執行流程,依據政策規劃及執行;任 用擁有充足資源的技術人員生產已控制的產出;納入 相關關鍵人員;監督、控制及審查;以及遵循流程說 明評估流程。流程對專案、群組或組織功能可能是短 暫的,流程的管理應考慮制度化及為流程建立其他特 定目標的達成。由已管理流程提供的控制,協助確保 所建立的流程,在有壓力時仍能維持。 此流程的需求及目標由組織建立。工作產品及服務交 付的狀態在已定義時間點(例如:在主要的里程碑及 主要工作項目的完成)中的管理是顯而易見的。在工 作執行中及相關關鍵人員間建立承諾,必要時進行修 訂。由相關關鍵人員審查及控制工作產品,其工作產 品及服務滿足特定的需求。 已執行流程及已管理流程間關鍵的區別在於被管理的 程度。已管理流程是有規劃的(計畫可能是整合性計 畫的一部分),並依照計畫來管理流程的執行。當正 確的結果及績效很明顯與計畫脫軌時,應採取矯正行 動。已管理流程達到計畫的目標,且一致性績效的制 度化。 一般目標與一般執行方法 81 適用於服務的能力成熟度整合模式 1.2 版 已調適流程 已調適流程是一個已管理流程,根據組織的調適指引 調適組織標準流程,擁有已維護的流程說明,並納入 工作產品、度量與其他流程改善資訊至組織流程資 產。 組織流程資產是與描述、執行及改善流程相關的人為 產物,之所以被稱為資產,是因為透過發展或迎合組 織經營目標而取得,且對於期望能提供現在及未來經 營價值的組織來說,也算是投資。 建立並持續改善已調適流程的基礎-組織標準流程。 標準流程描述已調適流程期望的基本流程元件。標準 流程同時描述這些流程元件間的關係(例如:順序與 介面)。組織層面的基礎架構,支援現在與未來使用 已建立並持續改善的組織標準流程。(有關「標準流 程」的定義,請參見詞彙。) 專案的已調適流程提供規劃、執行及改善專案工作及 活動的基礎。專案不只有一個已調適流程(例如:一 個用於發展產品,另一個用於測試產品)。 已調適流程清楚陳述如下: • 目的 • 輸入 • 允入準則 • 活動 • 角色 • 度量 • 驗證步驟 82 一般目標與一般執行方法 • 輸出 關於適用於服務的能力成熟度整合模式 1.2 版 • 允出準則 已管理流程與已調適流程的主要區別,在於流程說 明、標準及程序的應用範圍。在已管理流程,流程說 明、標準及程序應用於特定專案、團隊或組織功能 群。同一組織內,兩個專案的已管理流程可能非常不 同。 另一個主要的區別,在於已調適流程比已管理流程描 述更詳細,執行更嚴謹,這意味著改善資訊更容易瞭 解、分析與使用。最後,經由瞭解流程活動的相互關 係,以及流程、工作產品與服務的細部度量,來管理 已調適流程,並提供更多的洞察力。 量化管理流程 量化管理流程是一個已調適流程,使用統計與其它量 化的技術進行控制。產品品質、服務品質及流程績效 屬性,在整個專案中是可量測及控制的。 量化目標是根據組織標準流程的能力、組織企業的目 標,與客戶、最終使用者、組織及流程執行者的需 要,以及提供的可用資源而設定。執行流程的人直接 從事量化的流程管理。 對生產產品的整體流程執行量化管理,並對整體流程 績效有重要貢獻的子流程進行統計管理。針對這些已 選定的子流程,蒐集流程績效的詳細度量資料,並進 行統計分析。界定流程變異的特殊原因,並適當蒐集 特殊原因的來源,以避免未來再度發生。 將品質與流程績效的度量結果,納入組織度量儲存 庫,以支援未來以事實為基礎的決策。 一般目標與一般執行方法 83 適用於服務的能力成熟度整合模式 1.2 版 流程績效的量化管理活動包含如下: • 界定置於統計管理的子流程 • 界定與度量產品與流程屬性,該屬性對品質與 流程績效有重要貢獻 • 界定與處理子流程變異的特殊原因(以已選定的 產品與流程屬性,以及已選定進行統計管理的 子流程為基礎) • 以界定績效在常態範圍為目標,管理每一已選 定的子流程(例如:以已選定的產品與流程屬性 為基礎,使子流程績效具統計穩定性與可預測 性) • 預測流程能力,以符合已建立的量化品質與流 程績效目標 • 當決定已建立的量化品質與流程績效目標無法 符合時,採取適當的矯正行動 以上描述的矯正行動包括:改變目標,或確保相關關 鍵人員對績效差距具量化的瞭解,並同意此績效差 距。 已調適流程與量化管理流程的主要區別,在於流程績 效的可預測能力。量化管理流程意指使用適當的統計 與其它量化的技術,管理一個流程的一至多個子流 程,因此可預測未來的流程績效。已調適流程僅提供 量化的可預測性。 最佳化流程 最佳化流程是一個量化管理(能力度第四級)流程,改 變與適應量化管理流程,以符合重要的趨勢與專案的 84 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 經營目標。最佳化流程透過漸進與創新的技術改善, 致力於持續的流程績效改善。流程改善,處理流程變 異的根本原因,以及界定、評估及推展可度量的組織 流程改善。以下列二者的量化瞭解為基礎選擇改善方 案:流程改善方案對達成組織流程改善目標的預期貢 獻,以及執行時的成本與對組織的衝擊。組織流程的 績效是持續改善的。 系統化管理與推展已選定之漸進與創新的技術改善至 組織。根據量化流程改善的目標來度量與評估推展流 程改善的效果。 而最佳化流程,藉由改變平均值或減少變異的方式改 變流程,以回歸穩定的狀態。這些改變意圖改善流程 績效,以便達成組織已建立的流程績效目標。 量化管理流程與最佳化流程的主要區別,在於最佳化 流程藉由處理流程變異的共同原因而持續改善。量化 管理流程專注於克服流程變異的特殊原因,並提出統 計上可預測的結果。雖然流程或許可以產生可預期的 結果,但結果本身卻未必足以達成預期的目標。 流程間的關係 一般目標逐步發展,所以每個目標為下一個的基礎。 結論如下: • 已管理流程是已執行流程 CMF • 已調適流程是已管理流程 CMF • 量化管理流程是已調適流程 CMF • 最佳化流程是已管理流程 CMF 如此,按照順序應用,一般目標描述漸進式制度化的 流程,從已執行流程到最佳化流程 CMF。 達到流程領域的 GG1,就等於達到該流程領域的一般 目標 CMF。 一般目標與一般執行方法 85 適用於服務的能力成熟度整合模式 1.2 版 達到流程領域的 GG2,就等於管理該流程領域的流程 績效。有政策來指定要執行,有計畫來執行,並提供 資源,指派責任,訓練如何執行,控制從執行流程選 定工作產品,等等。換句話說,規劃及監督該流程就 像任何專案或支援活動一樣。 達到流程領域的 GG3,假設可調適的組織標準流程, 取決於所使用的流程。調適可能對標準流程沒有任何 改變,換句話說,所使用的流程與標準流程可能是完 全一樣的。使用眾所皆知的標準流程也是調適,因為 已決定不需更進一步修改。 每個流程領域描述多樣活動,有些是重複執行的。你 可能需要調適其中一個已執行的活動,來導出新功能 或環境。舉例來說,你有一個發展或獲得組織訓練的 標準,但沒有包含網路線上訓練。當準備發展或獲得 網路線上課程時,你可能需要調適標準流程,來導出 特定的挑戰及網路線上訓練的利益。 達到流程領域的 GG4 或 GG5 概念上是可實行的,但 除不經濟外,也許在延長階段中,產品領域會趨於穩 定,或者流程領域或專業領域是關鍵經營的驅動者。 一般目標及一般執行方法 本節描述所有一般目標及一般執行方法,以及相關的 細部執行方法、筆記、案例,以及參照。以數列順序 來排列一般目標,從 GG1 到 GG5,一般執行方法也 以數列順序及其所支援的一般目標來排列。 一般執行方法詳細說明條列在一些流程領域的每一個 一般執行方法之後。不是每一個流程領域都會呈現, 因為應用流程領域的一般執行方法有時不需解釋,有 時則不是只有一段話就可說明的。 86 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品,並支 援與促成流程領域特定目標的達成。 GP 1.1 實施特定執行方法 實施流程的特定執行方法,以發展工作產品與提供服 務,達成流程領域的特定目標。 此特定執行方法的目的在於產出工作產品與履行服 務,該工作產品與服務是執行本流程所預期的結果。 這些執行方法可能以非正式且未遵循書面的流程說明 或計畫的方式來執行。這些執行方法執行的精確度端 視管理或執行該項工作的人員而定,不同的人執行, 其差異可能相當大。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 2.1 建立組織政策 建立並維護組織的政策,以規劃與執行流程。 此一般執行方法的目的,在於定義組織對流程的期 望,並使組織中的關鍵人員都能瞭解這些期望。一般 而言,資深管理人員擔負著建立與溝通組織之指導原 則、方向及期望的責任。 一般目標與一般執行方法 87 適用於服務的能力成熟度整合模式 1.2 版 88 CAR 原因分析與解決方案詳細說明 這政策建立組織的期望,以界定與系統化地解決缺失 與其他問題的根本原因。 CM 建構管理詳細說明 這政策建立組織的期望,:建立與維護工作產品的基 準、追踪與控制變更(在建構管理之下),以及建立 與維護基準的完整性。這政策必須解決授權與實施緊 急變更。 DAR 決策分析與解決方案詳細說明 這政策建立組織的期望,以使用正式的評估流程選擇 性地分析可能的決策,此評估流程會依已建立的準 則,評估已界定的可行方案。這政策也應該提供哪個 決策需要正式評估流程的指引。 IPM 整合專案管理詳細說明 這政策建立組織的期望,以建立與維護專案已調適流 程從開始到整個專案生命,使用專案已調適流程管理 專案,以及與相關的關鍵人員協調與合作。 IRP 事故解決方案與預防詳細說明 這政策建立組織的期望,以建立事故解決方案與預防 的方式;界定、控制與解决事故;以及對選定的事 故,決定權宜之計或解決潛在原因。 MA 度量與分析詳細說明 這政策建立組織的期望,以提供度量結果,以及以界 定的資訊需要與目的調準度量目標與活動,。 OID 組織創新與發展詳細說明 這政策建立組織的期望,以界定與推展流程與技術改 善,促成符合品質與流程績效目標。 一般目標與一般執行方法 OPD 組織流程定義詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 這政策建立組織的期望,以建立與維護一組標準流程 供組織使用,使組織的流程資產能跨組織提供,並為 整合的團隊建立規則與指引。 OPF 組織流程專注詳細說明 這政策建立組織的期望,以對將使用的流程決定流程 改善的機會,並跨組織規劃、實施與推展流程改善。 OPP 組織流程績效詳細說明 這政策建立組織的期望,以對組織的一套標準流程, 建立與維護流程績效基準。 OT 組織訓練詳細說明 這政策建立組織的期望,以界定組織策略性訓練的需 求,並提供訓練。 PMC 專案監控詳細說明 這政策建立組織的期望,以依專案計畫監督績效,當 實際績效或結果明顯地偏離計畫時,管理矯正行動, 直至結束。 PP 專案規劃詳細說明 這政策建立的組織期望在預測規劃的參數,完成內部 與外部的承諾,以及發展管理此專案的計畫。 PPQA 流程與產品品質保證詳細說明 這政策建立組織的期望,以客觀地評估流程與相關的 工作產品,是否遵循流程的說明、標準與程序,並確 保不相符處被解決。 一般目標與一般執行方法 89 適用於服務的能力成熟度整合模式 1.2 版 這政策也建立組織的期望,以對所有專案的流程與產 品品質保證。流程與產品品質必須從專案管理足夠的 獨立處理,以提供界定與報告不符合議題的客觀性。 QPM 量化專案管理詳細說明 這政策建立組織的期望,以量化地管理專案使用品質 與流程績效目標,以及統計化地管理專案已定義流程 所選定的子流程。 REQM 需求管理詳細說明 這政策建立組織的期望,以管理需求,以及界定需求 與專案計畫及工作產品間的不一致之處。 RSKM 風險管理詳細說明 這政策建立組織的期望,以界定風險管理策略,以及 界定、分析與減輕風險。 SAM 供應商協議管理詳細說明 這政策建立組的織期望,以建立、維護與滿足供應商 協議。 SCON 服務持續性詳細說明 這政策建立組織的期望,以建立一個服務持續性計 畫,促使在服務交付時的顯著中斷之後,主要服務的 重新開始,提供執行計畫的訓練,以及驗證與確認計 畫。 SD 服務交付詳細說明 這政策建立組織的期望,以定義服務交付方式、建立 服務協議、處理服務請求及交付服務。 90 一般目標與一般執行方法 服務發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展詳細說明 這政策建立組織的期望如下: • 收集關鍵人員的需要,詳述服務與服務系統組 件需求,以及分析與確認那些需求。 • 反覆週期的執行選定的服務系統解決方案,發 展服務系統與服務系統組件設計,管理介面相 容性,執行服務系統設計,以及整合服務系統 組件。 • 建立與維護驗證與確認的方法、程序、準則及 環境;執行同仁審查;以及驗證選定的工作產 品。 SST 服務系統移轉詳細說明 這政策建立組織的期望,以規劃、實施與管理服務系 統組件的轉換到交付環境。 STSM 策略服務管理詳細說明 這政策建立組織的期望,以建立與維護一組供組織使 用的標準服務,並使標準服務的說明可以跨組織取 得。 GP 2.2 規劃流程 建立並維護用來執行流程的計畫。 此一般執行方法的目的,在於決定執行流程與達成已 設定目標時所需的資源、準備執行流程所需的計畫、 準備流程說明,以及取得相關關鍵人員對該計畫的同 意。 實際上,每一流程領域對一般執行方法的應用不盡相 同。當應用於專案監控流程領域時,本一般執行方法 一般目標與一般執行方法 91 適用於服務的能力成熟度整合模式 1.2 版 所說的規劃,可能經由專案規劃流程領域相關的流程 來實現。當應用於專案規劃流程領域時,專案規劃流 程領域的一般執行方法就會設定專案規劃流程的期 望。必須瞭解本一般執行方法會強調在模式的其他地 方已設定的期望,或設定新的期望。 有關發展專案計畫,請參考專案規劃流程領域,以獲 得更多的資訊。 建立計畫包含文件化計畫及流程說明。維護計畫包括 更新計畫以反應矯正行動或需求或目標的變更。 執行流程的計畫,通常包括下列: • 流程說明 • 流程之工作產品與服務的標準及需求 • 流程績效的特定目標(例如:品質、時程、週期時 間,以及資源的使用) • 流程的活動、工作產品及服務間的相依性 • 執行流程所需的資源(例如,資金、人力及工具) • 責任與授權的指派 • 執行與支援流程所需的訓練 • 控制的工作產品及其納管的層級 • 度量需求以提供深入瞭解流程、工作產品及服務 的績效 • 納入已界定的關鍵人員 • 監控流程的活動 • 流程的客觀評估活動 92 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 • 流程與工作產品的管理審查活動 細部執行方法 1. 定義並記錄執行流程的計畫 CMF。 此計畫可能是一份獨立的文件,可能包含在另一 範圍更廣的文件中,也可能散佈在不同的文件 裡。若散佈在不同的文件裡,就必須確保任務分 工的一致性。文件可用儲存媒體或紙本方式保存 CMF。 2. 定義並記錄流程說明。 流程說明包含相關的標準與程序,可視為流程規 劃的一部分,或者當做規劃的參考。 3. 與相關的關鍵人員審查此計畫,並取得他們的同 意。 這包括審查已規劃的流程符合現行的政策、計 畫、需求及標準,以便向相關的關鍵人員提出保 證。 4. 視需要修訂計畫。 容量與可用度管理詳細說明 這計畫為執行容量與可用度管理流程,可能包含(或 參考)在專案規劃流程領域中描述的專案計畫。 原因分析與解決方案詳細說明 這計畫為執行原因分析與解決方案,可能包含(或參 考)在專案規劃流程領域中描述的專案計畫。這計畫 不同於這流程領域中數個特定執行方法所描述的行動 建議及相關的行動項目。這一般執行方法中要求的計 畫,說明計畫整體的原因分析與解決方案流程(可能 自組織維護的標準流程調適)。對照之下,流程行動 一般目標與一般執行方法 93 適用於服務的能力成熟度整合模式 1.2 版 建議與相關的行動項目,說明移除一個正在研究的特 定根本原因所需的活動。 建構管理詳細說明 這計畫為執行建構管理流程,可能包含(或參考)在 專案規劃流程領域中描述的專案計畫。 決策分析與解決方案詳細說明 這計畫為執行決策分析與解決方案流程,可能包含 (或參考)在專案規劃流程領域中描述的專案計畫。 整合專案管理詳細說明 這計畫為執行整合專案管理流程結合專案規劃與專案 監控流程的規劃。為執行整合專案管理中有關規劃的 執行方法之規劃,稱為規劃專案規劃流程的一部份。 這計畫為執行整合專案管理中有關監控的執行方法, 可能包含(或參考)在專案規劃流程領域中描述的專 案計畫。 有關一般執行方法 2.2 與專案規劃流程之間的關係, 請參考「一般目標與一般執行方法」的表 6.2。 事故解決方案與預防詳細說明 這計畫為執行事故解決方案與預防流程,可能包含 (或參考)在專案規劃流程領域中描述的專案計畫。這 計畫通常基於對服務事故數量與型態的預估。 度量與分析詳細說明 這計畫為執行度量與分析流程,可能包含(或參考) 在專案規劃流程領域中描述的專案計畫。 組織創新與推展詳細說明 這計畫為執行組織創新與推展流程不同於這流程領域 的特定執行方法中描述的推展計畫。這一般執行方法 94 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 中要求的計畫,說明這流程領域中所有特定執行方法 的廣泛規劃,從收集與分析改善建議到度量改善效 果。對照之下,這流程領域的特定執行方法中要求的 推展計畫,說明推展個別流程與技術改善,所需的規 劃。 組織流程定義詳細說明 這計畫為執行組織流程定義流程,可能是組織流程改 善計畫的一部份(或參考)。 組織流程專注詳細說明 這計畫為執行組織流程專注的流程,通常被稱為「流 程改善計畫」不同於這流程領域的特定執行方法中描 述的流程行動計畫。這一般執行方法中要求的計畫, 說明這流程領域中所有特定執行方法的廣泛規劃,從 建立組織流程需要到納入流程相關經驗至組織流程資 產中。 組織流程績效詳細說明 這計畫為執行組織流程績效流程,可能包含(或參 考)在組織流程專注流程領域中描述的組織流程改善 計畫。或它可以記錄在另一文件中,只描述組織流程 績效流程的計畫。 組織訓練詳細說明 這計畫為執行組織訓練流程不同於這流程領域的特定 執行方法中描述的組織訓練的戰略計畫。這一般執行 方法中要求的計畫,說明這流程領域所有的特定執行 方法的廣泛規劃,從建立策略訓練需要到評量組織訓 練效率。對照之下,這流程領域的特定執行方法中要 求的組織訓練戰略計畫,說明交付個別訓練課程的定 期規畫。 一般目標與一般執行方法 95 適用於服務的能力成熟度整合模式 1.2 版 專案監控詳細說明 這計畫為執行專案監控流程,可能是在專案規劃流程 領域中描述的專案計畫的一部份(或參考)。 專案規劃詳細說明 有關一般執行方法 2.2 與專案規劃流程領域之間的關 係,請參考一般目標與一般執行方法的表 6.2,以獲 得更多的資訊。 流程與產品品質保證詳細說明 提供的資源範例包括以下的工具: ● 評估工具 ● 符合追踪工具 量化專案管理詳細說明 這計畫為執行量化專案管理流程,可能包含(或參 考)在專案規劃流程領域中描述的專案計畫。 需求管理詳細說明 這計畫為執行需求管理流程,可以包含(或參考)在 專案規劃流程領域中描述的專案計畫。 風險管理詳細說明 這計畫為執行風險管理流程,可能包含(或參考)在 專案規劃流程領域中描述的專案計畫。這一般執行方 法要求的計畫,說明這流程領域所有的特定執行方法 的廣泛規劃。特別是,這計畫提供風險減少的整體方 式,但不同於特定風險的減低計畫(包括危機處理計 畫)。對照之下,這流程領域的特定執行方法中要求 的風險減低計畫,說明更聚焦的項目,例如啟動風險 處理活動的層級。 96 一般目標與一般執行方法 供應商協議管理詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 這計畫的部份為執行供應商協議管理流程,可能是在 專案規劃流程領域中描述的專案計畫的一部份(或參 考)。通常,然而,計畫的有些部份屬於專案外圍的 群組,例如,契約管理。 服務持續性詳細說明 這計畫為執行服務持續流程,可能包含(或參考)在 專案規劃流程領域中描述的專案計畫。或者,這計畫 可能包含在組織層級維護的更廣泛的營運持續性計畫 的一部份。 另一種情形,這計畫為執行的服務持續流程不同於這 流程領域的特定執行方法中描述的服務持續性計畫。 這一般執行方法要求的計畫,說明這流程領域所有的 特定執行方法的廣泛規劃,從界定與優先順序重要功 能到驗證與確認結果。對照之下,這流程領域的一個 特定執行方法中要求的服務持續性計畫,說明如何在 服務交付的顯著中斷後,恢復關鍵服務。 服務交付詳細說明 這計畫為執行服務交付流程,可能包含(或參考)在 專案規劃流程領域中描述的專案計畫。 一般目標與一般執行方法 97 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 服務系統發展詳細說明 這計畫為執行服務系統發展流程,可能是在專案規劃 流程領域中描述的專案計畫的一部份(或參考)。 服務系統移轉詳細說明 服務系統移轉的整體規劃,可能包含(或參考)在專 案規劃流程領域中描述的專案計畫。此外,特定服務 系統移轉相關的規劃,通常說明在服務系統移轉計畫 中。 這計畫為執行的服務系統移轉流程不同於這流程領域 的特定執行方法中描述的服務系統移轉計畫。這一般 執行方法中要求的計畫,說明這流程領域所有的特定 執行方法的廣泛規劃,從分析服務系統移轉需要到評 量與控制轉換的衝擊。對照之下,這流程領域的特定 執行方法中要求的服務系統移轉計畫,說明服務系統 特定轉換的規劃。 策略服務管理詳細說明 這計畫為執行策略服務管理流程不同於這流程領域的 特定執行方法中描述的標準服務計畫。這一般執行方 法中要求的計畫,說明這流程領域所有的特定執行方 法的廣泛規劃。 GP 2.3 提供資源 提供充分的資源,以執行流程、發展工作產品及提供 流程服務。 此一般執行方法的目的,在於確保在需要時能獲得定 義在計畫中執行流程所需的資源。資源包含充分的資 金、合適的硬體設施、有技能的人力及適當的工具。 98 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 「充分」一詞的詮釋則視許多因素而定,而且隨時可 能改變。不充分的資源可以靠增加資源,或減少需 求、限制及承諾來解決。 容量與可用度管理詳細說明 提供資源的範例如下: • 遠端分析工具 • 監督工具 原因分析與解決方案詳細說明 提供資源的範例如下: • 資料庫系統 • 流程模型工具 • 統計分析套裝 • 方法與分析技術(例如:石川馨或魚骨圖、柏 拉圖分析、長條圖、流程能力研究、管控圖) 建構管理詳細說明 提供資源的範例如下: • 建構管理工具 • 資料管理工具 • 建立檔案與重製工具 • 資料庫程式 一般目標與一般執行方法 99 適用於服務的能力成熟度整合模式 1.2 版 決策分析與解決方案詳細說明 提供資源的範例如下: • 模擬與模型工具 • 雛型工具 • 執行調查的工具 整合專案管理詳細說明 提供資源的範例如下: • 問題追踪與報告套裝 • 群體軟體 • 視訊會議 • 整合決策資料庫 • 整合產品支援環境 事故解決方案與預防詳細說明 提供資源的範例如下: • 諮詢窗口工具 • 遠距分析工具 • 自動監督工具 • 事故管理系統 度量與分析詳細說明 度量人員可以是全職或兼職人員。一個度量組可以存 在,也可以不存在以支援跨多重專案的度量活動。 100 一般目標與一般執行方法 提供資源的範例如下: • 統計的套裝 • 支援跨網路資料收集的套裝 組織創新與推展詳細說明 提供資源的範例如下: • 模擬的套裝 • 雛型工具 • 分析套裝 • 動態系統模型 • 登錄線上技術資料庫及刊物 • 流程模型工具 關於適用於服務的能力成熟度整合模式 1.2 版 組織流程定義詳細說明 流程群組主要管理組織流程定義活動。這群組通常由 核心專業人士組成,其主要責任為協調組織流程的改 善。這群組由流程擁有者及下列不同領域專業人士所 支援: • 專案管理 • 合適的工程領域 • 建構管理 • 品質保證 提供資源的範例如下: • 資料庫管理系統 • 流程模型工具 • 網頁建置與瀏覽器 一般目標與一般執行方法 101 適用於服務的能力成熟度整合模式 1.2 版 組織流程專注詳細說明 提供資源的範例如下: • 資料庫管理系統 • 流程改善工具 • 網頁建置與瀏覽器 • 群體軟體 • 品質改善工具(例如,因果分析圖、親和圖、 柏拉圖表) 組織流程績效詳細說明 在統計及統計流程管制的特別專家可能需要為組織的 標準流程建立流程績效基準。 提供資源的範例如下: • 資料庫管理系統 • 系統動態模型 • 流程模型工具 • 統計分析套裝 • 問題追踪套裝 組織訓練詳細說明 提供資源的範例如下: • 主題專家 • 課程設計者 • 教學的設計者 • 講師 • 訓練行政人員 102 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 訓練可能需要特別的設備。當需要時,發展或購買組 織訓練流程活動所需的設備。 提供資源的範例如下: • 分析訓練需要的器材 • 訓練使用的工作站 • 教學設計的工具 • 發展簡報資料的套裝 專案監控詳細說明 提供資源的範例如下: • 成本追踪系統 • 工作報告系統 • 行動項目追踪系統 • 專案管理及時程規劃 專案規劃詳細說明 在專案規劃中可能需要特別的專業、設備及設施。在 專案規劃中的特別專業可能包括: • 有經驗的預測者 • 時程規劃者 • 在應用領域的技術專家(例 如:產品領域、技術) 提供資源的範例如下: • 表格程式 • 預測的模型 • 專案規劃和排程套裝 一般目標與一般執行方法 103 適用於服務的能力成熟度整合模式 1.2 版 流程與產品品質保證詳細說明 提供資源的範例如下: • 評估工具 • 不相符之追踪工具 組織流程績效詳細說明 可能需要統計及統計化流程控制的特別專業,以針對 選定的子流程定義其統計管理的技術,但員工將使用 工具及技術執行統計的管理。可能需要統計的特別專 業分析與解釋從統計管理產出的度量值。 提供資源的範例如下: • 系統動態模型 • 自動化的含蓋測試的分析 • 統計的流程及品質控制套裝 • 統計的分析套裝 需求管理詳細說明 提供資源的範例如下: • 需求追溯工具 • 可追溯的工具 104 一般目標與一般執行方法 風險管理詳細說明 提供資源的範例如下: • 風險管理資料庫 • 風險減輕工具 • 雛型工具 • 模型與模擬工具 供應商協議管理詳細說明 提供資源的範例如下: • 較優先的供應商名單 • 需求追踪的程序 • 專案管理與排程程序 關於適用於服務的能力成熟度整合模式 1.2 版 服務持續性詳細說明 服務持續性有賴於獲得特別及足夠的資源。遠端的位 置、安全的網絡、設施及裝備應該要界定、獲得以及 事先準備,以確保在發生顯著的中斷時服務系統運作 能持續。為執行服務持續性計畫應準備所需的特別訓 練設施及相關的資源。最後,為用來驗證與確認服務 持續準備作業,應發展與購買特別的測試設施、裝備 及工具。 一般目標與一般執行方法 105 適用於服務的能力成熟度整合模式 1.2 版 提供資源的範例如下: • 備份溝通機制及網路 • 檔案備份及儲存 • 用做訓練的工作站 • 模型及模擬工具 • 測試管理工具 服務交付詳細說明 服務交付需要合適的服務系統運作,包括經過訓練的 員工、基礎架構、工具、流程、消耗品及其他資源。 此外,服務系統的運作隱含持續的需要足夠的資源。 例如,服務系統內經常使用的組件可能需要升級、取 代或淘汰;服務交付的員工可能需要再訓練、增加、 輪調或減少;以及消耗品可能需要再補充,以確保服 務可以根據服務合約交付。 有些服務系統的組件可能需要發展或購買,這限制條 件可能需要依服務系統發展及供應商協議管理流程領 域所描述的資源取得。 提供資源的範例如下: ●請求管理系統 ●自動化監督工具 106 一般目標與一般執行方法 服務系統發展補充 服務系統發展詳細說明 提供資源的範例如下: • 需求規格工具 • 模擬與模型工具 • 雛型工具 • 劇本定義與追踪工具 • 設計規格工具 • 建造與組裝工具 • 測試管理工具 • 測試個案產生工具 • 監督工具 • 測試設備與環境 關於適用於服務的能力成熟度整合模式 1.2 版 一般目標與一般執行方法 107 適用於服務的能力成熟度整合模式 1.2 版 服務系統移轉詳細說明 提供資源的範例如下: • 支援移轉的員工 • 安裝與推展工具 • 取消與儲存的機制 策略服務管理 資深管理人員、策略規劃者、產品經理、產品線經理 或檔案經理通常管理策略服務管理執行方法。 提供資源的範例如下: • 策略需要與能力之資料來源 • 文件管理或建構管理工具 • 產品管理技術 GP 2.4 指派責任 指派流程的責任與授權,以執行流程、發展工作產品 及提供流程服務。 此一般執行方法的目的,在於整個執行流程和達成指 定結果的過程中,都有人能負責任。被指派責任的人 一定要取得適當的授權,以執行該責任。 可以用詳細的工作說明或文件(如執行流程的計畫)來 指派責任。在流程的生命週期內,只要責任的指派和 接受都能獲得保證,動態的責任指派也是執行本一般 執行方法的一種合理方法。 108 一般目標與一般執行方法 細部執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 1. 指派整體性的責任與授權,以執行流程。 2. 指派責任及授權以執行流程的特定工作。 3. 確定被指派責任與授權的人,都能瞭解和接受。 事故解決方案與預防詳細說明 指派責任給第一層服務事故處理(例如,諮詢窗口) 及第二層的處理(例如,由服務、平台、功能或技術 組織的支援小組)。 流程與產品品質保證詳細說明 指派責任給執行流程與產品品質保證評估的人,並有 足夠的獨立性及客觀性來防止主觀或偏見。 服務持續性詳細說明 指派責任給組織(或專案)的備份管理小組,以在顯 著的中斷發生時,接替管理責任。 服務交付詳細說明 指派責任給建立服務協議、接受服務請求、溝通狀態 資訊(例如,籍由諮詢窗口) 、操作及維護服務系統、 處理服務請求、及解決服務事故(例如,藉由服務、 平台、功能或技術所組織的支援群組) 。 策略服務管理詳細說明 指派責任給規劃、執行及管理轉換。除此之外,清楚 的指派關鍵人員通知的活動,以確保公開的溝通及確 認。當轉換不成功時,指派回復及取消。 一般目標與一般執行方法 109 適用於服務的能力成熟度整合模式 1.2 版 GP 2.5 訓練人員 依需要訓練人員,以執行或支援流程。 此一般執行方法的目的,在於確保人員具有必要的技 巧和專業知識,以執行或支援流程的執行。 提供執行工作的人員適當的訓練,並針對與執行工作 人員互動的人員,實施概要訓練以提供指導。 例如:訓練的進行方式,包括自修、自我引導的訓 練、線上學習、在職訓練、同仁指導及正式的課堂訓 練等。 訓練可建立對流程的共識,以及傳授執行流程時所需 的技巧和專業知識,所以訓練可提供協助以成功地執 行流程。 有關發展人員的技能與知識以便能成功有效率地執行 角色請參考組織訓練流程領域,以獲得更多資訊。 容量與可用度管理詳細說明 訓練主題的範例如下: • 容量與可用度管理人員的角色、責任及授權 • 容量與可用度管理的標準、程序及方法 原因分析與解決方案詳細說明 訓練主題的範例如下: • 品質管理的方法(例如,根原因分析) 110 一般目標與一般執行方法 建構管理詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 訓練主題的範例如下: • 建構管理人員的角色、責任及授權 • 建構管理的標準、程序及方法 • 建構管理資料庫系統 決策分析與解決方案詳細說明 訓練主題的範例如下: • 正式的決策分析 • 評估依照準則的替代解決方案的方法 整合專案管理詳細說明 訓練主題的範例如下: • 調適組織的標準流程以符合專案的需要 • 基於專案已調適流程來管理專案的程序 • 使用組織的度量儲存庫 • 整合管理 • 內部團隊協調 • 團隊問題解決 一般目標與一般執行方法 111 適用於服務的能力成熟度整合模式 1.2 版 事故解決方案與預防詳細說明 訓練主題的範例如下: • 服務事故準則 • 與通報服務事故及被影響的人互動 • 事故管理系統 • 分析的技術(例如,魚骨圖,柏拉圖分析等) 度量與分析詳細說明 訓練主題的範例如下: • 統計的技術 • 資料收集、分析與通報程序 • 目標相關度量的發展(例如,目標問題矩陣圖) 組織創新與推展詳細說明 訓練主題的範例如下: • 規劃、設計與執行先導計畫 • 成本效益分析 • 技術移轉 • 變更管理 112 一般目標與一般執行方法 組織流程定義詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 訓練主題的範例如下: • CMMI 及其他流程與流程改善參考模式 • 成本效益分析 • 技術移轉 • 變更管理 組織流程專注詳細說明 訓練主題的範例如下: • 資料庫管理系統 • 流程改善工具 • 網頁建置與瀏覽器 • 群體軟體 • 品質改善工具(例如,因果分析圖、親和圖、 柏拉圖表) 組織流程績效詳細說明 訓練主題的範例如下: • 流程和流程改善模式 • 量化和統計方法(例如,預測模式、柏拉圖分 析、管制表) 一般目標與一般執行方法 113 適用於服務的能力成熟度整合模式 1.2 版 組織訓練詳細說明 有關一般執行方法 2.5 和組織訓練流程領域間的關係,請 參考一般目標和一般執行方法的表 6.2 訓練主題的範例如下: • 知識和技巧需求分析 • 教學式的設計 • 教學的技能(例如,訓練講師) • 主題式的再訓練 專案監控詳細說明 訓練主題的範例如下: • 專案監控 • 風險管理 • 資料管理 專案規劃詳細說明 訓練主題的範例如下: • 預測 • 預算 • 協調 • 風險界定與分析 • 資料管理 • 規劃 • 排定時程 114 一般目標與一般執行方法 流程與產品品質保證詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 訓練主題的範例如下: • 應用領域 • 客戶關係 • 專案的流程說明、標準、程序和方法 • 品質保證目標、流程說明、標準、程序、方法 和工具。 品質流程管理詳細說明 訓練主題的範例如下: • 流程模式和分析 • 流程度量資料選擇、定義和收集。 需求管理詳細說明 訓練主題的範例如下: • 應用領域 • 需求定義、分析、檢視和管理 • 需求管理工具 • 建構管理 • 協調和衝突解決 1. 一般目標與一般執行方法 115 適用於服務的能力成熟度整合模式 1.2 版 風險管理詳細說明 訓練主題的範例如下: • 風險管理概念和活動(例如,風險界定、評量、 監督、降低) • 降低風險之度量選擇 供應商協議管理詳細說明 訓練主題的範例如下: • 與供應商協商和共事的相關規定和業務執行方 法 • 採購規劃和準備 • 現成商品之採購 • 供應商評量和選擇 • 協商和衝突解決方案 • 供應商管理 • 已採購商品之測試和轉移 • 已採購商品之驗收、儲存、使用和維護 服務持續性詳細說明 訓練主題的範例如下: • 服務系統及其組件 • 支援服務系統(及服務交付)運作所使用的業務 功能和資源 • 服務持續計畫的內容 • 相關的本地、州際的和聯邦的災難準備活動。 116 一般目標與一般執行方法 服務交付詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 訓練主題的範例如下: • 服務交付人員的角色、責任和授權 • 服務協議、服務要求、和服務交付標準、程 序、和方法。 • 要求管理系統 • 其他的服務系統組件 服務系統發展補充 服務系統發展詳細說明 訓練主題的範例如下: • 特別服務領域的專業知識 • 需求定義、分析、取得、規格、模式和追 踪。 • 設計方法 • 通用的服務系統組件和介面設計型態 • 標準(例如,產品、安全、人員因素、保安、 交付、環境) • 整合方法、工具和設施 • 驗證和確認原則、標準、方法、工具和設施 • 同仁審查準備和程序 • 會議進行 一般目標與一般執行方法 117 適用於服務的能力成熟度整合模式 1.2 版 服務系統移轉詳細說明 訓練主題的範例如下: • 轉換的規劃和監控 • 取消轉換的方式 • 推展後的檢視流程 策略服務管理 訓練主題的範例如下: • 策略規劃技術例如劇本規劃、SWOT及需求 分析 • 市場研究技術 • 產品規劃與管理 • 檔案管理 • 行銷溝通 GP2.6 管理建構 將指定的流程工作產品,納入適當層級的控制。 此一般執行方法的目的,在於建立並維護流程的指定 工作產品(或其說明)在它整個生命週期的完整性。 在執行流程的計畫中須界定什麼是指定的工作產品, 以及該工作產品納入適當控制的層級。 不同的工作產品,以及在不同的時間點,所適用的控 制層級可能不同。對某些工作產品而言,進行版本管 制可能就足夠。也就是不論過去或是現在,工作產品 在某段時間所用的版本都很清楚,而且改變都在控制 下進行。版本管制通常都由工作產品的擁有者(可能是 個人、小組或團隊)單獨控制。 118 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 有時將工作產品置於正式或「基準(baseline)」的建構管 理是非常重要的。這種類型的控制會在事先設定的時 間點,定義和建立基準。這些基準會被正式審查及同 意,並當做工作產品進一步發展的基礎。 有關將工作產品納入建構管理,請參考建構管理流程 領域,以獲得更多資訊。 在版本控制與正式的控制之間,可能有其他層級的建 構管理。在不同的時間點,經界定的工作產品可能納 入不同的控制層級之下。 容量與可用度管理詳細說明 管控下的工作產品的範例如下: • 容量與可用度管理記錄 • 容量與可用度管理報告 原因分析與解決方案詳細說明 管控下的工作產品的範例如下: • 行動提案 • 為執行選定的行動提案 • 原因分析與解決方案記錄 一般目標與一般執行方法 119 適用於服務的能力成熟度整合模式 1.2 版 建構管理詳細說明 有關一般執行方法 2.6 和建構管理流程領域間的關係,請 參考一般目標和一般執行方法的表 6.2。 管控的等級必須足夠符合業務需求、降低失敗的風險和說 明服務的重要性。 管控下的工作產品的範例如下: • 存取清單 • 變更狀態報告 • 變更需求資料庫複製 • 建構管控委員會會議記錄 • 制式的基準線 決策分析與解決方案詳細說明 管控下的工作產品的範例如下: • 何時採用正式的評估流程的指引 • 包含建議的解決方案的評估報告 整合專案管理詳細說明 管控下的工作產品的範例如下: • 專案的已調適流程 • 專案規畫 • 影響專案的其他計畫 • 整合的計畫 • 從專案收集的實際流程及產品度量 120 一般目標與一般執行方法 事故解決方案與預防詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 管控下的工作產品的範例如下: • 事故管理記錄 • 事故解決方案與預防記錄 • 行動提案 • 解決方法描述和指示 • 事故資料庫複製 度量與分析詳細說明 管控下的工作產品的範例如下: • 基礎和衍生度量的規格 • 資料收集與儲存程序 • 基礎和衍生度量資料組 • 分析結果和草擬報告 • 資料分析工具 組織創新與推展詳細說明 管控下的工作產品的範例如下: • 從先導計畫記錄下的學習經驗 • 修改的流程和技術改善度量、目標、優先順序 和推展計畫 • 更新的訓練教材 一般目標與一般執行方法 121 適用於服務的能力成熟度整合模式 1.2 版 組織流程定義詳細說明 管控下的工作產品的範例如下: • 組織的標準流程組 • 生命週期模式的描述 • 組織的標準流程組的調適指引 • 通用產品與流程度量組的定義 • 組織的度量資料 組織流程專注詳細說明 管控下的工作產品的範例如下: • 流程改善建議 • 組織的核定流程行動計畫 • 推展組織流程資產的訓練教材 • 在新專案推展組織的標準流程的指引 • 組織流程評鑑的計畫 組織流程績效詳細說明 管控下的工作產品的範例如下: • 組織品質與流程績效目標 • 選定的流程績效度量的定義 • 組織流程績效的基準線資料 122 一般目標與一般執行方法 組織訓練詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 管控下的工作產品的範例如下: • 組織訓練戰略計畫 • 訓練記錄 • 訓練教材及支援工具 • 講師評量格式 專案監控詳細說明 管控下的工作產品的範例如下: • 專案狀態時程 • 專案度量資料分析 • 所獲值報告 專案規劃詳細說明 管控下的工作產品的範例如下: • 分工結構圖 • 專案計畫 • 資料管理計畫 • 關鍵人員參與計畫 流程與產品品質保證詳細說明 管控下的工作產品的範例如下: • 不相符報告 • 評量記錄和報告 一般目標與一般執行方法 123 適用於服務的能力成熟度整合模式 1.2 版 品質流程管理詳細說明 管控下的工作產品的範例如下: • 專案的調適流程中所包含的子流程 • 度量的操作定義,它們在子流程中收集旳點及 如何決定度量的整合。 • 收集的度量 124 一般目標與一般執行方法 需求管理詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 管控下的工作產品的範例如下: • 需求 • 需求追踪矩陣圖 風險管理詳細說明 管控下的工作產品的範例如下: • 風險管理策略 • 界定的風險項目 • 降低風險計畫 供應商協議管理詳細說明 管控下的工作產品的範例如下: • 工作說明 • 供應商協議 • 協議備忘錄 • 子合約 • 優先供應商清單 服務持續性詳細說明 管控下的工作產品的範例如下: • 服務持續計畫 • 在服務持續計畫中用來訓練人員的教材 • 訓練的記錄 • 驗證和確認的程序和準則 • 驗證和確認的報告 一般目標與一般執行方法 125 適用於服務的能力成熟度整合模式 1.2 版 服務交付詳細說明 管控下的工作產品的範例如下: • 服務協議 • 服務交付和要求管理報告 • 要求管理資料庫 126 一般目標與一般執行方法 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展詳細說明 管控下的工作產品的範例如下: • 關鍵人員的需求 • 服務系統架構 • 服務、服務系統、服務系統組件及介面需求 • 服務系統、服務系統組件及介面設計 • 設計及服務系統組件再使用的準則 • 技術規格與員工解決方案 • 執行設計(例如操作程序、已製造的消耗品組 件) • 整合的服務系統組件評量 • 服務系統組件整合順序 • 整合程序及準則 • 驗證與確認程序及準則 • 驗證與確認報告 • 同仁審查訓練教材 • 同仁審查資料 • 使用者、裝置、交付、事故管理及維護文件 服務系統移轉詳細說明 管控下的工作產品的範例如下: • 轉換計畫 • 服務系統分析報告 一般目標與一般執行方法 127 適用於服務的能力成熟度整合模式 1.2 版 • 推展的報告與記錄 • 轉換評估與發展後的審查報告 策略服務管理 管控下的工作產品的範例如下: • 組織的標準服務說明 • 服務等級說明 • 組織的標準服務調適指引 GP 2.7 界定並納入相關關鍵人員 依計畫界定並納入流程相關關鍵人員。 此一般執行方法的目的,在於建立並維護關鍵人員在 流程執行期間預期的參與程度。 依描述關鍵人員參與之適當計畫所述,將相關的關鍵 人員納入。將關鍵人員適當地納入,以參與下列活 動: z 規劃 z 決策 z 承諾 z 溝通 z 協調 z 審查 z 評鑑 z 需求定義 z 問題或議題的解決方案 128 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 有關納入關鍵人員的專案規劃,請參考專案規劃流程 領域,以獲得更多資訊。 規劃關鍵人員參與是為了確保有足夠的關鍵人員互 動,這對於完成流程是必要的,同時避免過多關鍵人 員的小組成員阻礙流程的執行。 細部執行方法 1. 界定與流程有關的關鍵人員,並規劃其適當的參 與。 由輸入的供應者、輸出的使用者,以及流程活動 的執行者之中,界定出相關的關鍵人員。一旦界 定相關的關鍵人員,也會規劃相關的關鍵人員在 流程活動的參與程度。 2. 將這些身分界定的方式,與專案規劃人員或其他 適當的規劃人員一起分享。 3. 依規劃的方式,納入相關的關鍵人員。 一般目標與一般執行方法 129 適用於服務的能力成熟度整合模式 1.2 版 容量與可用度管理詳細說明 關鍵人員參與的活動範例如下: • 檢視容量與可用度管理報告與解決議題 • 當不可能直接影響使用資源的要求時與關鍵人 員緊密合作 原因分析與解決方案詳細說明 關鍵人員參與的活動範例如下: • 執行原因分析 • 評量行動提案 建構管理詳細說明 關鍵人員參與的活動範例如下: • 建立基準線 • 檢視建構管理系統報告及解決議題 • 評量改變建構項目的影響 • 執行建構稽核 • 檢視建構管理稽核結果 130 一般目標與一般執行方法 決策分析與解決方案詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 關鍵人員參與的活動範例如下: • 建立與正式評估流程有關議題的指引 • 建立評估準則 • 界定與評估替代方案 • 選擇評估方法 • 選擇解決方案 整合專案管理詳細說明 有關一般執行方法 2.7 和在這流程領域的管理關鍵人員參 與特定執行方式間的關係,請參考一般目標和一般執行方 法的表 6.2。 關鍵人員參與的活動範例如下: • 有關調適組織流程資產的解決方案議題 • 專案計畫和影響專案的其他計畫的解決方案議 題 • 檢視專案績效以連結現行和預計的需要、目標 和需求 事故解決方案與預防詳細說明 關鍵人員參與的活動範例如下: • 建立達成事故解決方案與預防的方式 • 界定服務事故和記錄相關資訊 • 分析服務事故以決定最佳行動方案 • 檢視解決服務事故的行動結果 一般目標與一般執行方法 131 適用於服務的能力成熟度整合模式 1.2 版 度量與分析詳細說明 關鍵人員參與的活動範例如下: • 建立度量目標與程序 • 評估度量資料 • 基礎和衍生度量資料組 • 提供有意義的回饋給負責提供分析和結果資料 的人 組織創新與推展詳細說明 關鍵人員參與的活動範例如下: • 檢視流程和技術改善建議,其可能對流程績效 或客戶及最終使用者的滿意度有重要影響 • 就流程和技術改善推展活動的狀態和結果,提 供有意義的回饋給組織 132 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 回饋通常包括下列: • 通知提交流程和技術改善建議的人有關建議的處 理。 • 常態性地通知相關關鍵人員有關選擇與推展流程 和技術改善的計畫和狀態 • 準備和散布流程和技術改善的選擇與推展活動 組織流程定義詳細說明 關鍵人員參與的活動範例如下: • 檢視組織的標準流程組 • 檢視生命週期模式 • 調適指引的解決方案議題 • 評估通用產品與流程度量組的定義 • 檢視工作環境的標準 一般目標與一般執行方法 133 適用於服務的能力成熟度整合模式 1.2 版 組織流程專注詳細說明 關鍵人員參與的活動範例如下: • 與流程擁有者協調和合作流程改善活動,其是 或將是執行流程及支援組織的人(例如,訓練 人員、品質保證代表) • 建立組織流程需求與目標 • 評鑑組織流程 • 執行流程行動計畫 • 協調和合作執行先導計畫以測試選定的改善 • 推展組織流程資產和變動到組織流程資產 • 溝通和規劃、執行和推展流程改善相關的計 畫、狀態、活動和結果 組織流程績效詳細說明 關鍵人員參與的活動範例如下: • 建立組織品質與流程績效目標及其優先順序 • 檢視與解決組織流程績效基準線的議題 • 檢視與解決組織流程績效模式的議題 134 一般目標與一般執行方法 組織訓練詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 關鍵人員參與的活動範例如下: • 建立合作環境以討論訓練需求和訓練效率,來 確保符合組織的訓練需求 • 界定訓練需求 • 檢視組織的訓練戰略計畫 • 評估訓練效率 專案監控詳細說明 有關一般執行方法 2.7 和在專案監控流程領域的監控關鍵 人員參與特定執行方式間的關係,請參考一般目標和一般 執行方法的表 6.2。 關鍵人員參與的活動範例如下: • 評估專案與計畫 • 檢視承諾與解決方案議題 • 檢視專案風險 • 檢視資料管理活動 • 檢視專案進度 • 管理矯正措施直到結案 專案規劃詳細說明 有關一般執行方法 2.7 和在專案規劃流程領域的規劃關鍵 人員參與特定執行方式間的關係,請參考一般目標和一般 執行方法的表 6.2。 一般目標與一般執行方法 135 適用於服務的能力成熟度整合模式 1.2 版 關鍵人員參與的活動範例如下: • 建立預測 • 檢視與解決專案風險的完成度與正確度議題 • 檢視資料管理計畫 • 檢視專案計畫與解決工作與來源的議題 流程與產品品質保證詳細說明 關鍵人員參與的活動範例如下: • 建立流程與工作產品的目標評估準則 • 評估流程與工作產品 • 解決不相符的議題 • 追踪不相符的議題直到結案 品質流程管理詳細說明 關鍵人員參與的活動範例如下: • 建立專案目標 • 解決專案品質和流程績效目標間的議題 • 評鑑選定的子流程的績效 • 界定與管理達成專案品質和流程績效目標的風 險 • 界定應採取的矯正措施 136 一般目標與一般執行方法 需求管理詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 從客戶、最終使用者、發展者、製造商、測試者、供應 商、行銷人員、維護人員、處理人員和其他可能影響流程 及產品或被影響的人中,選擇相關的關鍵人員。 關鍵人員參與的活動範例如下: • 解決瞭解需求的議題 • 評估需求改變的影響 • 溝通相對追溯性 • 界定專案計畫、工作產品和需求間的不一致處 一般目標與一般執行方法 137 適用於服務的能力成熟度整合模式 1.2 版 風險管理詳細說明 關鍵人員參與的活動範例如下: • 建立自由與公開討論風險的協同環境 • 檢視風險管理策略及降低風險計畫 • 參與風險界定、分析與降低的活動 • 溝通與通報風險管理狀態 供應商協議管理詳細說明 關鍵人員參與的活動範例如下: • 建立評估潛在供應商的準則 • 檢視潛在的供應商 • 建立供應商協議 • 解決與供應商的議題 • 檢視供應商績效 服務持續性詳細說明 關鍵人員參與的活動範例如下: • 界定支援服務交付的重要功能和資源 • 檢視服務持續計畫 • 檢視訓練教材 • 驗證和確認活動 138 一般目標與一般執行方法 服務交付詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 關鍵人員參與的活動範例如下: • 建立服務協議 • 提交服務要求 • 檢視服務要求管理報告和解決議題 • 檢視解決服務要求的行動結果 一般目標與一般執行方法 139 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 服務系統發展詳細說明 關鍵人員參與的活動範例如下: • 檢視與評估需求是否足夠符合需要、期望、 限制和介面 • 建立運作的概念和劇本 • 建立服務和服務系統需求 • 評估成本、時程、希望的資源需要和風險 • 發展替代方案解決方案和選擇準則 • 取得外部介面規格和設計描述的許可 • 發展服務系統架構 • 評估製造、購買或再使用服務系統組件的替 代方案 • 執行設計 • 檢視完成度的介面說明 • 建立服務系統整合程序、準則和順序 • 整合和裝置服務系統組件 • 選擇驗證與確認的服務系統組件 • 建立驗證與確認的方法、程序及準則 • 檢視服務系統組件的驗證與確認結果 • 檢視在驗證與確認期間與客戶或最終使用者 界定的議題 140 一般目標與一般執行方法 服務系統移轉詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 關鍵人員參與的活動範例如下: • 規劃與監控服務系統移轉 • 通知關鍵人員轉換的狀態與議題 • 推展後的檢視 策略服務管理 關鍵人員參與的活動範例如下: • 確認業務目標 • 檢視組織的標準服務 • 檢視標準服務的說明 • 檢視組織的服務等級 • 解決調適指引議題 GP2.8 監控流程 依流程的執行計畫,監控流程,並採取適當的矯正措 施。 此一般執行方法的目的,在於執行直接的日常流程監 控。維護流程適當的能見度,以便於必要時,採取適 當的矯正措施。流程監控包括流程或流程所產生之工 作產品參數的度量工作。 有關發展和維護度量能力以支援管理資訊需求,請參 考度量與分析流程領域,以獲得更多資訊。 有關瞭解專案進度,以在專案績效明顯偏離專案時, 採取適當的矯正措施,請參考專案監控流程領域,以 獲得更多資訊。 一般目標與一般執行方法 141 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 依據規劃要行的流程,度量其實際績效。 度量是搜集來自於流程、工作產品及服務。 2. 審查流程的實際執行結果,是否與流程的執行計 畫相符。 3. 與第一線負責流程的管理者審查流程的活動、進 度及結果,並界定可能的問題。 此審查的目的,在於提供第一線管理者對流程適 當的瞭解。這類審查的進行時機可以是定期的, 也可以在事件發生時才進行。 4. 界定並評估與流程的執行計畫有顯著差異的影響。 5. 界定發生在執行流程時和流程執行計畫的問題。 6. 當需求與目標不符合、議題被界定,或進度嚴重落 後於流程執行計畫的要求時,採取矯正措施。 採取矯正措施之前,應先考慮其潛在風險。 矯正措施可涵蓋下列內容: • 採取補救措施,以修補有缺失的工作產品或服 務 • 變更流程的執行計畫 • 調整資源包含人員、工具及其他資源 • 對已承諾事項的變更進行溝通 • 確保需求和目標的改變必須符合要求 • 終止工作 7. 追蹤矯正措施直到結案。 142 一般目標與一般執行方法 容量與可用度管理詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 用在監控的度量和工作產品的範例如下: • 和容量與可用度管理原因有關的服務中斷,所導 致每個月損失的客戶總時數 • 和容量與可用度管理原因有關的服務中斷,所導 致每個月每個客戶損失的時數 • 由於容量與可用度管理有關的原因,而不符合服 務回應時間要求的比例 • 資源使用上趨勢預測的正確性 原因分析與解決方案詳細說明 用在監控的度量和工作產品的範例如下: • 移除的根原因數量 • 每一個在原因分析與解決方案流程的案例中的品 質或流程績效的改變 • 執行選定的行動提案的活動時程 建構管理詳細說明 用在監控的度量和工作產品的範例如下: • 改變建構項目的數量 • 執行建構稽核的數量 • 建構管制委員會或稽核活動的時程 決策分析與解決方案詳細說明 用在監控的度量和工作產品的範例如下: • 使用正式評估流程議題的成本與效益比例 • 執行交易研究的時程 一般目標與一般執行方法 143 適用於服務的能力成熟度整合模式 1.2 版 整合專案管理詳細說明 用在監控的度量和工作產品的範例如下: • 專案調適流程的變動數量 • 調適組織標準流程的時程和努力 • 介面協調議題趨勢(也就是,界定的數量和結案 的數量) • 專案調適活動的時程 事故解決方案與預防詳細說明 用在監控的度量和工作產品的範例如下: • 提醒潛在服務事故的能力、績效和可用度資料 • 收到的服務事故 • 解決服務事故的前置時間與在服務等級協議中調 適的前置時間的比較 • 在服務事故解決前支援團隊間的轉移數量 • 執行行動提案的時程以避免同類的服務事故重複 發生 度量與分析詳細說明 用在監控的度量和工作產品的範例如下: • 專案使用流程和績效度量的比例 • 說明度量目標的比例 • 收集與檢視度量資料的時程 144 一般目標與一般執行方法 組織流程定義詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 用在監控的度量和工作產品的範例如下: • 專案使用流程建構和組織標準流程的流程元素的 比例 • 偵測每一個組織標準流程的流程元素的密度 • 由於人體工程學問題的工人補償抱怨的數量 • 發展一個流程或流程改變的時程 一般目標與一般執行方法 145 適用於服務的能力成熟度整合模式 1.2 版 組織流程專注詳細說明 用在監控的度量和工作產品的範例如下: • 流程改善提議的提交、接受或執行的數量 • 獲得的 CMMI 成熟等級或能力等級 • 推展組織流程資產的時程 • 專案使用現行組織標準流程的比例(或現行套組 的調適版本) • 執行組織標準流程所伴隨的議題趨勢 組織流程績效詳細說明 用在監控的度量和工作產品的範例如下: • 與工作產品及工作屬性改變有關的組織流程績效 趨勢(例如,規模的成長、工作量、時程、品質 • 收集與檢視用在建立流程績效基準線的度量的時 程 組織訓練詳細說明 用在監控的度量和工作產品的範例如下: • 交付訓練課程的數量(例如規劃的與實際的對照) • 訓練後的評估評比 • 訓練課程品質調查評比 • 交付訓練的時程 • 發展課程的時程 專案監控詳細說明 有關一般執行方法 2.8 和專案監控流程領域間的關係,請 參考一般目標和一般執行方法的表 6.2。 146 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 用在監控的度量和工作產品的範例如下: • 開放的和封閉的矯正措施數量 • 每月財務資料收集、分析和通報的狀態時程 • 執行檢視的數量和型態 • 檢視的時程(規劃的與實際的對照及分段的目標 日期) • 收集與分析監控資料的時程 專案規劃詳細說明 用在監控的度量和工作產品的範例如下: • 計畫的改版數量 • 每一個計畫版本的成本、時程和工作量的差異 • 專案計畫的發展與維護時程 流程與產品品質保證詳細說明 用在監控的度量和工作產品的範例如下: • 已規劃的和已執行的目標流程評估的差異 • 已規劃的和已執行的目標工作產品的差異 • 目標評估的時程 品質流程管理詳細說明 用在監控的度量和工作產品的範例如下: • 統計管理下的子流程檔案(例如,規劃在統計管 理下的數量、現行已統計化地管理的數量、已經 穩定的統計的數量) • 已界定的差異的特別原因的數量 一般目標與一般執行方法 147 適用於服務的能力成熟度整合模式 1.2 版 • 在度量和分析環節中,當它與量化管理活動相關 的資料收集、分析和通報活動的時程 需求管理詳細說明 用在監控的度量和工作產品的範例如下: • 需求的善變性(需求改變的比例) • 協調需求的時程 • 分析一項提議的需求改變的時程 • 148 一般目標與一般執行方法 風險管理詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 用在監控的度量和工作產品的範例如下: • 界定、管理、追踪和管控的風險數量 • 風險曝露和改變到風險曝露為每一個已評估的風 險,及保留管理的總比例 • 風險降低計畫的改變活動(例如,流程、時程及 資金) • 未預期風險的發生 • 風險類別的善變性 • 預期的與實際的降低風險工作量和影響的比較 • 風險分析活動的時程 • 特定降低的行動的時程 供應商協議管理詳細說明 用在監控的度量和工作產品的範例如下: • 對供應商的需求的改變數量 • 按照供應商協議的成本與時程差異 • 已完成的供應商工作產品評估的數量(規劃的與 實際的對照) • 已完成的供應商流程評估的數量(規劃的與實際 的對照) • 選擇供應商和建立協議的時程 服務持續性詳細說明 用在監控的度量和工作產品的範例如下: • 已界定對服務交付的重要功能和資源的改變數量 • 確保服務持續所延伸的成本、時程和工作量 一般目標與一般執行方法 149 適用於服務的能力成熟度整合模式 1.2 版 • 在服務持續計畫已訓練過,但必須再訓練的比例 • 服務持續計畫驗證與確認問題報告狀態(也就是 每一個已公開的問題報告有多久) 服務交付詳細說明 用在監控的度量和工作產品的範例如下: • 準備服務協議所花費的時間 • 收到服務要求的數量 • 解決服務要求所花費的時間與在服務等級協議中 調適的次數的比較 • 在服務要求解決之前在支援團隊間的轉移數量 150 一般目標與一般執行方法 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展詳細說明 用在監控的度量和工作產品的範例如下: • 再工作所延伸的成本、時程和工作量 • 需求規格的偵測密度 • 發展一組需求的活動時程 • 在服務系統或服務系統組件設計中說明的需 求的比例 • 服務系統、服務系統組件、介面及文件的大 小和複雜度 • 設計與整合工作產品的偵測密度整合評估問 題報告趨勢(例如,寫下的數字、結案的數 字) • 過期的整合評估問題報告(也就是每一個已 公開的問題報告有多久) • 驗證與確認檔案(例如,已規劃的和已執行 的驗證與確認的數量、已發現的缺失數量) • 依照缺失類別已偵測到的缺失數量 • 驗證與確認問題報告趨勢(例如,寫下的數 字、結案的數字) • 驗證與確認問題報告狀態(也就是每一個已 公開的問題報告有多久) • 執行特定需求、設計、整合、驗證與確認活 動的時程 一般目標與一般執行方法 151 適用於服務的能力成熟度整合模式 1.2 版 服務系統移轉詳細說明 用在監控的度量和工作產品的範例如下: • 已規劃的與實際的轉換時間的對照 • 已收到的轉換相關的服務事故的數量 • 未預期的取消及返轉案例的數量,包括嚴重的破 壞服務系統交付 • 推展後檢視與關鍵人員調查的結果 策略服務管理 用在監控的度量和工作產品的範例如下: • 使用組織標準流服務套組的合約比例 • 違反調適的服務等級的客戶要求數量 • 使用特定服務的頻率 • 服務描述變更的發展時程 GP2.9 客觀評估遵循程度 依流程之說明、目標、標準及程序,客觀評估流程的 遵循程度,並解決不符合的情況。 此一般執行方法的目的,在於提供可信的保證,確保 流程依計畫執行,並遵循該流程的說明、標準及程 序。某種程度來說,是藉由評估流程的已選定工作產 品,來執行一般執行方法(有關「客觀評估」的定 義,請參見詞彙。 有關遵循程度的客觀評估,請參考流程與產品品質保 證流程領域,以獲得更多資訊。 152 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 基本上,非直接負責管理或執行流程活動的人員,可 進行遵循程度的評估。大部分的情況下,由下列人員 執行遵循度的評估:組織中非本流程或專案的人員或 非本組織的人員。因此即使在流程面對壓力(如進度落 後或預算超過)的情況下,亦可提供遵循程度的可信賴 保證。 容量與可用度管理詳細說明 已檢視活動的範例如下: • 決定缺失的原因 • 說明缺失的原因 原因分析與解決方案詳細說明 已檢視工作產品的範例如下: • 為執行選定的行動提案 • 原因分析與解決方案記錄 建構管理詳細說明 已檢視活動的範例如下: • 建立基準線 • 追踪與管控變更 • 建立與維護基準線的整合 已檢視工作產品的範例如下: • 基準線的檔案 • 變更需求的資料庫 一般目標與一般執行方法 153 適用於服務的能力成熟度整合模式 1.2 版 決策分析與解決方案詳細說明 已檢視活動的範例如下: • 評估使用已建立準則與方法的替代方案 已檢視工作產品的範例如下: • 何時採行正式的評估流程的指引 • 評估報告包括建議的解決方案 整合專案管理詳細說明 已檢視活動的範例如下: • 建立、維護及使用專案的已調適流程 • 與相關關鍵人員協調合作 已檢視工作產品的範例如下: • 專案的已調適流程 • 專案計畫 • 影響專案的其他計畫 • 工作環境標準 事故解決方案與預防詳細說明 已檢視活動的範例如下: • 建立達成事故解決方案與預防的方式 • 界定服務事故和記錄相關資訊 • 溝通服務事故的狀態 154 一般目標與一般執行方法 已檢視工作產品的範例如下: • 服務事故資料庫 • 解決方案 • 行動建議 • 服務事故記錄 關於適用於服務的能力成熟度整合模式 1.2 版 度量與分析詳細說明 已檢視活動的範例如下: • 連結度量與分析活動 • 提供度量結果 • 已檢視工作產品的範例如下: • 基礎和衍生度量的規格 • 資料收集與儲存程序 • 分析結果與草擬報告 組織創新與推展詳細說明 已檢視活動的範例如下: • 選擇改善 • 推展改善 一般目標與一般執行方法 155 適用於服務的能力成熟度整合模式 1.2 版 已檢視工作產品的範例如下: • 推展計畫 • 修改流程與技術改善的度量、目標、優先順序 和推展計畫 • 更新的訓練教材 組織流程定義詳細說明 已檢視活動的範例如下: • 建立組織流程資產 • 建立架構與形成整合團隊的規則和指引 已檢視工作產品的範例如下: • 組織的標準流程 • 生命週期模式的描述 • 組織的標準流程的調適指引 • 組織的度量資料 組織流程專注詳細說明 已檢視活動的範例如下: • 決定流程改善機會 • 規劃與協調流程改善機會 • 在專案起始時推展組織標準流程 已檢視工作產品的範例如下: • 流程改善計畫 • 流程行動計畫 • 流程推展計畫 156 一般目標與一般執行方法 • 組織流程評鑑計畫 關於適用於服務的能力成熟度整合模式 1.2 版 組織流程績效詳細說明 已檢視活動的範例如下: • 建立流程績效基準線與模式 已檢視工作產品的範例如下: • 流程績效計畫 • 組織品質與流程績效目標 • 流程績效的選定度量的定義 組織訓練詳細說明 已檢視活動的範例如下: • 界定訓練需求並提供訓練 • 提供必要的訓練 已檢視工作產品的範例如下: • 組織的訓練戰略計畫 • 訓練教材和支援文件 • 講師評估表格 專案監控詳細說明 已檢視活動的範例如下: • 監控專案績效是否符合專案計畫 • 管理矯正措施直到結案 一般目標與一般執行方法 157 適用於服務的能力成熟度整合模式 1.2 版 已檢視工作產品的範例如下: • 專案績效的記錄 • 專案檢視結果 專案規劃詳細說明 已檢視活動的範例如下: • 建立預測 • 發展專案計畫 • 取得對專案計畫的承諾 已檢視工作產品的範例如下: • 分工結構圖專案計畫 • 資料管理計畫 • 關鍵人員參與計畫 流程與產品品質保證詳細說明 有關一般執行方法 2.9 和流程和產品品質保證流程領域間 的關係,請參考一般目標和一般執行方法的表 6.2。 已檢視活動的範例如下: • 遵循評估流程和工作產品 • 追踪與溝通不相符的議題 已檢視工作產品的範例如下: • 不相符的報告 • 評估的記錄和報告 158 一般目標與一般執行方法 品質流程管理詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 已檢視活動的範例如下: • 量化地管理使用品質與流程績效目標的專案 • 統計地管理專案調適流程中選定的子流程 已檢視工作產品的範例如下: • 專案調適流程中包含的子流程 • 度量的操作定義 • 收集的度量 需求管理詳細說明 已檢視活動的範例如下: • 管理需求 • 界定專案計畫、工作產品和需求間的不相符 已檢視工作產品的範例如下: • 需求 • 需求追踪矩陣圖 風險管理詳細說明 已檢視活動的範例如下: • 建立與維護風險管理策略 • 界定與分析風險降低風險 已檢視工作產品的範例如下: • 風險管理策略 • 降低風險計畫 一般目標與一般執行方法 159 適用於服務的能力成熟度整合模式 1.2 版 供應商協議管理詳細說明 已檢視活動的範例如下: • 建立與維護供應商協議 • 滿足供應商協議 已檢視工作產品的範例如下: • 供應商協議管理計畫 • 供應商協議 服務持續性詳細說明 已檢視活動的範例如下: • 建立服務持續計畫 • 執行服務持續計畫中訓練 • 驗證與確認服務持續計畫 已檢視工作產品的範例如下: • 服務持續計畫 • 訓練教材 • 驗證與確認的方式、程序和準則 服務交付詳細說明 已檢視活動的範例如下: • 建立服務協議 • 進行服務要求 • 維護服務系統 160 一般目標與一般執行方法 已檢視工作產品的範例如下: • 服務協議 • 服務交付方式 關於適用於服務的能力成熟度整合模式 1.2 版 一般目標與一般執行方法 161 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 服務系統發展詳細說明 已檢視活動的範例如下: • 收集關鍵人員需求 • 需求規格的偵測密度 • 制訂與分析服務、服務系統及組件需求 • 選擇服務系統解決方案 • 發展服務系統與服務系統組件設計 • 確保介面的相容性 • 執行服務系統設計 • 整合與裝置服務系統組件 • 驗證與確認服務系統 • 執行同仁審查 已檢視工作產品的範例如下: • 服務、服務系統及組件需求 • 介面需求 • 服務系統架構 • 服務系統、服務系統組件與介面設計 • 設計與服務系統組件再使用的準則 • 技能規格與人員解決方案 • 執行的設計(例如,操作程序、製造的消耗品組 件) • 整合的服務系統組件評估 • 服務系統組件整合順序 • 整合程序與準則 162 一般目標與一般執行方法 • 驗證與確認程序與準則 關於適用於服務的能力成熟度整合模式 1.2 版 • 驗證與確認報告 • 同仁審查訓練教材 • 同仁審查資料 • 使用者、裝置、交付、事故管理和維護文件 服務系統移轉詳細說明 已檢視活動的範例如下: • 轉換規劃 • 轉換訓練 • 推展活動,包括確認和評估 已檢視工作產品的範例如下: • 服務系統移轉計畫 • 安裝記錄 • 推展後審查報告 策略服務管理 建立組織標準服務是一個被審查活動的範例。 已檢視工作產品的範例如下: • 組織標準服務 • 標準服務的描述 • 服務等級的描述 • 組織標準服務的調適指引 一般目標與一般執行方法 163 適用於服務的能力成熟度整合模式 1.2 版 GP2.10 與上層管理人員審查各狀況 與上層管理人員審查流程的活動、狀況及結果,並解 決問題。 此一般執行方法的目的,在於使上層管理人員對流程 的執行有適當的瞭解。 「上層管理人員(higher-level management)」包括高於直接 負責流程管理階層之所有階層的管理人員。特別注意 的是,上層管理者包含資深管理階層。本一般執行方 法所指之審查的管理人員,是指提供負責整體流程指 導的管理人員,而不是執行日常流程監控的管理人 員。 不同的管理人員對流程的資訊需求會有所不同。上述 的審查能確保在流程規劃與執行時,有充分的資訊以 進行決策。因此這類審查的進行時機,可以是定期 的,也可以在事件發生時才進行。 事故解決方案與預防詳細說明 上層管理人員保持對顯著的服務事故的瞭解,包括解 決方案與預防活動的結果。 組織流程專注詳細說明 這些審查通常是以簡短的格式由流程團隊和流程行動 團隊呈報給管理執行委員會。 164 一般目標與一般執行方法 組織流程專注詳細說明 關於適用於服務的能力成熟度整合模式 1.2 版 呈報主題的範例如下: • 由流程執行團隊已發展的改善的狀態 • 先導計畫的結果 • 推展的結果 • 達成顯著的里程碑的時程狀態(例如評鑑的整 備、達成目標組織成熟度等級或能力等級的進 度) 需求管理詳細說明 對承諾提議的改變將在組織外部達成,由高層管理人員審查以確保所有 的承諾能被完成。 風險管理詳細說明 由適當的管理階層以定期的或事件發生的基礎,審查專案風險狀態,以 提供潛在的專案風險曝露及適當的矯正措施的能見度。 服務持續性詳細說明 這些審查通常是以簡短的形式呈報給較高層管理人員。 呈報主題的範例如下: • 界定對服務交付重要的業務功能和資源的顯著改變 • 服務持續包括訓練活動的準備狀態 • 驗證與確認的議題和結果 服務系統移轉詳細說明 較高層管理人員應保持瞭解轉換狀態,包括成功的與不成功的轉換嘗試 和推展結果。 一般目標與一般執行方法 165 適用於服務的能力成熟度整合模式 1.2 版 GG3 制度化已調適流程 將流程制度化為已調適流程。 GP3.1 建立已調適流程 建立並維護已調適流程的說明。 此一般執行方法的目的,在於建立並維護流程的說 明。流程的說明,為滿足某種特定情況的需要,自組 織標準流程調適而來。組織應有一套涵蓋流程領域的 標準流程與調適指引,依據某專案或組織單位元的需 要調適該標準流程。有了已調適流程,會減少組織執 行流程的差異,而且更能有效率地分享流程資產、資 料及學習心得。 有關組織標準流程和調適指引,請參考組織流程定義 流程領域,以獲得更多資訊。 有關建立及維護專安的已調適流程,請參考整合專案 管理流程領域,以獲得更多資訊。 已調適流程的描述,提供流程規劃及流程執行的基 礎,也提供流程相關活動、工作產品及服務的管理基 礎。 細部執行方法 1. 自組織的標準流程,選擇最符合專案或組織功能需 要的流程。 2. 根據組織的調適指引,調適已選定的流程,以建立 已調適流程。 3. 確保已調適流程,已適當的說明組織的流程目標。 4. 記錄已調適流程和調適的紀錄。 5. 視需要修訂已調適流程的說明。 166 一般目標與一般執行方法 GP3.2 蒐集改善資訊 關於適用於服務的能力成熟度整合模式 1.2 版 蒐集由規劃和執行流程所衍生的工作產品、度量、度 量結果及改善資訊,以支援組織流程與流程資產的未 來使用與改善。 此一般執行方法的目的,在於蒐集進行規劃和執行流 程時的資訊和產品。經由執行本一般執行方法,相關 資訊和產品可存放於組織流程資產中,並可供正在(或 將要)規劃和執行相同或相似流程的人員使用。相關資 訊和產品存放於組織度量儲存庫和組織流程資產館 中。 相關資訊,包括各種活動所投入的工作量、某特殊活動所注入 或移除的缺失數,以及學習心得等。 有關組成工作產品、度量、度量資料結果,以及納入 組織度量儲存庫與與流程資產館的改善資訊,請參考 組織流程定義流程領域,以獲得更多資訊。 有關貢獻工作產品、度量、度量結果及文件化的經 驗,給組織流程資產,請參考整合專案管理流程領 域,以獲得更多資訊。 細部執行方法 1. 將流程和產品度量與度量結果存放到組織度量儲 存庫中。 流程和產品的度量資料,主要是組織標準流程所 定義的共用度量。 2. 提交相關文件,以納入組織流程資產館。 3. 記錄流程的學習心得,以納入組織流程資產館。 4. 提出組織流程資產的改善建議。 一般目標與一般執行方法 167 適用於服務的能力成熟度整合模式 1.2 版 GG4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP4.1 建立流程的量化目標 建立並維護流程的量化目標,該目標用來處理以客戶 需要與經營目標為基礎的品質與流程績效。 本執行方法的目的,在決定並自相關關鍵人員取得關 於流程特定量化目標的契約,這些量化目標能表達產 品品質、服務品質及流程績效。 有關如何建立專案已調適流程的子流程之量化目標, 請參考量化專案管理流程領域,以獲得更多資訊。 量化目標可能為特定流程而定,或者它們可能為較廣 的範圍而定義(例如:為一組流程),在往後的案例, 這些量化目標可能分配至某些被涵蓋的流程。 這些量化目標是用來判斷產品、服務與流程績效是否 滿足客戶、最終使用者、組織管理及流程執行者的準 則。這些量化目標超越傳統最終產品的目標,它們同 時包括用來管理持續達成目標的中間目標。它們部分 地反映組織標準流程的展示績效。當參與的流程或子 流程是穩定的,這些量化目標應設定可能達成並落入 常態範圍目標範圍內的數值。 細部執行方法 1. 建立流程有關的量化目標。 2. 分配量化目標至流程或其子流程。 GP4.2 穩定子流程績效 穩定一個或多個子流程的績效,以決定流程的能力, 是否達成已建立之量化品質與流程績效目標。 本一般行方法的目的是穩定一個或多個已調適(能力度 第三級)流程的子流程之績效,該流程使用適當的統計 168 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 和其他量化的技術,並對整體績效有重要貢獻。穩定 已選定子流程來支援流程的預測能力,以達成已建立 的量化品質與流程改善目標。 有關選擇統計管理的子流程、監控子流程的績效,以 及穩定子流程績效的其他觀點,請參考量化專案管理 流程領域,以獲得更多資訊。 穩定的子流程不是流程變異中特殊原因的重要指標, 在子流程的常態範圍所建立的限制下,穩定的子流程 是可預測的。穩定的子流程的變異,因共同原因系統 而改變。 預測流程的能力以達成已建立的量化目標,需要量化 瞭解子流程的貢獻,這對達成這些目標,以及持續建 立和管理過渡的量化目標是重要的。 納入已選定流程與產品度量及度量資料結果於組織度 量儲存庫,以支援流程績效分析與未來以事實為基礎 的決策。 細部執行方法 1. 統計管理一個或多個子流程績效,對整體流程績 效有重要貢獻。 2. 預測流程的能力以達成已建立的量化目標,考慮 統計管理子流程績效。 3. 將已選定的流程績效度量結果,納入組織流程績 效基準。 GG5 制度化最佳化流程 將流程制度化為最佳化流程。 GP5.1 確保持續的流程改善 確保流程的持續改善,以實現相關的組織經營目標。 一般目標與一般執行方法 169 適用於服務的能力成熟度整合模式 1.2 版 此一般執行方法的目的,在於選擇與系統化推展流程 與技術改善項目,以促成符合所建立的品質和流程改 善目標。 有關選定及佈置漸進及創新的改善方法,以可度量式 地改善組織流程及科技,請參考組織創新及佈置流程 領域,以獲得更多資訊。 靈活和創新的最佳化流程,有賴於被充分授權之工作 團隊的參與,並且配合組織的經營價值與目標。可藉 由加速學習和分享學習的方法,加強組織對改變和機 會的快速反應能力。流程改善是每個人的責任,它也 會導致持續改善的循環。 細部執行方法 1. 建立與維護量化流程改善目標,以支援組織的經 營目標。 量化流程改善目標可能是個別流程的特定目標, 或為較廣的範圍而定義(例如:一組流程),而個別 流程對達成這些目標做出貢獻。個別流程的特定 目標通常由為較廣範圍所建立的量化目標配置而 來。 這些流程改善目標,主要由組織的經營目標和流 程能力的詳細瞭解衍生而來,這些目標是用來判 斷流程績效是否量化改善組織能力,以滿足經營 目標的準則。這些流程改善目標時常設定高於目 前流程績效的數值,並且可能需要漸進與創新的 技術改善,以達成這些目標。這些目標也可能經 常修訂,以持續驅動流程改善(例如:當達成目 標,可能設定再高於新流程績效的新數值)。 這些流程改善目標,可能與「建立流程的量化目 標」一般執行方法的目標相同或更精確。只要它 們可以作為成功流程改善的驅動與準則。 170 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 2. 界定流程改善項目,這些改善項目對流程績效可 能會產生可度量的改善。 流程改善包括漸進的改變與創新的技術改善,通 常追求創新的技術改善,是藉由個別規劃、執行 與管理的工作努力來達成,也常常執行試行。這 些工作努力通常把流程因素當作目標,流程績效 分析已是重要度量改善的關鍵。 3. 以量化的預期效益、估計成本與影響,以及流程 績效度量的改變為基礎,定義策略並管理已選定 流程改善項目的推展。 量化估計這些改善項目的成本與效益,並度量實 際的成本與效益。相對於組織量化的流程改善目 標,效益是主要的考量。同時對組織標準流程與 已調適流程進行改善。 管理流程改善的推展,包括變更的試行與適當的 進行實施的調整、處理潛在與實際的推展障礙、 減低對不斷努力的瓦解,以及管理風險。 GP5.2 矯正問題的根本原因 界定並矯正流程之缺失與其他問題的根本原因。 此一般執行方法的目的,在於分析在量化管理流程 中,所造成缺失和其他問題的原因,矯正此類缺失與 問題的根本原因,並避免缺失及問題未來再度發生。 有關界定並矯正所選缺失的根本原因,請參考原因分 析與解決方案流程領域,以獲得更多資訊。雖然原因 分析與解決方案流程領域有專案背景,其亦可應用於 其他背景的流程。 非量化管理的流程可有效益地應用根本原因分析,雖 然可能在流程外發現最終根本原因,一般執行方法仍 著重在量化管理流程。 一般目標與一般執行方法 171 適用於服務的能力成熟度整合模式 1.2 版 應用一般執行方法 本節幫助你更瞭解一般執行方法,及提供資訊,以幫 助你詮釋及應用一般執行方法到你的組織。 一般執行方法是應用於所有流程領域的模型元件,把 一般執行方法想成是提醒,目的在於提醒你把事情做 對,並且是期望性的模型元件。 舉例來說,當達成專案規劃流程領域的一般執行方法 時,同時你也在建立及維護定義專案活動的計畫。應 用一般執行方法到專案規劃流程領域,是在建立及維 護計畫,以執行流程(GP2.2)。當應用一般執行方法到 本流程領域,是在提醒你去規劃與建立專案計畫相關 的活動。 當你滿足組織訓練流程領域的特定目標時,也就是在 發展專案及組織人員的技巧及知識,以致於能更有效 果及有效率地執行他們的角色。當應用同樣的一般執 行方法(GP2.2)到組織訓練流程領域,特定執行方法能 提醒你去規劃,與發展組織人員技巧及知識相關的活 動。 支援特定執行方法的流程領域 一般目標及一般執行方法是模型元件,用以直接陳述 跨組織的流程制度化,很多流程領域同樣地陳述支援 一般執行方法實施的制度化過程。瞭解這些關係,將 有助於效率地執行一般執行方法。 這些流程領域包含一個或多個特定執行方法,實施 時,可能完全執行一個特定執行方法,或者是產生用 於執行特定執行方法的工作產品。 舉建構管理流程領域及”GP2.6 在適當控制層級中,選 定流程的指定工作產品”的例子來說。為執行一個或 172 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 多個流程領域的一般執行方法,你可能選擇執行建構 管理流程領域,全部或部分地執行特定執行方法。 另一個是組織流程定義流程領域及”GP3.1 建立及維護 已調適流程敘述”的例子。為執行一個或多個流程領 域的一般執行方法,應該先執行組織流程定義流程領 域,全部或部分地建立組織流程資產,用以執行特定 執行方法。 表 6.2 描述(1)支援執行特定執行方法的流程領域,及 (2)特定執行方法及其緊密相關流程領域間的遞迴關 係。流程改善利用存在於特定執行方法及其相關的流 程領域間自然的合作方式,這兩種關係的種類要牢 記。 表 6.2 特定執行方法及流程領域關係 特定執行方法 在特定執行方法的實施上,流程領 執行方法如何遞迴地應用於其相關 域的角色 的流程領域 GP2.2 規劃流 程 專案規劃:對所有與專案相關的流 GP2.2 應用於專案規劃流程是”規 程領域(除專案規劃本身外),專 劃計畫”的特點,並包含規劃專案 案規劃流程可以完全實行 GP2.2。 的規劃活動 GP2.3 提供資 源 GP2.4 指派責 任 專案規劃:在專案規劃流程中,有 關實行專案規劃 SP2.4”規劃專案 的資源”,對於所有與專案相關的 流程領域(也許除最初的專案規劃 本身外),支援 GP2.3 及 GP2.4 的 實行,並藉由界定所需的專案資 源,以確保專案所需的適當任職、 機構、設備,以及其他資產,是安 全的。 一般目標與一般執行方法 173 適用於服務的能力成熟度整合模式 1.2 版 特定執行方法 在特定執行方法的實施上,流程領 執行方法如何遞迴地應用於其相關 域的角色 的流程領域 GP 2.5 Train People GP2.5 人員訓 練 組織訓練:組織訓練流程支援 GP2.5 的實行,可藉由訓練策略或 組織全面的訓練需求,給將執行或 支援流程的人員,以應用到所有流 程領域。 GP2.5 應用於組織訓練流程,包含 執行組織訓練活動的訓練,其陳述 了管理、創造及完成訓練所需要的 技巧。 專案規劃:專案規劃流程中,有關 實行專案規劃 SP2.5” 規劃專案所 需的知識及技巧”,以及組織訓練 流程,對於所有專案相關的流程領 域,支援 SP2.5 的完整實行。 GP2.6 建構管 理 建構管理:對於所有專案相關的流 GP2.6 應用於建構管理流程,包含 程領域,以及部分組織流程領域, 了建構管理產生之工作產品的變更 建構管理流程可完整實行 GP2.6。 及版本控制。 GP2.7 界定及 涉及相關關鍵 人員 專案規劃:專案規劃流程中,有關 實行專案規劃 SP2.6” 關鍵人員參 與計畫”,對於所有專案相關的流 程領域,同樣可完整實行 GP2.7 的 關鍵人員部分(前二個細部執行方 法)。 專案監控:專案監控流程中,有關 實行專案專案監控 SP1.5”監督關 鍵人員參與”, 對於所有專案相關 的流程領域,可支援實行 GP2.7 第 三個細部執行方法。 GP2.7 應用於專案規劃流程,包含 了專案規劃活動中,相關關鍵人員 的參與。 GP2.7 應用於專案監控流程,包含 相關關鍵人員在專案監控活動的參 與。 GP 2.7 應用於整合專案管理流程 GP2.7,包含了相關關鍵人員在整 合專案管理活動的參與。 整合專案管理:整合專案管理流程 中,有關實行整合專案管理 SP2.1”管理關鍵人員參與”,對於 所有專案相關的流程領域,可支援 實行 GP2.7 第三個細部執行方法。 174 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 特定執行方法 在特定執行方法的實施上,流程領 執行方法如何遞迴地應用於其相關 域的角色 的流程領域 GP2.8 監控流 程 專案監控管理:對於所有專案相關 GP2.8 應用於專案監控流程,包含 的流程領域,專案監控管理流程可 監控專案的監控活動。 完整實行 GP2.8。 度量與分析:對所有流程,而不只 是專案相關流程來說,度量與分析 流程領域提供有關度量、分析與記 錄資訊的一般指引,可用於建立度 量,來監督流程的實際績效。 GP2.9 目標評 估遵循 流程與產品品質保證:對於所有流 程領域(也許除了流程與產品品質 保證本身),流程與產品品質保證 流程可完整實行 GP2.9。 GP2.9 應用於流程與產品品質保證 流程,包含品質保證活動的目標評 估。 GP2.10 與更高 管理階級審查 狀態 專案監控管理:在專案監控流程 中,有關實行專案監控 SP1.6”進 行進度審查”及 SP1.7”進行里程碑 審查”,對於所有專案相關流程領 域,支援 GP2.10 的實行,其完整 度端視這些審查的較高管理階級而 定。 GP3.1 建立已 調適流程 整合專案管理:整合專案管理流程 中,有關實行整合專案管理 SP1.1”建立專案已調適流程”,對 於所有專案相關的流程領域,可完 整實行 GP3.1。 GP3.1 應用於整合專案管理流程, 包含為了整合專案管理活動,而建 立已調適流程。 組織流程定義:對所有流程,而不 只是專案相關流程來說,組織流程 定義流程建立實行 GP3.1 所需的組 織流程資產。 一般目標與一般執行方法 175 適用於服務的能力成熟度整合模式 1.2 版 特定執行方法 在特定執行方法的實施上,流程領 執行方法如何遞迴地應用於其相關 域的角色 的流程領域 GP3.2 收集改 善資訊 整合專案管理:在整合專案管理流 程中,有關實行專案管理 SP1.7” 提供組織流程資產”,對於所有專 案相關的流程領域,可完整實行 GP3.2。 GP3.2 應用於整合專案管理流程, 包含收集從規劃及執行整合專案管 理活動中,所取得的改善資訊。 組織流程專注:在組織流程專注流 程中,有關實行組織流程專注 SP3.4” 將經驗納入組織流程資產 中”, 對於所有流程領域,可部分 或完整實行 GP3.2。 組織流程定義:對所有流程,組織 流程已調適流程建立實行 GP3.2 所 需的組織流程資產。 GP4.1 建立流 程的量化目標 量化專案管理:量化專案管理流程 中,有關實行量化專案管理 SP1.1”建立專案的目標”,對於所 有專案相關流程領域,從各特定流 程取得的目標,可支援 GP4.1 的實 行。如果這些目標為量化專案管理 SP1.1 細部執行方法 5 及 8 的一部 分,則量化專案管理流程完整地實 行 GP4.1。 GP4.1 應用於量化專案管理流程, 包含建立量化專案管理活動的量化 目標。 GP4.1 應用於組織流程績效,包含 建立組織流程績效活動的量化目 標。 組織流程績效:在組織流程績效流 程中,有關組織流程績效 SP1.3” 建立品質與流程績效的目標”,對 於所有流程領域,支援 GP4.1 的實 行。 176 一般目標與一般執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 特定執行方法 在特定執行方法的實施上,流程領 執行方法如何遞迴地應用於其相關 域的角色 的流程領域 GP4.2 穩定細 部流程績效 量化專案管理:量化專案管理流程 中,有關實行量化專案管理 GP2” 統計管理細部流程績效”,對於所 有專案相關流程領域,以及相對應 的統計管理細部流程,可支援 GP4.2 的完整實行。 GP4.2 應用於量化專案管理流程, 包含在量化專案管理活動中,已選 定細部流程的穩定性。 組織流程績效:對所有流程,而不 只是專案相關流程來說,組織流程 績效流程建立實行 GP4.2 所需的組 織流程資產。 GP5.1 確保持 續流程改善 組織創新推展:組織創新推展流 程,對於所有流程領域,可完整實 行 GP5.1,提供品質及流程績效目 標給已調適的組織。(如果已實行 組織流程績效流程領域,就如同是 後者)。 GP5.1 應用於組織創新推展流程, 包含在組織創新及推展活動中,確 保持續流程改善。 GP5.2 矯正問 題的根本原因 原因分析及解決方案:對於所有專 案相關的流程領域,原因分析及解 決方案流程可完整實行 GP5.2。 GP5.2 應用於原因分析及解決方案 流程,包含在原因分析及解決方案 活動中,界定缺失的根本原因及其 他問題。 這些流程領域通常較早以完整或部分來實行,提早或 同時與相關的一般執行方法共同執行,以提供一般執 行方法在這些流程領域的相依性,以及很多流程領域 所呈現更多完整的觀點。 應用一般執行方法到特定的流程領域,似乎是多餘 的,但事實上,並非如此。這樣來想也許是正常的, 應用 GP3.1”建立已調適流程”,到專案規劃及專案監 一般目標與一般執行方法 177 適用於服務的能力成熟度整合模式 1.2 版 控流程領域,效果如同整合專案管理的第一個特定執 行方法。“使用組織的已調適流程”。 雖然有些部分是重疊,一般執行方法應用於這兩個流 程領域中,提供已定義流程涵蓋了專案規劃及專案監 控活動。已調適流程無需涵蓋支援活動(如建構管 理)、其他專案管理流程(如整合專案管理),或採 購流程。相反地,整合專案管理流程領域的專案已調 適流程,涵蓋了所有適當的專案管理、工程,和支援 流程。 178 一般目標與一般執行方法 容量與可用度管理 成熟度等級 3 的專案管理流程領域 關於適用於服務的能力成熟度整合模式 1.2 版 目的 簡介 容量與可用度管理(CAM) 的目的是確保有效的服務系 統績效與確保有效地提供及使用資源,以支援服務需 求。 容量與可用度管理流程領域包含在合理的成本及資源 有效的使用情形下,建立與維護能力與可用度。容量 與可用度管理活動可以在組織內不同的層級執行,包 括跨越不同的服務。 容量與可用度管理流程領域包括下列活動: • 建立與維護容量與可用度管理策略 • 適當地提供與配置資源 • 監督、分析、瞭解與報告現今及未來對服務、資 源使用、能力、服務系統績效及服務可用度的需 求 • 當平衡成本與所需資源,以及供給與需求時,決 定矯正行動,以確保適當的能力與可用度 容量與可用度管理 「能力」表示一件事可以支援、保持、處理或製造另 一件事的程度。在服務內容中,能力可以參考為服務 系統可以在一段固定時間內成功地處理之服務交付的 最大量或服務請求的最多次數。能力的定義與度量可 以由於不同型態的服務與服務系統而有所不同,也可 以定義在服務協議中。此外,能力的定義與度量可以 179 適用於服務的能力成熟度整合模式 1.2 版 從服務協議中產生,而不是從中反應出來。如果服務 協議沒有明確的能力需求,仍可以對服務或服務系統 隱含衍生出能力需求。對某些服務,能力可能是服務 系統組件的最大尺寸、容量或生產量。 能力的例子如下: ●在 24 小時內可以收到維護通知需要維護交通工具的 數量 ●在 8 小時內可以處理貸款申請表格的數量 ●磁碟機的大小或容量 ●每個小時可以打掃的地板平方英呎數量 ●裝貨機一次可裝載的磅數 ●服務系統組件可以吸收液體的總量 ●客服中心每天可以處理的電話數量 ●每年可以執行的評鑑數量 作為建立容量與可用度管理策略的部份,決定下列事 項: • 適合管理的資源 • 影響服務可用度及應度量、監督、分析及管理的 服務系統層面 包括人員、硬體、電力及可用空間的資源的例子。 「可用度」表示一樣東西當需要時可以取得與能用的 程度。在服務內容中,可用度可以參考為一組時間、 場地,或其他環境包含服務交付、需執行的服務請求 或服務協議有效的其他面向。不同的專案對不同型態 180 容量與可用度管理 關於適用於服務的能力成熟度整合模式 1.2 版 的服務與服務系統及可用度的不同觀點,可以有不同 的可用度的定義與度量。(可用度的不同觀點,例 如,經營觀點、最終使用者觀點、客戶觀點、服務提 供者觀點)可用度的定義需要瞭解服務系統組件如何 支援對可用度的服務需求,此點可能在服務協議中定 義。此外,可用度需求與度量值可以倚賴及影響其他 密切相關的需求,例如維護度、信賴度、持續性與安 全性。 服務系統組件可用度的可能考量,舉例如下: • 麻醉設備 • 餐廳員工 • 維護的供給 • 交通的組件(例如,計程車、公車、貨車、司 機) • 客服中心員工 • 主評鑑員 可用度是最終使用者與客戶眼中對服務品質最明顯的 指標之一。對某些服務,瞭解信賴度、維護度及可用 度等之間的關係,對管理可用度而言是重要的。 容量與可用度管理 181 適用於服務的能力成熟度整合模式 1.2 版 服務的可用度可以依賴下列事項: • 服務系統組件的可用度 • 服務系統失效的回復能力 • 服務系統執行的維護品質 • 提供於服務系統的支援品質 • 服務流程的有效性 • 安全的執行方法 「能力管理」著重在如何提供最好的資源以符合服務 需求。「可用度管理」著重在交付可用度的維持等級 以符合服務需求。然而,在高等級,很多能力管理與 可用度管理的執行方法極為類似,而合併在一起,變 成緊密的配對。能力管理提供達到維持的可用度的方 法,以符合服務需求(對某些服務,它也提供備用的 能力與恢復能力)。 服務的同步製造與消耗是服務獨特的特色之一。這個 特色展現某些管理服務的能力與可用度的挑戰。如 果,提供給服務的能力與可用度當要求發生時並沒有 發生,客戶必須等待,造成一種或其他成本(例如, 較低的客戶滿意、當客戶放棄等待時,失去業務、財 務懲罰)。當預期的需求沒有發生時(例如,員工的 薪資成本閒置、過量能力的購買成本),成本可能也 伴隨過量的能力。 能力管理的挑戰,舉例如下: • 提供足夠與正確的旅館房型以符合要求,並沒 有重複訂房或空房 • 在機場為眾多的旅行者提供足夠的行李搬運 機,而沒有超量或閒置的行李搬運機 182 容量與可用度管理 關於適用於服務的能力成熟度整合模式 1.2 版 可用度管理的挑戰,舉例如下: • 確保交付景觀服務、維護景觀設備、景觀人員 能休假(例如,假日、年休假),如同在相關 協議的定義。 • 監督景觀設備與人員的信賴度(例如,景觀人 員的缺席率) • 當服務可用度降低到服務協議的水準以下時, 決定矯正行動。 容量與可用度管理包括建立服務系統的表現方式及使 用這些表現方式執行下列事項: • 支援適當的服務協議的協商 • 規劃 • 決策 • 考量矯正行動 • 提供及分配資源以符合現在及未來的服務需求 「服務系統表現方式」例如模式、模擬、圖表、地圖 及雛型,提供服務系統如何運作特定的工作量與差異 的行為。這些表現方式可能以資料表、市面現有 (COTS)工具(例如模擬套裝)、或內部發展的工具建 立。對某些服務,表現方式可能是歷史的基準、趨勢 分析、分析的模式、等待時間的分析、模擬模式、統 計模式(例如,回歸模式或時間順序模式)、原因模 式(例如,可能性的網路)、或應用規模。 容量與可用度管理的範圍可能是一個服務系統或數個 服務系統。如果服務提供者操作數個服務系統,容量 與可用度管理流程可能在分別的服務系統獨立地執 行,但組織可能需瞭解減少的價值。 容量與可用度管理 183 適用於服務的能力成熟度整合模式 1.2 版 相關流程領域 有關界定、控制與解決事故,請參考事故解決方案與 預防流程領域,以獲得更多的資訊。 有關建立與維護計畫以確保在正式運作中任何明顯地 中斷時服務的持續性,請參考服務持續性流程領域, 以獲得更多的資訊。 有關維護服務系統,請參考服務交付流程領域,以獲 得更多的資訊。 有關為標準服務建立策略需要與計畫,請參考策略服 務管理流程領域,以獲得更多的資訊。 有關說明度量值,請參考度量與分析流程領域,以獲 得更多的資訊。 有關建立專案策略與發展專案計畫,請參考專案規劃 流程領域,以獲得更多的資訊。 特定目標與執行方法摘要 SG1 準備容量與可用度管理 SP 1.1 建立容量與可用度管理策略 SP 1.2 選擇度量值與分析技術 SP 1.3 建立服務系統表現方式 SG 2 監督與分析能力與可用度 SP 2.1 監督與分析能力 SP 2.2 監督與分析可用度 SP 2.3 報告容量與可用度管理資料 184 容量與可用度管理 依照目標的特定執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 SG1 準備容量與可用度管理 執行準備容量與可用度管理。 準備容量與可用度管理包括下列活動: • 建立與維護管理能力與可用度的策略以符合服務 需求 • 選擇度量值與分析技術以支援可用度與能力管理 目標 • 建立與維護服務系統表現方式以瞭解現行能力、 可用度及服務系統績效(也就是描述什麼是正 常的能力、可用度及服務等級) 建立與維護門檻以定義服務系統的例外情形、認可對 服務需求的違反或幾乎違反,以及界定服務事故。除 了瞭解現行服務系統的能力與可用度外,依據服務資 源使用、服務系統績效及期望的服務需求的趨勢,估 計能力、可用度及服務等級。 SP 1.1 建立容量與可用度管理策略 建立與維護容量與可用度管理的策略。 容量與可用度管理策略是基於服務需求、失效與變更 需要趨勢分析、現今資源使用與服務系統績效。服務 系統表現方式可以幫助發展容量與可用度管理的策 略。策略可解決在短、中、長服務期間,最小、最大 及平均的服務(也就是服務資源)使用。 對某些服務它可適合界定、規劃與管理激增能力的可 用度或取得資源,以回應突然的、無預期的增加要 容量與可用度管理 185 適用於服務的能力成熟度整合模式 1.2 版 求。對某些服務型態,容量與可用度管理的策略是管 理某些廢棄的資源及服務因素。 服務系統設計文件可以幫助決定服務系統要度量、監 督、分析與管理的資源與層面。然而,設計文件可能 不提供或可能無法正確地與充份地反應現行服務環境 中可能會影響能力與可用度的各個層面。因此,監督 與分析實際能力與可用度資料是重要的。每日服務交 付與監督的服務策略資訊及現有服務協議的需求資訊 可以協助這些決定。 有關建立服務協議,請參考服務交付流程領域,以獲 得更多的資訊。 有關準備服務系統移轉,請參考服務系統移轉流程領 域,以獲得更多的資訊。 有關建立標準服務,請參考策略服務管理流程領域, 以獲得更多的資訊。 容量與可用度管理策略可以反應一些因素例如由於客 戶資金有限的限制及客戶接受某些能力與可用度相關 的風險。 服務提供者可能無法影響或控制需求與資源調整,但 仍被要求訂出最能符合服務需求的策略。如果服務提 供者可以影響或控制需求與資源調整,策略可能比服 務提供者無法影響或控制更精密。 典型的工作產品 1. 容量與可用度管理策略 細部執行方法 1. 記錄資源及服務使用、績效與可用度。 2. 預測未來資源與服務的能力與可用度需求 186 容量與可用度管理 關於適用於服務的能力成熟度整合模式 1.2 版 3. 發展能力策略,使符合服務需求、符合資源與服 務要求及解決如何提供、使用與分配資源。 4. 發展可用度策略,使符合服務需求與解決交付可 用度的維持等級。 對某些服務可能適合在策略中包含可用度測試時 程、服務系統維護策略與計畫的服務中斷。 有關準備服務持續性,請參考服務持續性流程領 域,以獲得更多的資訊。 有關維護服務系統,請參考服務交付流程領域, 以獲得更多的資訊。 有關準備服務系統移轉,請參考服務系統移轉流 程領域,以獲得更多的資訊。 5. 記錄策略的金錢成本與好處,以及任何假設。 6. 定期地修改策略。 如有需要以事件為導向的基礎修改策略。 SP 1.2 選擇度量值與分析技術 選擇將使用於管理服務系統的能力與可用度的度量值 與分析的技術。 為管理能力與可用度的特定度量值,可能需要收集經 營資料、財務資料、服務資料、技術資料、服務資源 使用資料、績效資料、以及其他服務系統的能力與可 用度的資料。度量目標與為能力與可用度選擇的度量 值與分析技術,大大地受服務協議與服務系統特定的 特性所影響。 選擇度量值的考量也包括將支援的活動、報告的需求 與將如何使用資訊。供應商協議應該適當地反應或支 援選擇的度量值與分析技術。 容量與可用度管理 187 適用於服務的能力成熟度整合模式 1.2 版 有關建立服務協議,請參考服務交付流程領域,以獲 得更多的資訊。 有關指派度量與與分析活動,請參考度量與與分析流 程領域,以獲得更多的資訊。 有關建立供應商協議,請參考供應商協議管理流程領 域,以獲得更多的資訊。 可用度的度量值,舉例如下: • 同意的時數內可用的百分比(這個可用度可能 是整個服務的可用度或服務組件的可用度) • 同意的時數內不可用的百分比(這個不可用度 可能是整個服務的不可用度或服務組件的不可 用度) • 基於失效的當機的時間(通常是分數、時數或 每週的時數) • 失效的頻率 • 衝擊的範圍(例如,影響使用者的數目、使用 者損失生產力的分數、沒有處理或完成的交易 或重要業務功能、妨礙的應用服務的數量) • 服務系統對服務事故的回應時間、交易的回應 時間、以及服務的回應時間(這個回應時間可 能是能力的度量值或可用度的度量值) • 信賴度(例如,服務中斷的次數、失效間的平 均時間、服務事故間的平均時間) 188 容量與可用度管理 能力的度量值,舉例如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 受限制的服務資源的使用 • 服務組件的使用 • 不使用受限制的服務資源 • 不使用服務組件 • 生產量(例如同時間的使用者數量、將處理的 交易數量) • 排隊的長度(最大與平均) • 在選定的時間量內使用特別型態資源的數量或 一個或多個特定資源的數量(這個使用可以日 曆時間監督) 典型的工作產品 1. 能力與可用度度量值的操作定義。 2. 追踪到服務需求的能力與可用度度量值 3. 支援收集與分析能力與可用度資料的工具 4. 選定的度量屬性符合目標度量值或範圍。 細部執行方法 1. 從支援容量與可用度管理目標的組織流程資產, 界定度量值。 2. 界定與特別說明額外的度量值,這度量值需要支 援達成服務的容量與可用度管理目標。 3. 分析界定的度量值與服務需求間的關係,並衍生 出描述特定目標度量值或範圍以符合每一個度量 屬性的目標。 容量與可用度管理 189 適用於服務的能力成熟度整合模式 1.2 版 這個分析提供對標準服務與服務等級的描述的輸 入資料。 有關建立標準服務,請參考策略服務管理流程領 域,以獲得更多的資訊。 SP 1.3 建立服務系統表現方式 建立與維護服務系統表現方式以支援容量與可用度管 理。 服務系統表現方式提供服務系統將如何運作特定的工 作量與差異性的重要意見。這些重要意見用來支援有 關資源分配、服務系統變更、服務協議與其他服務管 理與交付的面向的決策。 對很多服務,需求的波動很廣泛。對廣泛地變動要求 的管理服務是服務獨特的挑戰之一。依照變動的型 態,表現方式可以著重在短期或中期的時間間隔(例 如,依照一天中工作交接時程的小時,一星期中的幾 天,一年中的幾個月)或較長的時間間隔(例如,一 年的幾季、一年二次,或一年一次) 使用收集的能力與可用度資料、預測的服務需求及服 務系統表現方式制定服務資源使用的預測成長。 服務系統的度量目標與特定的性質決定服務系統表現 方式的本質與範圍。(服務協議對度量目標有重要的 影響力)經驗、歷史資料、模組專業與現今資源的使 用也可以影響服務系統表現方式的本質。 有關建立度量目標與說明分析程序,請參考度量與分 析流程領域,以獲得更多的資訊。 表現方式可能被用來分析可能影響可用度與能力的需 求變更的影響。表現方式也可以用來說明可以達成的 190 容量與可用度管理 關於適用於服務的能力成熟度整合模式 1.2 版 未來要求的範圍以及服務系統所需的服務等級的衝 擊。在未來行為的表現方式或服務系統績效建立之 前,必須先建立對服務資源正常使用與服務系統績效 的描述。 支援容量與可用度管理的服務系統表現方式,舉 例如下: • 圖表式的表現方式顯示出一個在醫院綜合二種 型態的保健提供者資源,有特定的限制與參數 指出2種資源可能最好的配置。 • 對銀行提款機的等候線的分析。 • 交通工具排程計畫。 • 交易抵達率與特定資源建構的模擬模組(例 如,銀行提款機,網路伺服器)。 • 服務系統組件的可用度、信賴度與維護度的趉 勢分析。 • 服務系統組件失效的衝擊分析。 • 負載測試以產出對服務系統資源的期望要求與 確保服務系統組件可以根據服務協議執行。 • 錯誤樹狀分析與單點失效分析。 可以建立服務系統表現方式提供輸入資料,以支援發 展服務協議及描述標準服務與服務等級。 有關建立服務協議,請參考服務交付流程領域,以獲 得更多的資訊。 有關建立標準服務,請參考策略服務管理流程領域, 以獲得更多的資訊。. 服務系統表現方式可能在設計服務系統時建立。然 而,就算在設計與發展服務系統時小心翼翼以確保其 能在大範圍的運作情形下,符合服務需求,服務管理 容量與可用度管理 191 適用於服務的能力成熟度整合模式 1.2 版 與交付仍必須維持在轉換與運作時服務系統績效與品 質的要求等級。 服務系統發展補充資料 有關發展服務系統,請參考服務系統發展流程領域, 以獲得更多的資訊。 在整個服務生命週期中要維護服務系統表現方式。 服務系統表現方式一般都不是與流程績效基準以及建 立在第 4 級與第5級組織流程績效的模式相同。有幾 件事區分表現方式與流程績效基準與模式的不同: • 組織流程績效﹙OPP﹚的流程績效模式與基準需 要使用統計的技術、需要界定與解決差異性的 特殊原因、需要流程穩定與可預測(也就是統 計管理)。服務系統表現方式不需要有這些屬 性。 • 建立在容量與可用度管理﹙CAM﹚的表現方 式,不需以從使用組織的標準流程收集來的資 料為基礎。 • 組織流程績效﹙OPP﹚的重點是流程績效基準與 模式。除了流程資料之外,容量與可用度管理 ﹙CAM﹚的服務系統表現方式重點包括非流 程資料、人員與服務系統的其他部份,例如基 礎建設與自動化系統。 • 建立服務系統表現方式以特別地支援能力與可 用度分析。這個範圍比組織流程績效﹙OPP﹚執 行方法的範圍較窄。 參見詞彙中「統計管理流程」的定義。 有關建立績效基準與模式,請參考組織流程績效流程 領域,以獲得更多的資訊。 192 容量與可用度管理 關於適用於服務的能力成熟度整合模式 1.2 版 雖然對容量與可用度管理不需要,表現方式提供機會 使用統計的技術,例如統計的流程控制。這些技術可 以量化地管理服務系統績效與品質,以及改善服務系 統能力。 有關採用統計方式以瞭解差異性,請參考量化專案管 理流程領域,以獲得更多的資訊。 典型的工作產品 1. 資源與服務使用的表現方式 2. 服務等級的表現方式 3. 資源與服務使用的資料 4. 現行交付的服務等級資料 5. 定義例外情形與違反的門檻 細部執行方法 1. 收集資源與服務的使用及現行交付的服務等級的 度量。 2. 建立與維護正常使用服務資源與服務系統績效的描 述。 對某些服務而言,在決定服務系統現行的能力也 可能需要決定服務系統組件能力之前,建立一般 系統的流程圖以界定服務系統及其流程是明智 的。 3. 從收集的度量與分析中,建立與維護服務系統表現 方式。 對某些服務而言,預測服務系統在尖峰工作量的 能力是明智的。 容量與可用度管理 193 適用於服務的能力成熟度整合模式 1.2 版 4. 與關鍵人員審查及取得同意有關正常使用服務資 源、服務系統績效及服務系統表現方式的描述。 5. 使正常使用服務資源、服務系統績效及服務系統 表現方式的描述可取得。 6. 建立與維護伴隨需求、工作量、服務資源使用及 服務系統績效的門檻,以定義在服務系統中的例 外情形及服務需求的違反或接近違反。 門檻一般是設低於例外情形或違反服務需求的等 級。發生時允許矯正行動以預防違反服務需求、 過份使用資源或不良服務系統績效。 SG2 監督與分析能力與可用度 監督與分析能力與可用度以管理資源與需求。 分析符合服務需求的每一個服務系統組件的貢獻,以 成功地管理服務能力與可用度。依據容量與可用度管 理策略,管理資源的有效使用,策略是為符合服務需 求而發展。對服務組織而言,它不可能影響對服務的 要求,如此的作為是不隱含在「管理資源與要求」」 這句話裏。資源的有效使用可以包含反應與主動的回 應。主動的回應在服務提供者能影響要求的情形下, 是有可能的。 定期地監督實際的能力與可用度資料。這實際資料也 定期地與門檻、一般與預期使用的描述及業務目標作 比較。這些比較界定服務系統的例外情形、違反或接 近違反服務需求及變更使用可能表示趨勢的服務系統 資源的型態。例如,定期監督實際服務資源使用與預 期服務資源使用可能揭示一個暫停的服務需求的違 反。 194 容量與可用度管理 SP 2.1 監督與分析能力 對照門檻的能力,監督與分析能力 關於適用於服務的能力成熟度整合模式 1.2 版 記錄每一個服務資源的使用以及每一個服務使用的每 一個資源(例如,一個服務資源由每一個服務使用的 範圍或程度)。分析資源對服務組件失效的衝擊。 對某些服務可能適合監督激增能力或到達資源的使 用,以及決定是否需要矯正行動,例如調整提供的資 源、調整門檻或調整一般使用服務資源及服務系統績 效的描述。 界定矯正行動的需要可以監督與分析能力與可用度, 或回應服務事故、變更請求、變更服務需求(現在與 未來)的結果或改善服務系統績效或預防服務協議的 違反。 有關說明資料收集與儲存程序,請參考度量與分析流 程領域,以獲得更多訊息。. 典型的工作產品 1. 服務資源使用資料 2. 服務使用的成長分析 3. 未如預測使用的資源清單 細部執行方法 1. 對照門檻、一般使用的描述及服務系統績效,監督 服務資源的使用。 有關監督專案規劃參數,請參考專案監控流程領 域,以獲得更多的資訊。 2. 監督服務回應時間。 3. 界定門檻及例外情形的違反。 容量與可用度管理 195 適用於服務的能力成熟度整合模式 1.2 版 門檻及例外情形的違反可以構成或指出一個事 故。 有關界定、控制與解決事故,請參考事故解決方 案與預防流程領域,以獲得更多的資訊。. 有關運作服務系統,請參考服務交付流程領域, 以獲得更多的資訊。 4. 決定採取的矯正行動 矯正行動包括對資源與服務的調整,以預防績效 問題或改善服務績效。調整可能是自動化地、手 動地執行或兩者。 矯正行動舉例如下: • 在資源間重新平衡工作量 • 改善服務系統流程以允許較大的生產力、效率 與有效性 • 改善服務系統設計,例如使用新的技術以允許 較大的生產力、效率與有效性 • 加入能力至服務系統,例如加入護士、伺服器 或電話線 • 調整以最佳化及改善能力或服務系統績效 • 調整服務需求 • 藉由要求管理技術,改善服務資源的使用 服務系統發展補充資料 有關發展服務系統,請參考服務系統發展流程領 域,以獲得更多的資訊。 有關管理矯正行動到結案,請參考專案管控流程 領域,以獲得更多的資訊。 196 容量與可用度管理 關於適用於服務的能力成熟度整合模式 1.2 版 5. 預測資源與服務的使用在未來的變更(成長或減 少)。 預測服務系統行為的方法與工具包括趨勢分析、 分析模組、模擬模組、基準模組與應用規模。 預測資源使用的成長可以基於所收集的能力與可 用度資料、預測的服務需求與服務系統表現方 式。 6. 儲存能力與可用度資料、規格、分析結果與監督資 料。 SP 2.2 監督與分析可用度 對照目標監督與分析可用度。 為避免服務系統組件的失效及支援系統的可用度,必 須監督服務系統。最少,要監督可用度。其他的 「度」可能適合的監督決定於服務提供的種類。信賴 度與維護度是其他的「度」可能適合監督很多種類的 服務系統。可能也需監督服務系統的回復力到服務組 件的失效,並界定服務系統可用度特定失效的衝擊。 典型的工作產品 1. 警告資料 2. 可用度資料 3. 信賴度資料 4. 維護度資料 細部執行方法 1. 對照其需求,監督可用度、信賴度及維護度。 2. 分析可用度、信賴度及維護度的趨勢。 容量與可用度管理 對某些服務而言,執行失效的趨勢分析是明智 的。 197 適用於服務的能力成熟度整合模式 1.2 版 3. 界定可用度、信賴度及維護度需求的違反。 有關界定、控制與解決事故,請參考事故解決方 案與預防流程領域,以獲得更多的資訊。 4. 決定採取的矯正行動 有關維護服務系統,請參考服務交付流程領域, 以獲得更多的資訊。 有關管理矯正行動到結案,請參考專案監控流程 領域,以獲得更多的資訊。 SP 2.3 報告容量與可用度管理資料 報告容量與可用度管理資料給相關的關鍵人員。 將能力與可用度的簡要資料報告提供給相關的關鍵人 員。這些報告對照服務協議與服務審查支援監督。資 料如何報告強烈地影響有多少的利益會從容量與可用 度管理中衍生出來。 有關對照計畫監督專案,請參考專案監控流程領域, 以獲得更多的資訊。 服務協議與供應商協議可以定義要報告的資訊、要交 付給誰及如何提供(例如,格式、細節、分送、媒 體)。這資訊應適用於觀眾,這表示它應該是可瞭解 的(例如,不是非常技術的),以及它需要解決不同 的觀點。這些觀點可以包括經營、最終使用者、客戶 或服務提供者的觀點。 能力與可用度報告可以是一般的或專屬的,端視服務 協議所定。對某些服務,報告可能藉由自動化報告數 字所提供的資料庫大大地簡化。應遵守組織報告標 準,應使用標準工具與技術,當它們存在,以支援報 告中資料的整合與合併時。 198 容量與可用度管理 關於適用於服務的能力成熟度整合模式 1.2 版 有關建立服務協議,請參考服務交付流程領域,以獲 得更多的資訊。 有關建立標準流程,請參考組織流程定義流程領域, 以獲得更多的資訊。 有關建立供應商協議,請參考供應商協議管理流程領 域,以獲得更多的資訊。 可用度通常以百分比的方式報告。除了報告可用度, 某些服務提供者也報告信賴度(例如,服務的信賴 度、服務系統組件的信賴度)因為它在服務協議中是 必要的。服務協議也需要報告維護度與其他「度」。 典型的工作產品 1. 服務系統績效報告 2. 服務資源使用報告 3. 服務資源使用預測 4. 服務可用度報告 細部執行方法 1. 報告資源與服務的績效與使用。 2. 報告服務系統中的例外情形與服務需求的違反。 3. 報告監督資源與服務使用的成長預測資料。 4. 報告資源與服務的可用度、信賴度與維護度。 容量與可用度管理 199 適用於服務的能力成熟度整合模式 1.2 版 原因分析與解決方案 成熟度第五級的支援類流程領域 目的 簡介 200 原因分析與解決方案(Causal Analysis and Resolution, CAR)的目的,在於界定造成缺失和其他問題的原 因,並採取行動以避免未來再度發生。 原因分析與解決方案流程領域包括下列活動: • 界定並分析造成缺失和其他問題的原因 • 採取行動,以移除造成缺失及問題的原因, 並避免此類缺失及問題未來再度發生 藉由原因分析與解決方案以改善品質和生產力避免將 缺失導入產品。在缺失發生後再進行偵測是不符合成 本效益的。更有效的方式是,將原因分析與解決方案 的活動整合到專案的每個階段,以避免缺失的發生。 既然類似的缺失和問題可能發生於先前的其他專案或 現有專案的稍早階段,原因分析與解決方案的活動可 以做為各專案間溝通學習的機制。 分析所發生的缺失和其他問題的類型,以界定其趨 勢。依對已調適流程及其如何實施的瞭解為基礎,判 定缺失的根本原因及未來可能發生的地方。 原因分析也可以運用於與缺失無關的問題上。例如: 原因分析可用來改善與一個或多個供應商之間的協調 以及週期時間。 原因分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 當對所有的缺失進行原因分析並不實際時,必須在預 估的投資與預估的品質、生產力、週期時間的報酬之 間做取捨,選擇缺失目標。 雖然在某些情況下,也許需要新的度量來分析流程變 更的影響,但度量流程應準備妥當,並使用已定義的 度量。 有關建立度量與分析的目標、界定待執行的度量與分 析、取得和分析度量資料,以及報告結果等,請參考 度量與分析流程領域,以獲得更多資訊。 原因分析與解決方案活動提供專案一個機制,以便在 專案層級評估其流程,並找尋可實施的改善措拖。 當改善措施在專案層級的實施被認定為有效時,這些 資訊可擴展至組織層級。 有關經由所建議的改善措施和行動建議,以改善組織 層級的流程,請參考組織創新與推展流程領域,以獲 得更多資訊。 本流程領域的助益性資料的前提為特定執行方法適用 量化管理流程。在不考慮此前提的情況下,本流程領 域的特定執行方法也可適用,不過會降低所產生的價 值。 有關「穩定流程」和「流程變異的共同原因」的定 義,請參見詞彙。 相關流程領域 有關分析流程績效與決定流程能力,請參考量化專案 管理流程領域,以獲得更多資訊。 原因分析與解決方案 201 適用於服務的能力成熟度整合模式 1.2 版 有關針對組織流程和技術改善的選擇與推展,請參考 組織創新與推展流程領域,以獲得更多資訊。 有關建立度量與分析的目標、界定待執行的度量與分 析、取得和分析度量資料,以及報告結果等,請參考 度量與分析流程領域,以獲得更多資訊。 特定目標及執行方法摘要 SG 1 決定造成缺失與問題的原因 SP 1.1 選擇缺失與問題 SP 1.2 分析原因 SG 2 說明造成缺失與問題的原因 SP 2.1 實施行動建議方案 SP 2.2 評估變更的效果 SP 2.3 記錄相關資料 各目標的特定執行方法 202 原因分析與解決方案 SG 1 決定缺失與問題的原因 關於適用於服務的能力成熟度整合模式 1.2 版 有系統地決定造成缺失和其他問題的根本原因。 根本原因是缺失的源頭,若移除根本原因,那麼就移除或減少 缺失。 SP 1.1 選擇待分析的缺失資料 選擇缺失和其他問題資料,以進行分析。 典型的工作產品 1. 選定待進一步分析的缺失和問題資料 細部執行方法 1. 蒐集相關的缺失或問題資料。 相關缺失資料,舉例如下: • 客戶反應的缺失 • 服務小組反應的缺失 • 服務驗證所發現的缺失 有關問題資料,舉例如下: • 需要矯正措施的專案管理問題 • 流程能力的問題 • 流程期間的度量 • 資源流量、適用率、或反應時間度量 • 服務台電話,依時間及偶發事件類別 • 服務系統不合適的可利用度 有關統計化管理,請參考量化專案管理流程領 域,以獲得更多資訊。 2. 決定需進一步分析的缺失和其他問題。 原因分析與解決方案 203 適用於服務的能力成熟度整合模式 1.2 版 在決定哪些缺失需進一步分析時,應考慮缺失的 影響、發生頻率、缺失間的相似性、分析成本、 所需的時間和資源、安全性考量等等。 選擇缺失和其他問題的方法,舉例如下: • 柏拉圖分析 • 直方圖 • 原因與效果分析(例如,正在發展中的服務系 統的設計失敗模式與影響分析,服務系統發展 或服務遞送的流程失敗模式與影響分析) SP 1.2 分析原因 針對所選的缺失和其他問題,進行原因分析,並提出 處理的行動方案。 原因分析的目的,在於藉由分析相關資料和產生實施 的行動建議,以發展所界定問題的解決方案。 典型的工作產品 1. 行動建議方案 2. 根本原因分析的結果 細部執行方法 1. 與負責執行該項工作的人共同分析原因。 通常以會議的方式,與瞭解缺失和其他問題的 人,針對所選的缺失和其他問題,共同進行原因 分析的研究,而最瞭解缺失的人通常也是負責執 行該項工作的人。 204 原因分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 執行原因分析的時機,舉例如下: • 當穩定的子流程無法滿足它的品質和流程績效 目標時 • 工作期間,如果以及當問題保證原因分析會議 時。 • 當工作產品與其需求之間存在非預期的差異時 有關監督擇定的細部流程的績效,請參考量化專 案管理流程領域,以獲得更多資訊。 2. 分析所選的缺失和其他問題,以決定它們的根本原 因。 在界定根本原因之前,可依缺失的類型和數量先將 它們分類。 決定根本原因的方法,舉例如下: • 因果圖,即魚骨圖 • 查核表 3. 依據根本原因,將所選的缺失和其他問題分類進 行。 原因分析與解決方案 205 適用於服務的能力成熟度整合模式 1.2 版 原因的類別,舉例如下: • 訓練與技能不足 • 不充分的資源配置 • 溝通中斷 • 沒有說明工作的所有細節 • 人為操作錯誤(例如:打錯字) • 流程缺失 4. 建議並記錄需要採行的行動方案,以避免未來發生 類似的缺失或其他問題。 建議的行動方案可能包括對下列的變更: • 有問題的流程 • 訓練 • 工具 • 方法 • 溝通 • 工作產品 206 原因分析與解決方案 行動方案舉例如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 針對共通性的問題和技術,提供訓練以避免再 度發生 • 變更流程,使易犯錯的步驟不再發生 • 流程的局部或全部自動化 • 將流程活動重新排序 • 增加避免缺失的流程步驟,例如:增加工作啟 動會議,以審查共同的缺失和行動方案,並避 免再度發生 行動建議方案,通常記錄下列各項: • 行動建議的發起人 • 問題說明 • 缺失原因說明 • 缺失原因類別 • 提出問題的階段 • 界定出缺失的階段 • 行動建議的說明 • 行動建議的類別 SG 2 處理造成缺失與問題的原因 有系統地處理造成缺失和其他問題的根本原因,以避免未來再 度發生。 專案依已妥善調適的流程運作,若仍然發生問題,專 案會系統化的分析運作問題發生所在並實施流程變 更,以消除所選問題的根本原因。 原因分析與解決方案 207 適用於服務的能力成熟度整合模式 1.2 版 SP 2.1 實施行動建議方案 實施原因分析所發展的行動建議方案。 行動建議方案描述必要工作,用以移除經過分析之缺 失和問題的根本原因,並避免它們再度發生。只有證 明此變更有價值,才可考慮將其廣泛實施。 典型的工作產品 1. 已選定要實施的行動建議 2. 改善建議 細部執行方法 1. 分析各種行動建議,並決定優先順序。 排定行動建議優先順序的準則,包括: • 未處理缺失的意涵 • 實施流程改善措施以避免缺失的成本 • 對品質的預期影響 2. 選擇將實施的行動建議。 3. 產生實施行動建議的行動項目。 208 原因分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 行動項目所提供的資訊,舉例如下: • 負責實施的人 • 受影響領域的描述 • 必須被告知行動狀況的人 • 下一次進行狀況審查的日期 • 關鍵決策的理由 • 實施行動的描述 • 界定和矯正缺失所需時間和成本 • 不解決問題的預估成本 實施行動建議必須執行下列各項工作: • 指派工作 • 協調執行工作的相關人員 • 審查各項結果 • 追蹤各行動項目至結案為止 針對特殊複雜的變更,可先進行實驗。 實驗的舉例如下: • 使用暫時性已修訂的流程 • 使用新工具 行動項目可指派給原因分析團隊、專案團隊,或 組織內其他的成員。 4. 界定並移除可能存在於其他流程和工作產品的類似 缺失。 5. 界定並記錄組織標準流程的改善建議。 原因分析與解決方案 209 適用於服務的能力成熟度整合模式 1.2 版 有關收集與分析改善建議,請參考組織創新與推 展流程領域,以獲得更多資訊。 SP 2.2 評估變更的效果 評估變更在流程績效上所產生的效果。 有關選擇度量與分析技術,請參考量化專案管理流程 領域,以獲得更多資訊。 一旦在專案內推展已變更的流程,應檢查變更所產生 的效果,以便蒐集相關證據來證明該流程變更確已矯 正問題和改善績效。 典型的工作產品 1. 績效和績效變更的度量 細部執行方法 1. 適當地度量專案的已調適流程或子流程的績效變 更。 本細部執行方法決定所選的變更對流程績效是否 有正面影響及其影響程度。 以服務績效的改變是為整合修改過的服務系統組 件,改變子流程後,服務遞送成本的改變。這個 績效的改變將藉由監督改善前後的交付服務,以 及統計上(例如藉由假設性的測試)比較的差異 而決定。在統計流程管控圖表,這個績效上的改 變將由此一改變代表。 2. 適當地度量專案已調適流程或子流程的能力。 210 原因分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 這個細部執行方式決定選定的改變是否正面地影 響流程的能力以符合由關鍵人員決定定的品質與 流程績效目標。 以服務能力的改變將會是交付服務能力的改變為 例,如此一來,最後結果的服務會停留在其成本 範圍內。這個改變可能藉由計算監督改善前後的 交付服務成本的範圍,被統計化地度量。在統計 流程管控圖表,這個成本上的改變會由狹隘的管 控限制代表。 SP 2.3 記錄相關資料 記錄原因分析和解決方案相關資料,以供專案和組織 使用。 記錄資料,使其他專案和組織可做適當的流程變更並 達成相似結果。 記錄下列資料: • 分析之缺失和其他問題的資料 • 決策的理由 • 原因分析會議的行動建議方案 • 行動建議方案所導出的行動項目 • 原因分析與解決方案活動的成本 • 解決方案之已調適流程績效變更的度量 典型的工作產品 1. 原因分析與解決方案的紀錄 原因分析與解決方案 211 適用於服務的能力成熟度整合模式 1.2 版 建構管理 成熟度第二級的支援流程領域 目的 建構管理(Configuration Management, CM)的目的,在 使用建構識別、建構控制、建構狀態紀錄及建構稽 核,來達到建立與維護工作產品之完整性。 簡介 建構管理流程領域,包含下列活動: • 界定所選定之工作產品的建構,這些工作產品 在特定的時間點會組成基準 • 管制建構項目的變更 • 建立或提供規格,以便從建構管理系統建造工 作產品 • 維護基準的完整性 • 提供正確的狀態和目前的建構資料給發展人員、 最終使用者及客戶 納入建構管理的工作產品,包含交付客戶的產品、指 定的內部工作產品、取得的產品、工具,以及其他用 以產生或描述這些工作產品的項目。(有關「建構管 理」的定義,請參見詞彙。) 212 建構管理 建構管理 關於適用於服務的能力成熟度整合模式 1.2 版 可能納入建構管理的工作產品,舉例如下: • 計畫 • 流程說明 • 需求 • 設計資料 • 圖表 • 產品規格 • 軟體 • 電腦編譯程序 • 產品資料檔案 • 產品技術出版品 • 服務協議 • 管控軟體及附屬證照資料及文件之授權版本 • 資產資料的儲存庫 需求的產品需要由供應商及需求者放置在建構管理之 下。提供執行建構管理應該建立在供應商合約中。並 應該建立與維護確保資料完整及一致的方式。 參考供應商協議管理流程領域以獲得更多有關建立供 應商協議的資訊。 工作產品的建構管理可能在數個層級呈現。建構項目 被分解為建構組件及建構單位。 基準是建構項目持續演進的穩定基礎。 當基準發展完成,就會納入建構管理系統。基準的變 更與自建構管理系統所建造之工作產品的發行,經由 建構管理的建構管制、變更管理及建構稽核等功能, 進行有系統的管制與監督。 213 適用於服務的能力成熟度整合模式 1.2 版 本流程領域不只適用於專案的建構管理,也適用於組 織工作產品,如標準、程序及再用程式庫的建構管 理。 建構管理著重在管理面和技術面的工作產品嚴格管 制,包含已交付的產品或服務。 建構管理流程領域涵蓋執行建構管理功能的執行方 法,也適用於已納入建構管理的所有工作產品。 相關流程領域 有關監督專案是否符合計畫及管理矯正措施至結案為 止,請參考專案監督與管控流程領域,以獲得更多資 訊。 有關發展計畫和分工結構圖,請參考專案規劃流程領 域,以獲得更多資訊。分工結構圖可用於決定哪些是 建構項目。 特定目標及執行方法摘要 SG 1 建立基準 SG 1 建立基準 SP 1.1 界定建構項目 SP 1.2 建立建構管理系統 SP 1.3 建立或發行基準 SG 2 追蹤並管制變更 SP 2.1 追蹤變更申請 214 建構管理 SP 2.2 管制建構項目 SG 3 建立完整性 SP 3.1 建立建構管理紀錄 SP 3.2 實施建構稽核 關於適用於服務的能力成熟度整合模式 1.2 版 各目標的特定執行方法 SG 1 建立基準 建立由已界定的工作產品所組成的基準。 本特定目標涵蓋用以建立基準的特定執行方法。「追 蹤並管制變更」特定目標所涵蓋的特定執行方法用以 維護基準,而「建立完整性」特定目標的特定執行方 法則用以記錄和稽核基準的完整性。 SP 1.1 界定建構項目 界定將納入建構管理的建構項目、組件及相關的工作 產品。 建構識別為下列項目的選擇、建立及說明: • 交付客戶的產品 • 指定的內部工作產品 • 取得的產品 • 工具及其他專案工作環境的資本資產 • 其它用以產生或說明這些工作產品的項目 納入建構管理的項目,包含用於說明工作產品需求的 規格和介面文件;也包含其他的文件,例如:測試結 果。可依據它對於定義產品的重要性,來決定是否納 入建構管理。 建構管理 215 適用於服務的能力成熟度整合模式 1.2 版 建構項目是被指定要納入建構管理的實體,它可能包 含組成某基準的數個相關工作產品。這種邏輯上的編 組,提供較容易的識別和存取控制。應根據規劃時所 定的準則,選取需納入建構管理的工作產品。 典型的工作產品 1. 已界定的建構項目 細部執行方法 1. 根據文件化的準則,選擇建構項目和組成這些項 目的工作產品。 在適當的工作產品層次中,選擇建構項目的準 則,舉例如下: • 會隨著時間而變更的工作產品,其變更原因可 能是發生錯誤或變更需求 • 會隨著時間而變更的工作產品,其變更原因可 能是發生錯誤或變更需求 • 數個相互依存的工作產品,(例如,當其中一 個改變時,將會影響到其他的工作產品) • 對專案成功具有重要性的工作產品 216 建構管理 關於適用於服務的能力成熟度整合模式 1.2 版 可組成建構項目的取得的工作產品及供應商可交 付項目,舉例如下: • 流程說明 • 需求 • 設計 • 測試計畫與程序 • 測試結果 • 介面描述 • 圖表 • 原始碼 • 工具(例如電腦編譯程序) 2. 指定每個建構項目唯一的識別碼。 3. 界定每個建構項目的重要特性。 建構項目特性的例子包括作者、文件或檔案型 態、軟體編碼檔案的程式語言及建構項目服務的 目的。 4. 界定每個建構項目納入建構管理的時間點。 建構管理 217 適用於服務的能力成熟度整合模式 1.2 版 何時將工作產品納入建構管理的準則,舉例如 下: • 在專案生命週期的各階段 • 當取得的工作產品準備好可進行審查及審核的 時候 • 工作產品需要某種程度控制的時候 • 成本和時程的界限 • 關鍵人員的需求 5. 界定每個建構項目的負責人。 6. 說明建構項目間的關係 將現存於建構項目的關係型態(例如親子,互相 依賴)融入於建構管理架構(例如建構管理資料 庫),以協助管理修改的效果與影響。 SP 1.2 建立建構管理系統 建立並維護一個建構管理與變更管理的系統,以便管 制工作產品。 建構管理系統包含:儲存媒體、運作程序,以及存取 該系統的工具。一個建構管理系統可以包含不同執行 的子系統,其適合每一個建構管理環境。 在某些服務領域,建構管理著重在文件版本及修改管 控。 一個修改管理系統包括儲存媒體、程序及記錄及存取 修改要求的工具。 典型的工作產品 1. 建構管理系統,內含被管制的工作產品 218 建構管理 建構管理 2. 建構管理系統的存取控制程序 3. 變更申請資料庫 關於適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 建立多重管制層級的機制。 管制層級通常依照專案目標、風險及資源選擇。 管控層級在專案生命週期、發展中的系統型態及 特定的專案需求中可能不同。 管制層級的例子如下: • 不管制:任何人可以修改 • 工作進行中:作者管制修改 • 釋出:指定的授權者授權及管制改變,而相關 的關鍵人員被通知已做了修改。 管制層級的範圍可能從非正式的管制,例如只追 蹤已發展的建構項目的改變,或到正式的使用被 修改為正式建構管制流程的基準線來進行建構管 制。 2. 提供存取管制以確保被授權存取建構管理系統。 3. 在建構管理系統中,存取建構項目。 4. 在建構管理系統的不同程度管制機制下,分享和移 轉建構項目。 5. 儲存和復原已歸檔保存的建構項目版本。 6. 儲存、更新及獲取建構管理記錄。 7. 自建構管理系統產生建構管理報告。 219 適用於服務的能力成熟度整合模式 1.2 版 8. 保存建構管理系統的內容。 建構管理系統的保存功能,舉例如下: • 建構管理檔案的備份和復原 • 建構管理檔案的歸檔保存 • 建構管理錯誤的復原 9. 必要時,修訂建構管理結構 SP 1.3 建立或發行基準 建立或發行供內部使用和交付給客戶的基準。 基準是一組經正式審查和同意的規格或工作產品,也 是未來發展或交付的基礎,而且只能經由變更控制程 序才能改變此基準。基準表示對一個或多個建構項目 及相關項目之識別的指定。 當產品或服務演進中,有幾個基準可用來控制產品的 發展與測試。 基準線的型態,舉例如下: • 關鍵人員需求 • 界定的風險 • 現行的服務層級及資源使用 • 運作計畫 • 時程 典型的工作產品 1. 基準 2. 基準說明 220 建構管理 細部執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 1. 在建立或發行建構項目的基準之前,取得建構管制 委員會的授權 2. 只有來自建構管理系統的建構項目,才能建立基準 或發行基準。 3. 記錄基準所含的建構項目。 4. 使目前最新的基準,隨時可供使用。 SG 2 追蹤並管制變更 追蹤並管制已納入建構管理工作產品的變更。 本特定目標所涵蓋的特定執行方法用來維護基準,這些基準是 由「建立基準」特定目標所涵蓋的特定執行方法所建立。 SP 2.1 追蹤變更申請 追蹤建構項目的變更申請。 變更申請不只用於新的需求或需求的變更,也可用於 工作產品的故障或缺失。 分析變更申請,以決定此變更對工作產品、相關工作 產品、時程及成本的影響。 典型的工作產品 1. 變更申請 細部執行方法 1. 啟動變更申請,並記錄於變更申請資料庫。 2. 分析變更建議和所需的修改所造成的影響。 改變是經由確保他們與所有技術及專案需求一致 的活動來評估。 建構管理 221 適用於服務的能力成熟度整合模式 1.2 版 改變是評估它們對專案或管制需求的立即影響。 對一個使用在不同產品的項目的改變,可能其他 應用造成問題時,解決一個立即的議題。 評估改變對已釋出計畫的影響。 3. 將改變需求分類及訂定修先順序。 若合適,緊急需求被界定及參照到緊急授權。 改變被配置到未來的基準 4. 如果變更申請會影響其他基準,應與相關的關鍵 人員一起審查這些變更申請,並取得他們的同 意。 執行變更申請審查時,讓合適的人參與決定,並 記錄每一變更申請的處理方法和決策理由,包含 成功的準則、簡單的行動計畫及變更是否符合需 要等。執行處理方法所提的行動,並將結果告知 相關的關鍵人員。 5. 追蹤變更申請的狀態直到結案。 被帶到系統中的改變需求應該有效率且及時的處 理。一旦改變需求已經進行,很重要的是以適當 的被核可措施來結束一個需求。所採取行動應保 持開放以產生大於所需狀態的清單,這結果會造 成附加的成本及困擾。 SP 2.2 管制建構項目 管制建構項目的變更。 需要管制工作產品基準的建構,管制包含追蹤每一建 構項目的建構、必要時核准新的建構,並更新基準。 典型的工作產品 1. 建構項目的修訂歷史紀錄 222 建構管理 建構管理 2. 基準的保存檔 關於適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 在整個產品生命週期,管制建構項目的變更。 2. 變更後的建構項目,在納入建構管理系統之前, 必須獲得適當的授權。 舉例來說,授權可來自建構管制委員會、專案經 理或客戶。 3. 針對同時受某些變更影響的建構項目,在簽入或簽 出建構管理系統時,必須設法維護這些建構項目 的正確性和完整性。 簽入和簽出步驟例子如下: • 確認修改是被授權的 • 更新建構項目 • 將被取代的基準線檔案化並獲取新的基準線 4. 執行審查,以確保該變更沒有對基準造成意料外 的影響。例如:確保變更沒有影響系統的安全及 (或)機密。 5. 適當記錄建構項目的變更和變更的理由。 若一個對工作產品建議的改變被接受,即要界定 一個時程將對工作產品的改變及其他受影響的領 域納入。 建構管制機制可以針對改變類別客製化。例如, 經同意的考量對於未影響其他組件的組件改變可 能較不嚴格。 修改的建構項目在建構改變檢視及同意後被釋 出。改變直到它們被釋出後才是正式的。 223 適用於服務的能力成熟度整合模式 1.2 版 SG 3 建立完整性 建立並維護基準的完整性。 「建立基準」特定目標的流程用於建立基準,「追蹤 並管制變更」特定目標的流程用於維護基準,而本特 定目標所涵蓋的特定執行方法則用以記錄和稽核基準 的完整性。 SP 3.1 建立建構管理紀錄 建立並維護描述建構項目的紀錄。 典型的工作產品 1. 建構項目的修訂歷史紀錄 2. 變更過程的紀錄 3. 變更申請的紀錄 4. 建構項目的狀態 5. 不同基準間的差異 細部執行方法 1. 詳細記錄建構管理活動,使他人知道每個建構項目 的內容和狀態,並能復原建構項目的先前版本。 2. 確保相關的關鍵人員,能存取和瞭解建構項目的建 構狀態。 溝通建構狀態的活動,舉例如下: • 對經授權的最終使用者提供存取允許 • 對經授權的最終使用者提供基準複本 224 建構管理 3. 標示基準的最新版本。 關於適用於服務的能力成熟度整合模式 1.2 版 4. 界定組成某基準之建構項目的版本。 5. 描述前後版本基準間的差異。 6. 必要時修訂建構項目的狀態和歷史紀錄(指變更及 其他行動)。 SP 3.2 實施建構稽核 實施建構稽核以維護建構基準的完整性。 建構稽核確認最終的基準和文件有遵照特定標準或需 求。建構項目相關的記錄可能存在於不同的資料庫或 建構管理系統。在這種情形下,建構稽核應該擴大到 其他適當的資料庫以確保建構項目資料的正確、一致 及完整性。(有關「建構稽核」的定義,請參照詞 彙。) 稽核型態,舉例如下: • 功能建構稽核:執行稽核以驗證測試過的建構 項目的功能特色達到在功能基準文件中所描述 的需求。並且其操作及支援文件是完整的且令 人滿意的。 • 實際的建構稽核(PCA):執行稽核以驗證 已建立的建構項目確實如技術文件所定義的。 • 建構管理稽核:執行稽核以確認建構管理記錄 及建構項目是完整的、一致的及正確的。 典型的工作產品 1. 建構稽核結果 2. 行動項目 細部執行方法 1. 評量基準的完整性。 建構管理 225 適用於服務的能力成熟度整合模式 1.2 版 2. 確認建構管理紀錄已正確界定建構項目。 3. 審查建構管理系統中,建構項目的結構和一致性。 4. 確定建構管理系統中,建構項目的完整性和正確 性。 依據計畫中所述的需求和已核准之變更申請的處 理為基礎,來判斷建構管理系統內容的完整性和 正確性。 5. 確定符合適用的建構管理標準和程序。 6. 追蹤稽核的行動項目直到結案。 226 建構管理 關於適用於服務的能力成熟度整合模式 1.2 版 決策分析與解決方案 成熟度第三級的支援類流程領域 目的 決策分析與解決方案(Decision Analysis and Resolution, DAR)的目的,在於利用正式的評估流程,依據已建 立的準則評估各種已界定的備選方案,以分析可能的 決策。 簡介 決策分析與解決方案流程領域包含建立指引,以決定 什麼議題需要正式評估流程,並引用正式評估流程解 決議題。 正式評估流程為一結構化的方法,依據已建立的準則 評估備選解決方案,並決定推薦的方案。 正式評估流程包含下列的活動: • 建立評估備選方案的準則 • 界定備選解決方案 • 選擇評估備選方案的方法 • 使用已建立的準則與方法,評估備選解決方案 • 依據評估準則,從備選方案中選擇建議方案 在本流程領域中要表達「解決議題的備選解決方案」 時,將使用:備選解決方案(alternative solutions)或備 選方案(alternatives)。 正式評估流程是減少決策的主觀性,並提供較高的可 能性選擇一符合相關關鍵人員多樣需求的解決方案。 決策分析與解決方案 227 適用於服務的能力成熟度整合模式 1.2 版 本流程領域主要應用於選定技術的重要事項,正式評 估流程也可應用於許多非技術的議題,特別當專案開 始規劃,議題有多種備選解決方案與評估準則時,適 合使用正式評估流程。 正式評估流程的典型例子包括: • 裝備或軟體的替代方案研究 • 建立潛在服務能力的比較 在計畫期間,特定的議題需要一個正式的評估流程。 典型的議題包括在架構或設計替代方案中選擇、使用 可重複使用或商業套裝組件、挑選供應商、工程支援 環境或伴隨的工具、測試環境、交付的替代方案及運 籌與製造。一個正式的評估流程也可以用在製造-或 -購買的決策、製造流程的建立、運送地點的選擇及 其他的決策。 建立指引,以決定何時使用正式評估流程來解決非規 劃的議題。當議題涉及中高風險或議題會影響達成專 案目標的能力時,指引通常建議使用正式評估流程。 正式評估流程有不同的形式、準則類型及使用的方 法,例如:較不正式的決策,其分析可能花費幾小 時、使用幾條準則(如有效性和建置的成本),以及產 生一兩頁報告;但是較正式的決策可能需要個別計 畫、幾個月的工作量、研訂與核准準則的會議、模 擬、雛型、試用及大量的文件。 正式評估流程可使用量化或非量化的準則。量化準則 使用權重以反映準則的相對重要性;非量化準則使用 較主觀的等級劃分(如:高、中、低)。較正式的決策 可能要求完整的替代方案研究。 228 決策分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 正式評估流程界定與評估各種備選解決方案。選定最 後方案的過程,可能包括反覆的界定與評估活動。在 評估期間,已界定的備選方案,可能部分的被組合、 新出現的技術也可能改變備選方案,而供應商的經營 情況在評估期間也可能改變。 所建議的備選方案伴隨選定之方法、準則、備選方案 及建議理由的文件,此文件將分送給相關關鍵人員, 並提供正式評估流程的紀錄及理由,它對其他未來遇 到相似議題的專案是有幫助的。 整個專案中,部分決策涉及正式評估流程,其他決策 則否,就像之前所述,建立指引以決定哪些議題是屬 於正式評估流程。 相關流程領域 有關建立專案的已調適流程,參考整合專案管理流程 領域,以獲得更多資訊。專案的已調適流程包括對每 一個選定議題的正式評估流程以及對未預見的議題採 行正式評估流程的使用指引。 有關確認、分析和減緩風險,參考風險管理流程領 域,以獲得更多資訊。 特定目標和執行方式摘要 SG 1 評估備選方案 SP 1.1 建立決策分析指引 SP 1.2 建立評估準則 SP 1.3 界定備選解決方案 SP 1.4 選擇評估方法 SP 1.5 評估備選方案 SP 1.6 選擇解決方案 決策分析與解決方案 229 適用於服務的能力成熟度整合模式 1.2 版 各目標的特定執行方式 SG 1 評估備選方案 使用已建立的準則,根據評估的備選方案作決策 在產品或專案的任何時間點都可能界定出需正式評估 流程的議題。目標為儘早界定議題,使得有較充裕時 間解決該議題。 SP 1.1 建立決策分析指引 建立並維護指引,以決定哪些議題須經正式評估流 程。 不是每個決策都足夠重要到需要正式評估流程。若沒 有明確的指引,在重要與不重要之間的選擇會不清 楚。一個決策重要與否,與專案及環境相關,並由已 建立的指引加以決定。 用來決定何時需要正式評估流程的典型指引,包 含如下: • 當某決策與中高度風險主題有直接關係時 • 當某決策與在建構管理下之工作產品的變更有 關時 • 當某決策會導致時程延誤超過某一比例或時間 時 • 當某決策影響達成專案目標的能力時 • 當正式評估流程的成本與決策衝擊相比較是合 理時 • 當招標中有合法契約時 有關決定哪些議題屬於中高風險,請參考風險管理流 程領域,以獲得更多資訊。 230 決策分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 使用正式評估流程的時機,舉例如下: • 在標準服務描述中選擇包含的元素 • 選擇、終止或更新供應商 • 選擇專案成員訓練 • 在選擇一個繼續支援的處理(如災害回復、服 務層級) 典型的工作產品 1. 何時引用正式評估流程的指引 細部執行方法 1. 建立使用正式評估流程時機的指引。 2. 適當時,將指引的使用併入已調適流程中。 有關建立專案已調適流程,請參考整合的專案管 理流程領域,以獲得更多資訊。 SP 1.2 建立評估準則 建立並維護用來評估備選方案的評估準則及其相對排 序。 評估準則提供評估備選解決方案的基礎。將準則排 序,以使得排序最高的準則代表對評估有最大的影 響。 CMMI 模式的許多其他流程領域參考本流程領域,正 式評估流程也在許多地方使用。因此,在某些情況下 你會發現準則已經定義於其他的流程中。本特定執行 方法不建議再次發展相同的準則。 記錄評估準則,以避免後續決策猜疑的可能性或忘掉 作成該決策的原因,依據已明確定義及建立的準則所 作的決策,可排除關鍵人員的認同障礙。 決策分析與解決方案 231 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 評估準則的紀錄 2. 準則重要性排序 細部執行方法 1. 定義評估備選解決方案的準則。 準則應可追溯到需求、劇本、經營個案假設、經 營目標或其他已記錄的來源。 考量的準則類型包括如下: • 技術限制 • 環境衝擊 • 風險 • 所有權及生命週期成本 2. 定義評估準則分級的範圍與等級。 可運用非數字的值或將評估參數和權重數值結合 的公式,建立評估準則之相對重要性的等級。 3. 將準則排序。 4. 評估準則及其相對的重要性。 5. 漸進發展評估準則以改善其有效性。 6. 記錄選用及捨棄評估準則的理由。 記錄選用準則與理由可能需要用來判斷解決方案 或做為未來參考與使用。 SP 1.3 界定備選解決方案 界定解決議題的備選解決方案。 232 決策分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 儘可能請關鍵人員提出廣泛的備選方案,關鍵人員的 技能和背景皆不相同,其建議有助於界定和解決各種 假設、限制及偏見。腦力激盪會議經由快速互動與回 饋可刺激有創意的備選方案。 充分的備選方案可能也不足提供分析,當分析進行 時,其它方案應加到可能的候選解決方案清單內,在 決策分析與解決方案流程初期,考量與產生多樣的備 選方案,可增加做成可接受之決策的可能性,且該決 策的結果較易理解。 典型的工作產品 1. 已界定的備選方案 細部執行方法 1. 執行文獻搜尋。 文獻查詢可發覺組織內外曾做過的事情,可提供 對下列有更深的瞭解:問題、考慮的備選方案、 執行障礙、既有的替代方案研究及類似決策的學 習心得。 2. 除了議題的解決方案之外,界定納入考量的備選 解決方案。 評估準則是界定備選方案的有效起點。評估準則 界定相關關鍵人員的優先順序及技術、後勤或其 他挑戰的重要性。 組合既有方案的關鍵屬性可能產生額外的方案, 且有時侯是更具說服力的方案。 誘導相關關鍵人員提出備選方案。可有效地使用 腦力激盪、訪談及工作小組等方式以發現備選方 案。 決策分析與解決方案 233 適用於服務的能力成熟度整合模式 1.2 版 3. 記錄提議的方案。 SP 1.4 選擇評估方法 選擇評估方法 依據已建立的準則,用以評估備選方案的方法,其範 圍從模擬到使用機率和決策理論,這些方法必須小心 選擇。方法的詳細程度應與成本、時程、績效及風險 的衝擊相稱。 雖然許多問題只需一種評估方法,但有些問題可能需 要多種方法。舉例來說,模擬可加強替代方案研究, 以決定那個設計備選方案最符合特定的準則。 典型的工作產品 1. 已選擇的評估方法 細部執行方法 1. 以分析決策的目的與可用以支援該方法之資訊的 可用性為基礎,來選擇方法。 例如,用來評估解決方案的方式,當其需求是微 弱地被調適,可能與需求被確切調適的方式不 同。 典型的評估方法包含下列: • 模式組與模擬 • 工程研究 • 製造研究 • 成本研究 • 經營機會研究 • 調查 • 依據經驗與雛型加以推斷 234 決策分析與解決方案 • 使用者審查與評論 關於適用於服務的能力成熟度整合模式 1.2 版 • 測試 • 一個或一組專家的判斷(例:Delphi 方法) 2. 依據專注於手邊的議題,而不受無關議題過度影 響的能力,選擇評估方法。 3. 決定支援評估方法所需的度量。 考量成本、時程、績效及風險的影響 SP 1.5 評估備選方案 使用已建立的準則與方法,評估備選方案。 評估備選方案包括:分析、討論及審查。反覆的分析 有時是必要的。可能需要支援分析、實驗、雛型、演 練或模擬,以支持評分及結論。 準則的相對重要性經常是不精確的,且解決方案的整 體效果往往在執行相關分析工作之後才會明顯。若各 備選方案的評分結果差距不大,則可能無法從備選解 決方案中明確選出最佳者。應鼓勵對準則及假設條件 的挑戰。 典型的工作產品 1. 評估結果 細部執行方法 1. 使用已建立的評估準則與選定的方法,評估提議 的備選解決方案。 2. 評估各種評估準則的假設條件,以及支持該假設 條件的各種證據。 決策分析與解決方案 235 適用於服務的能力成熟度整合模式 1.2 版 3. 評估是否有價值觀念的不確定性影響備選解決方 案的評估,並適當的滿足這些不確定性。 4. 必要時,執行模擬、塑模、雛型及試行,以測試 評估準則、方法及備選解決方案。 未經試驗的準則,其相對的重要性以及支援資料 或功能,可能造成對解決方案實用性的質疑。準 則及其相對的優先順序與規模大小,可試用於一 些備選方案以進行測試。試用這些評估準則,使 準則得以在解決方案中進行漸進的影響性評估。 若試用顯現問題,則應考慮不同的準則或備選方 案,以避免偏差。 5. 若建議的備選解決方案無法通過測試時,考量新 的備選解決方案、準則及方法。並重複評估活 動,直到備選方案能通過測試。 記錄增加新備選方案或方法、準則變動的理由, 以及中間評估的結果。根據先前決定的評量準則 及成績方法,為每個備選方案決定成績。 6. 記錄評估結果。 SP 1.6 選擇解決方案 依據評估準則,從備選方案中選擇解決方案。 選擇解決方案包含對於備選方案評估結果,賦予權 重。必須評量執行解決方案有關的風險。 典型的工作產品 1. 解決重大議題的建議解決方案 細部執行方法 1. 評量執行建議解決方案相關的風險。 有關如何界定與管理風險,請參考風險管理流程 領域,以獲得更多資訊。 236 決策分析與解決方案 關於適用於服務的能力成熟度整合模式 1.2 版 2. 記錄建議解決方案的結果及理由。 決策分析與解決方案 237 適用於服務的能力成熟度整合模式 1.2 版 整合的專案管理 成熟度第三級的專案管理類流程領域 目的 簡介 整合的專案管理(Integrated Project Management, IPM) 旨在建立並管理專案及相關關鍵人員的參與,其依據 為組織標準流程裁適而成之已整合與調適的流程。 “專案"是指一組人及資源承諾共同規劃、監督及執 行已調適的流程以達到一組由營業及(現在或未來) 客戶的目標衍生出來的目的。從此領域及相關流程領 域的執行方式所獲得的業務價值,有一部份正確地界 定這些工作為“專案"。 參考專案規劃流程領域的簡介以獲得更多有關使用 “專案"一詞及使用該詞語的特定執行方式的應用資 訊。 整合的專案管理包含下列活動: • 在啟動專案時,經由調適組織標準流程以建立專 案之已調適流程。 • 使用已調適流程來管理專案。 • 根據組織工作環境標準,建立專案的工作環境。 • 建立整合團隊並賦予工作,以達成專案目標 • 使用與回饋組織流程資產。 • 在產品的發展過程中,使相關關鍵人員所關心的 議題均被界定、考慮及適當的處理。 238 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 • 確保相關關鍵人員以合作與準時的態度執行工 作,以(1)處理:產品與產品組件需求、計畫、目 標、議題及風險;(2)實現他們的承諾;(3)界定、 追蹤及解決協同作業之議題。 由組織標準流程裁適而來之整合及調適的流程,稱為 專案已調適流程。 專案工作量、成本、時程、人員、風險及其他因素的 管理,與專案已調適流程的工作項目息息相關。專案 已調適流程的實施與管理,通常描述於專案計畫中, 而某些活動可能包含於影響專案的其他子計畫,諸如 品質保證計畫、風險管理策略及建構管理計畫。 既然每個專案的已調適流程均從組織標準流程裁適而 來,專案間的相異性通常會減少,且專案可以更容易 分享流程資產、資料及學習心得。 此流程領域同時也規範與專案相關的所有活動之 協調,舉例如下: • 發展活動,例如:需求發展、設計及驗證 • 服務活動(例如,交付、服務台、操作及客戶聯 絡) • 採購活動(例如,招標、協議監控及操作移轉) • 支援活動(例如:建構管理、文件、行銷及訓練) 規劃與管理專案內部或外部相關關鍵人員間的工作介 面與互動,以確保整體專案的品質與產品的完整性。 在定義專案已調適流程與專案計畫時,相關關鍵人員 可適當參與。 為確保能適度關注協調的問題,與確保專案所有參與 人員均能適切瞭解專案現況、計畫與活動,專案需經 常性的與相關關鍵人員審查與交流 (相關關鍵人員的 整合的專案管理 239 適用於服務的能力成熟度整合模式 1.2 版 定義,請參考詞彙)。在定義專案已調適流程時,視 需要建立正式工作介面,以確保適當的協調與合作。 本流程領域適用於任何組織架構,包括如線性組織、 矩陣組織或整合團隊。此術語應該在現有的組織架構 中合理地闡釋。 相關流程領域 服務系統發展補充資料 有關呈現同儕檢視,請參考服務系統發展流程領域, 以獲得更多資訊。 有關特別說明度量與分析程序,請參考度量與分析流 程領域,以獲得更多資訊。 有關組織流程資產及工作環境標準,請參考組織流程 定義流程領域,以獲得更多資訊。 有關監控專案,請參考專案監控流程領域,以獲得更 多資訊。 有關建立專案計畫及規劃關鍵人員的參與,請參見專 案規劃流程領域,以獲得更多資訊。 特定目標及執行方法摘要 SG 1 使用專案的已調適流程 SP 1.1 建立專案的已調適流程 SP 1.2 使用組織流程資產規劃專案活動 SP 1.3 建立專案工作環境 SP 1.4 整合計畫 240 整合的專案管理 SP 1.5 使用整合計畫管理專案 SP1.6 建立整合團隊 SP 1.7 貢獻組織流程資產 SG 2 與相關關鍵人員協調合作 SP 2.1 管理關鍵人員參與 SP 2.2 管理相互依存關係 SP 2.3 解決協調議題 各目標的特定執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 SG 1 使用專案的已調適流程 專案之執行係依據組織標準流程所調適的流程 專案已調適流程必須包含相關之組織標準流程,該標 準流程說明採購、發展、維護或交付產品所需的所有 流程。 SP 1.1 建立專案的已調適流程 建立並維護從專案啟動到專案全壽期的已調適流程。 有關組織流程資產館,請參考組織流程定義流程領 域,以獲得更多資訊。 有關組織流程需求與目標,以及推展組織的標準流程 至專案,請參考組織流程專注流程領域,以獲得更多 資訊。 專案已調適流程由經過調適的流程所組成,提供專案 形成一個整合的、連貫的生命週期。 專案之已調適流程將採購者活動與供應商交付項目 (界定於供應商協議中)合理的加以排序,以交付符 整合的專案管理 241 適用於服務的能力成熟度整合模式 1.2 版 合需求的產品。採購者可要求供應商針對選定的流程 加以調整,以符合採購者已調適之流程。 專案已調適流程應該滿足專案的合約需求、操作需 要、機會及限制,其設計是要提供最適合專案的需 求。專案已調適流程以下列要素為基礎: • 關鍵人員需求 • 承諾 • 組織流程需求與目標 • 組織標準流程及調適指引 • 操作環境 • 商業環境 • 服務交付環境 此外,專案已調適流程的描述應該依據專案將交付的 服務,包括已客製化的標準服務及專案獨有的服務。 在專案起始時就建立專案的已調適流程,有助於確保 專案成員及關鍵人員執行一套有效建立專案初步需求 和計畫所需的活動。隨著專案進行,專案已調適流程 會更詳細說明並修訂,以更能符合專案需求、組織流 程需要及目標。且當組織標準流程改變時,專案已調 適流程可能需要隨著修訂。 典型的工作產品 1. 專案已調適流程 細部執行方法 1. 從組織流程資產中,挑選一個生命週期模式。 242 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 會影響生命週期模式選擇的專案特性,舉例如 下: • 專案大小 • 專案策略 • 人員執行流程的經驗及熟悉程度 • 週期時間及可接受的缺失等級等限制 2. 從組織標準流程,挑選最適合專案需要的標準流 程。 3. 依據調適準則,從組織的標準流程及其他的流程 資產中,調適成為專案的已調適流程 有時候,現存的生命週期模式與標準流程無法滿足 專案需要,有時專案無法產出所需的工作產品或 度量。當上述情形發生時,專案需獲核准,以其 他非組織要求的方式進行,此即豁免的目的 4. 適當的使用組織流程資產館的其他成果。 其他成果可能包括如下事項: • 學習心得文件 • 樣板 • 範例文件 • 估計模式 5. 記錄專案的已調適流程。 專案已調適的流程包括所有專案的服務建立與交 付活動,及其相關關鍵人員的介面。 整合的專案管理 243 適用於服務的能力成熟度整合模式 1.2 版 專案活動的例子如下: • 專案規劃 • 專案監督 • 需求管理 • 供應商管理 • 偶發事件管理 • 品質保證 • 風險管理 • 決策分析及解決方案 • 服務系統發展及支援 6. 對專案已調適流程,進行同仁審查。 服務系統發展補充資料 有關呈現同儕檢視,請參考服務系統發展流程領 域,以獲得更多的資訊。 7. 必要時,修訂專案的已調適流程。 SP 1.2 使用組織流程資產規劃專案活動 使用組織流程資產與度量儲存庫來估計及規劃專案活 動。 有關組織流程資產與組織度量儲存庫,請參考組織流 程定義流程領域,以獲得更多資訊。 典型的工作產品 1. 專案的估計值 2. 專案計畫 244 整合的專案管理 細部執行方式 關於適用於服務的能力成熟度整合模式 1.2 版 1. 以專案已調適流程的工作項目與工作產品為基礎, 進行估計及規劃活動。 瞭解專案已調適流程之工作項目與工作產品關連 性,以及瞭解關鍵人員所扮演的角色,是發展切 合實際計畫的基礎。 2. 使用組織度量儲存庫來估計專案的規劃參數。 估計通常包含下列事項: • 來自本專案或類似專案之適當歷史資料 • 現行專案與其歷史資料將被引用之專案,二者 間相似與差異處。 • 針對歷史資料進行獨立確認 • 歷史資料選擇的原因、假設及理由 被認為相似與差異的參數的例子如下: • 工作產品與工作屬性 • 應用領域 • 服務系統和服務系統組件 • 操作或交付環境 • 人員的經驗 整合的專案管理 245 適用於服務的能力成熟度整合模式 1.2 版 涵括在組織度量儲存庫的資料的例子如下: • 工作產品的大小或其他工作產品的屬性 • 工作量 • 成本 • 時程 • 成員 • 品質 • 回應時間 • 服務能力 • 供應商績效 SP 1.3 建立專案工作環境 根據組織工作環境標準,建立與維護專案的工作環 境。 專案的適當工作環境包括設施、工具與設備的基礎建 設,供成員有效執行工作,以支援企業與專案目標。工 作環境及其組件需維持在組織工作環境標準中所指定之 績效與可靠度水準。當需要時,專案的工作環境或部分 組件可由內部自行發展或購自外部的供應商。 專案的工作環境應該包含所有專案運作的工作空間。 工作環境包括不在組織擁有或直接管制的空間(例 如,在客戶端交付一個產品或服務)。 服務系統發展補充資料 服務系統的驗證與確認可以包括交付服務的工作環境 的起始與持續的評估。 246 整合的專案管理 服務系統發展補充資料 關於適用於服務的能力成熟度整合模式 1.2 版 關於準備驗證與確認,請參考服務系統發展流程領 域,以獲得更多資料。 有關與工作環境相關的標準,請參考組織流程定義流 程領域之建立工作環境標準特定執行方法,以獲得更 多資訊。 典型的工作產品 1. 專案的設備及工具 2. 專案工作環境的安裝、營運及維護手冊 3. 使用者調查與結果 4. 使用、績效及維護紀錄 5. 專案工作環境的支援服務 細部執行方法 1. 規劃、設計及安裝專案的工作環境 專案工作環境與其他產品一樣,其關鍵為需求導 向,故需比照其他產品發展的嚴格度探索工作環 境的功能性及操作性。 整合的專案管理 247 適用於服務的能力成熟度整合模式 1.2 版 工作環境之效率、成本及風險間可能須取捨,各 別舉例如下: • 效率可能包括及時溝通、安全、保密及可維護 性。 • 成本可能包括資本費用、教育訓練及支援架 構、現有環境的拆卸及處置,以及環境的營運 及維護。 • 風險可能包括對工作流程及專案所造成的干 擾。 設備及工具,舉例如下: • 辦公軟體 • 決策支援軟體 • 專案管理工具 • 需求管理工具 • 事故與需求管理工具 • 測試及評估設備 2. 對專案工作環境提供持續的維護及操作支援。 工作環境的維護與支援可以用組織內部能力或外 聘來達成。 維護及支援方法舉例如下: • 聘用人員來執行維護及支援 • 訓練人員來執行維護及支援 • 維護及支援外包 • 對所選用工具,培養使用專家 3. 維持專案工作環境構成組件的資格 248 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 組件包括軟體、資料庫、硬體、工具、測試設 備,以及適當的文件。軟體資格包括適當的檢 定,硬體及測試設備資格則包括校準與調校紀錄 以及校準標準的可追溯性。 4. 對工作環境是否符合專案需求及支援協同作業,加 以定期審查並適時採取行動。 可能需採取的行動,舉例如下: • 加入新的工具 • 要求額外的網路、裝備、訓練及支援 SP 1.4 整合計畫 整合專案計畫,以及其他會對描述專案已調適流程造 成影響的計畫。 有關建立專案計畫,請參考專案規劃流程領域,以獲 得更多資訊。 專案計畫應包括服務系統發展計畫及服務交付,若適 當。 有關準備能力與可利用度管理,請參考能力與可利用 度管理流程領域,以獲得更多資訊。 有關準備偶發事故解決方案預防,請參考偶發事故解 決方案與預防流程領域,以獲得更多資訊。 有關建立服務持續計畫,請參考服務持續流程領域, 以獲得更多資訊。 有關整合度量與分析活動,請參考度量與分析流程領 域,以獲得更多資訊。 整合的專案管理 249 適用於服務的能力成熟度整合模式 1.2 版 有關組織流程資產及,特別是組織度量儲存庫,請參 考組織流程定義流程領域,以獲得更多資訊。 有關界定與分析風險,請參考風險管理流程領域,以 獲得更多資訊。 本特定執行方法延伸了建立及維護專案計畫的特定執 行方法,以說明額外的規劃活動,例如納入專案已調 適流程、與相關關鍵人員協調、使用專案流程資產、 納入同仁審查計畫,以及建立工作目標性的允入及允 出準則。 專案計畫的發展應適當說明組織、客戶、供應商及最 終使用者之當前和期望的需要、目標與需求。 典型工作產品 1. 整合計畫 細部執行方法 1. 整合其他影響專案的計畫 影響專案計畫的其他計畫可能包括: • 品質保證計畫 • 風險管理策略 • 溝通計畫 • 能力與可利用度管理策略 • 服務持續計畫 • 偶發事件管理方法 250 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 2. 將用來管理專案的度量定義與度量活動,納入專 案計畫。 納入的度量的例子如下: • 組織的一般度量組 • 額外的專案特定的度量 3. 界定並分析產品與專案介面的風險。 產品與專案介面風險的例子如下: • 不完整的介面描述 • 工具或測試裝備無法提供 • 成本組件無法提供 • 不適合或無效的團隊介面 • 不適合的產品及服務介面 4. 安排工作順序時,考慮關鍵性發展因素與專案風 險。 時程安排時的考量因素,舉例如下: • 工作項目的規模大小與複雜度 • 整合與測試議題 • 關鍵資源的可用性 • 關鍵人物的可用性 5. 將對工作產品執行同仁審查的已調適流程,納入計 畫。 整合的專案管理 251 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充資料 有關呈現同儕檢視,請參考服務系統發展流程領 域,以獲得更多資訊。 6. 在專案的訓練計畫中,納入執行專案已調適流程所 需的訓練。 這個工作典型地包括與組織的訓練團隊協調他們 將提供的支援。 7. 建立客觀的允入與允出準則,以授權分工結構圖 所描述之工作的啟動與完成。 有關建立一個高層的分工結構圖,請參考專案規 劃流程領域,以獲得更多的資訊。 8. 確保專案計畫與相關關鍵人員的計畫相容。 一般而言,對計畫的規劃與修改將針對相容性加 以檢視。 9. 界定如何解決相關關鍵人員之間的衝突。 SP 1.5 使用整合計畫管理專案 使用專案計畫、影響專案的其他計畫及專案已調適流 程來管理專案。 有關組織流程資產,請參考組織流程定義流程領域, 以獲得更多資訊。 有關組織流程需求、導入組織流程資產及導入標準流 程,請參考組織流程專注流程領域,以獲得更多資 訊。 有關監控專案是否符合計畫,請參考專案監督與管制 流程領域,以獲得更多資訊 252 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 有關界定、分析與減輕風險,請參考風險管理流程領 域,以獲得更多資訊。 典型的工作產品 1. 執行專案已調適流程所產生的工作產品 2. 已蒐集的度量(亦即,實際的)與進度紀錄或報告 3. 已修訂的需求、計畫及承諾 4. 整合計畫 細部執行方法 1. 使用組織流程資產館,實施專案已調適流程。 這項工作通常包括下列活動: • 從組織流程資產館,將合適的成果納入專案 • 使用自組織流程資產館中的學習心得來管理專 案 2. 使用專案已調適流程、專案計畫及影響專案的其 他計畫來監控專案的活動和工作產品。 這項工作通常包括下列活動: • 利用已定義的允入與允出準則來授權工作的啟 動,與決定工作的完成 • 監控對專案的規劃參數有重大影響的活動 • 使用將引發調查和適當行動的度量門檻,來追 蹤專案的規劃參數 • 監控產品與專案介面的風險 • 根據專案已調適流程之工作項目與工作產品的 相關計畫為基礎,管理外部與內部承諾 整合的專案管理 253 適用於服務的能力成熟度整合模式 1.2 版 瞭解專案已調適流程中不同工作項目與工作產品 間的關係、關鍵人員所扮演的角色,以及完整定 義的控制機制(例如:同仁審查),可提高專案績效 透明度,及達成較佳的專案控管。 3. 取得並分析所選擇的度量資料,以管理專案與支 援組織的需求。 有關如何取得與分析度量,請參考度量與分析流 程領域,以獲得更多資訊。 4. 定期與適度的審查並調整專案績效,以符合組織、 客戶及最終使用者之當前和期望的需要、目標及 需求。 這項審查包括組織流程需要與目標的調整。 達成調整的措施,舉例如下: • 加速時程,並對其他的規劃參數與專案風險, 作適當的調整 • 改變需求,以反應市場機會或客戶與最終使用 者需求的變更 • 終止專案 SP 1.6 建立整合團隊 建立與維護整合團隊 專案利用整合的團隊來管理,該團隊需能體現組織對 團隊架構及組成之規範與指引。專案的共同願景需在 建立團隊架構前就完成,而團隊架構則可根據 WBS 來建立。對小型的採購組織而言,組織內所有成員以 及相關的外部關鍵人員,可被視為一個整合團隊。 有關建立與維護組織對整合團隊的架構、成立與運作 的規則與指引,請參考組織流程定義流程領域之建立 254 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 整合團隊規範與指引之特殊執行方法,以獲得更多資 訊。 確保相關關鍵人員協調合作的最佳方法之一,是將他 們納入整合團隊。 一個專案可能沒有整合團隊(例如,一個專案只有一 個人,在這種情形下,這一個人可能是較高層整合團 隊的一員),一個整合團隊(也就是整體專案團隊就 是整合團隊),或很多整合團隊。這個特殊執行方式 可能應用在前2個案例以及最後一個案例。建立一個 整合團隊是最好的執行方式,當團隊成員有互補的技 術套組或從不同的文化背景必須一起有效率地工作以 完成一個共同的目標。很重要的是決定在組織層級, 專案工作必須以整合團隊執行。 當一個專案是一個服務供應商,可能只有一個整合團 隊負責整體的服務發展與維護,而另一組人負責服務 遞送。以不同的重要服務為例,每一項都需要不同的 技能,配合每一個服務的員工可能要依照目標,建立 它自己的整合團隊,以確保服務成功及持續的交付 (或及時地對專屬要求或偶發事故解決方案的回 應)。 在需要協調不同產品發展或服務交付組織的客戶環境 中,重要的是建立一個由會影響整體成功的各方代表 組成的整合團隊。如此的代表性協助確保跨組織有效 的合作,包括對協調議題的及時解決方案。 典型的工作產品 1. 所記錄的共同願景 2. 每一個整合團隊的隸屬成員清單 3. 整合團隊的規章 4. 整合團隊現況之定期狀態報告 整合的專案管理 255 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 建立與維護專案的共同願景 在建立共同願景時,瞭解專案與專案外部關鍵人 員之介面是重要的。願景應透過同意與承諾在相 關關鍵人員間分享。 2. 建立與維護整合團隊的架構 評估成本、時程、專案風險、資源、介面、專案 已調適流程及組織各項指引等因素,以為定義整 合團隊及其權責與關係奠定基礎。 3. 建立與維護每個整合團隊 建立與維護整合團隊涵蓋選擇團隊的領隊及成 員、建立各團隊的團隊規章,以及提供所需資源 以完成團隊被指派之工作。 4. 定期評估整合團隊的架構與組成 整合團隊需要被監測以發現是否有問題、管理不 當的介面,以及團隊成員被不當指派工作之情形 存在,當績效不符期望時,應採取矯正措施。 SP 1.7 貢獻組織流程資產 貢獻工作產品、度量及經驗紀錄予組織流程資產。 有關流程改善建議,請參考組織流程專注流程領域, 以獲得更多資訊。 有關組織流程資產、組織度量儲存庫及組織流程資產 館,請參考組織流程定義流程領域,以獲得更多資 訊。 本特定執行方法說明從專案已調適流程內之各個流程 蒐集資訊。 256 整合的專案管理 典型的工作產品 關於適用於服務的能力成熟度整合模式 1.2 版 1. 針對組織流程資產所提出的改善措施 2. 從專案所蒐集之實際的流程與產品度量 3. 文件(如示範的流程描述、計畫、訓練模組、檢查 表及學習心得) 4. 專案調適及執行組織標準流程的相關流程成果。 細部執行方法 1. 針對組織流程資產,提出改善方案。 2. 於組織度量儲存庫中,保存流程與產品度量資 料。 有關記錄規劃與重新規劃的資料,請參考專案規 劃流程領域,以獲得更多資訊。 有關記錄度量資料,請參考度量與分析流程領 域,以獲得更多資訊。 這些流程和產品度量通常包含如下: • 規劃資料 • 重規劃資料 • 度量 整合的專案管理 257 適用於服務的能力成熟度整合模式 1.2 版 依專案記錄的資料,舉例如下: • 工作描述 • 假設 • 預測 • 修改的預測 • 記錄資料與度量的定義 • 度量 • 與活動呈現與製作工作產品活動有關的度量的 詳細資料 • 重建預測、評估它們的合理性及自新工作衍生 的預測所需的附屬資料 3. 交付文件以將其納入組織的流程資產資料庫。 文件的例子如下: • 示範性的流程描述 • 訓練的模組 • 示範性的計畫 • 檢查清單 4. 從專案的經驗學習文件納入組織流程資產資料 庫。 5. 為支援組織流程監控活動,提供與調適及執行組織 標準流程相關的流程成果。 有關對新的及現行專案,瞭解其組織標準流程的 執行的活動,請參考組織流程專注流程領域的監 控特定執行方法的實施,以獲得更多資訊。 258 整合的專案管理 SG 2 與相關關鍵人員協調合作 進行專案與其相關關鍵人員的協調與合作 關於適用於服務的能力成熟度整合模式 1.2 版 SP 2.1 管理關鍵人員參與 管理相關的關鍵人員在專案的參與程度。 根據專案整合及已調適流程,管理相關關鍵人員的參 與。 供應商協議提供專案管理供應商參與程度之基礎。採 購者與關鍵組織(可能為產品或服務的提供者或接受 者)所共同制訂的供應商協議(如單位與公司內部協 議、諒解備忘錄、協議備忘錄),可能是產品或服務 供應商或接收者,提供其參與程度的基礎。這些協議 特別重要當專案交付的服務必須整合到較大的服務交 付內容時。 有關規劃關鍵人員的參與及獲得對專案的承諾,請參 考專案規劃流程領域以獲得更多的資訊。 典型的工作產品 1. 協同活動所需的議程與時程 2. 所記錄的議題 3. 對解決相關關鍵人員議題的建議 細部執行方法 1. 與相關關鍵人員協調合作,以決定誰應參與專案活 動 相關的關鍵人員應已界定在專案計畫中。 2. 確保為滿足承諾所產出的工作產品,能符合接收人 員的需求。 整合的專案管理 259 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充資料 有關驗證與確認服務系統,請參考服務系統發展 流程領域,以獲得更多資訊。 製作的工作產品以滿足承諾可以是服務。 工作通常包括下列: • 由相關的關鍵人員檢視、展示、或測試,若適 當,每一項製作的工作產品。 • 由其他接受工作產品的專案的代表檢視、展 示、或測試,每一項工作產品,若適當。 • 解決有關接受工作產品的議題。 3. 發展建議及協調行動以解決對需求誤解及問題。 SP 2.2 管理相互依存關係 與相關的關鍵人員共同界定、協商與追蹤重要的依存 關係。 典型的工作產品 1. 與相關的關鍵人員審查所產生的缺失、議題及行 動項目 2. 重要依存關係 3. 滿足重要依存關係的承諾 4. 重要依存關係的狀態 細部執行方法 1. 與相關的關鍵人員進行審查。 2. 界定每一重要依存關係。 260 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 3. 以專案的時程為基礎,建立每一重要依存關係的 必要天數與計畫天數。 4. 與產出、承接工作產品或產出、接受服務的人員 共同針對重要依存關係的履行承諾,進行審查並 取得協議。 5. 記錄重要依存關係與承諾。 承諾的文件典型包括: • 描述承諾 • 界定誰做的承諾 • 界定誰負責滿足承諾 • 當承諾被滿足時,特別說明 • 特別說明決定承諾已經被滿足的準則 6. 追蹤重要的依存關係與承諾,並採取適當的矯正 措施。 有關監督承諾,請參考專案監督與管制流程領 域,以獲得更多資訊。 追蹤重要的依存關係通常包括下列事項: • 評估延遲與提早完成的影響,以決定對未來活 動及里程碑的衝擊 • 盡可能與負責的一方解決實際與潛在的問題 • 將負責人員未解決之實際與潛在的問題,提昇 至適當的管理階層 SP 2.3 解決協調議題 與相關的關鍵人員解決議題。 整合的專案管理 261 適用於服務的能力成熟度整合模式 1.2 版 協調之議題,舉例如下: • 遲來的重要依存關係與承諾 • 服務系統需求及設計缺失 • 產品層級的問題 • 無法取得關鍵的資源或人員 典型的工作產品 1. 相關關鍵人員的協調議題 2. 相關關鍵人員的協調議題現況 細部執行方法 1. 界定與記錄議題。 2. 與相關關鍵人員溝通議題 3. 與相關關鍵人員解決議題 4. 將相關關鍵人員無法解決的議題,提報至適當的管 理者 5. 追蹤議題到結案 6. 與相關關鍵人員溝通議題的現況與解決狀況 262 整合的專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 事故解決方案與預防 成熟度第三級的服務建立與交付流程領域 目的 事故解決方案與預防(IRP)的目的是適當地確保及時與 有效的服務事故解決方案與服務事故預防。 簡介 事故解決方案與預防流程領域包含下列活動: • 界定與分析服務事故 • 啟動特定的行動解決事故 • 監督事故的狀態、追踪事故狀態的進展、以及視需 要升級 • 界定與分析事故的潛在原因 • 界定使服務持續的權宜之計 • 啟動特定的行動以解決事故的潛在原因或提供權宜 之計 • 溝通事故狀態相關的關鍵人員 • 與相關的關鍵人員確認完成事故解決方案 「事故」一詞在此流程領域通常指「服務事故」,而 在模式的其他領域,其內容使其意義更明顯。「服務 事故」一詞使用在詞彙中以及其模式的其他部份,與 日常使用的「事故」一詞特別不同地定義。(參考詞 彙中「服務事故」的定義。) 事故解決方案與預防 263 適用於服務的能力成熟度整合模式 1.2 版 事故是指如果不解決最終可能造成服務提供者組織破 壞服務承諾的事件。因此,服務提供者組織必須根據 服務協議的條款,及時及有效地解決事故。 解決事故可以包含下列活動: • 移除潛在原因或原因 • 減少事故的衝擊 • 監督造成事故的情形或一連串的事件 • 提供權宜之計 事故可以是服務中斷或潛在中斷的原因或指標。 中斷服務的例子包括軟體應用系統在正常運作時間中 斷、電梯困住、重複訂旅館房間及行李在機場遺失 等。 服務潛在的中斷包括回復的裝備中有損壞組件、超級 市場的結帳隊伍超過3個人,以及一個人員不足的客 服中心。 客戶抱怨是潛在中斷的特別型態。一個抱怨是指客戶 意識到服務不能滿足他或她的期望,甚至客戶對於協 議的要求有誤。因此,抱怨應該以事故處理,且涵括 在事故解決方案與預防流程領域的範圍中。 所有的事故有一個或多個潛在原因,故且不論服務提 供者是否瞭解該原因。例如,每一個系統的中斷都有 潛在原因,不論是記憶體漏電、資料庫有缺陷或操作 員錯誤。 事故的潛在原因是一種情形或事件,造成一個或多個 事故發生。並不是所有的潛在原因都會立即造成事 故。例如,一個很少使用的系統零件的缺失可能很長 的時間不會造成事故。 264 事故解決方案與預防 潛在原因可能如下列: 關於適用於服務的能力成熟度整合模式 1.2 版 • 在服務提供者控制中的根本原因,可以且應該 被移除 • 正面或負面的服務情形,可能或可能不被移除 • 服務提供者不能變更的情形(例如:天氣條 件) 潛在原因與根本原因(如同在原因分析與解決方案流 程領域所描述)意義並不相同。一個根本原因是潛在 原因的一種,在某種情形下被認為是基本的。我們通 常不會尋找根本原因的原因,但當我們解決根本原因 時,我們通常期望大量減少事故的發生。 有時,因為實際與預算的原因,我們無法解決一個根 本原因,所以,我們可以著重在其他非根本的潛在原 因。移除所有潛在原因有時也不盡合理。在某些情形 下,解決事故與權宜之計或只是依照個別情形一件一 件地解決事故,可能更有效率。 事故解決方案的有效執行方法開始於與客戶、最終使 用者及其他報告事故的關鍵人員發展一個解決事故的 流程。組織可以收集已知的事故、事故的潛在原因與 權宜之計,以及分開但相關的活動,發展解決選定的 事故與潛在原因的行動。處理所有事故與分析選定的 事故及其潛在原因,以定義解決事故的方式,是二個 可同時或依序執行的強化活動。 因此,事故解決方案與預防流程領域有3個特定目 標。目標「準備事故解決方案與預防」協助確保建立 及時的事故解決方案與有效的事故預防。此目標的特 定執行方法「確認、控制及解決事故」是用來處理與 結束事故,通常應用權宜之計或在目標「定義解決選 定事故的方式」所定義的其他行動。 事故解決方案與預防 265 適用於服務的能力成熟度整合模式 1.2 版 相關流程領域 有關監督與分析能力與可用度,請參考容量與可用度 管理流程領域,以獲得更多的資訊。 有關建立與維護服務協議,請參考服務交付流程領 域,以獲得更多的資訊。 有關決定缺失與問題的原因,請參考原因分析與解決 方案流程領域,以獲得更多的資訊。 有關追踪與控制變更,請參考建構管理流程領域,以 獲得更多的資訊。 有關提供專案進度的瞭解,以在專案績效明顯地徧離 計畫時,採取適當的矯正行動,請參考專案監控流程 領域,以獲得更多的資訊。 有關界定、分析與減輕風險,請參考風險管理流程領 域,以獲得更多的資訊。 特定目標與執行方法摘要 SG1 準備事故解決方案與預防 SP 1.1 建立事故解決方案與預防的方式 SP 1.2 建立事故管理系統 SG 2 界定、控制與解決事故 SP 2.1 界定與記錄事故 SP 2.2 分析事故資料 SP 2.3 對選定的事故提供權宜之計 SP 2.4 解決選定事故的潛在原因 SP 2.5 監督事故的狀態到結案 SP 2.6 溝通事故的狀態 SG 3 定義解決選定事故的方式 SP 3.1 分析選定事故的資料 SP3.2 規劃解決選定事故潛在原因的行動 SP 3.3 建立選定事故的權宜之計 266 事故解決方案與預防 各目標的特定執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 SG 1 準備事故解決方案與預防 執行事故解決方案與預防的準備工作。 建立與維護確保及時與有效的事故解決方案與預防的 方式,以確保符合服務協議的條款。 SP 1.1 建立事故解決方案與預防的方式 建立與維護事故解決方案與預防的方式。 事故解決方案與預防的方式描述組織功能涉及事故解 決方案與預防、執行的程序、使用的支援工具及指派 在事故生命週期間的責任。這類的方式通常需予文件 化。 通常,在服務交付開始前定義完整解決事故所需的時 間量,並記錄在服務協議中。 在很多服務領域,事故解決方案及預防的方式包括一 項功能叫:「詢問台」、 「服務台」或其他的名字。 這項功能通常是與客戶溝通的一種方式,可以接受事 故、採取權宜之計及解決事故。然而,這個功能不是 出現在所有服務領域。此外,其他的功能群組也適當 地固定解決事故。 有關建立與維護服務協議,請參考服務交付流程領 域,以獲得更多的資訊。 典型的工作產品 1. 事故管理方式 2. 事故準則 事故解決方案與預防 267 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 定義事故的決定準則。 為了能界定有效的事故,必須定義準則使服務提 供者決定什麼是及什麼不是事故。通常,準則也 會定義事故嚴重程度及優先順序的不同。 2. 定義事故的類別及決定事故所屬類別的準則。 事故解決方案藉由建立一套類別、嚴重程度及其 他指定事故型態的準則來啟動。這些預先決定的 準則可以促使優先順序、指派及升級行動快速且 有效率。 適當的事故類別根據服務而有所不同。例如,資 訊技術相關的安全事故類別,可以包括下列: • 內部或外部系統的探測或掃描(例如,網路、 網頁應用、郵件伺服器) • 行政或特權存取帳號、應用系統、伺服器網路 等 • 對服務攻擊、網頁損壞、惡意編碼(例如病 毒)等的公布否認 • 內部攻擊或其他資源錯誤使用(例如,密碼共 用) • 遺失個人的辨認資料 必須有準則使服務人員快速且簡單地界定主要的 事故。 事故的嚴重程度方式例如下: • 重要、高、中、低 • 數字化的等級(例如,1-5,1 代表最高) 268 事故解決方案與預防 關於適用於服務的能力成熟度整合模式 1.2 版 3. 描述處理事故指派及轉換的責任。 描述可以包括下列: • 誰負責解決事故的潛在原因 • 誰負責監督及追踪事故狀態 • 誰負責追踪事故相關的行動進度 • 升級程序 • 所有被指派與轉換元素的責任如何 4. 界定一個或多個客戶及最終使用者可以用來報告 事故的機制。 這些機制可以計算群組與個人如何能報告事故。 5. 定義事故管理使用的方法及安全工具。 6. 描述如何通知所有可能受報告的事故影響的相關 客戶及最終使用者。 如何與客戶及最終使用者溝通通常記錄在服務協 議中。 7. 基於嚴重程度及優先順序等級,定義決定嚴重程 度與優先順序等級及行動類別及採取的回應的準 則。 基於嚴重程度及優先順序等級回應的例子包括立 即的短期行動、再訓練或文件更新、稍後回應 等。 8. 在服務協議中界定定義事故解決方案的時間量的 需求。 通常,解決事故所需的最少與最多的時間量會在 服務交付開始之前,定義並記錄在服務協議中。 事故解決方案與預防 269 適用於服務的能力成熟度整合模式 1.2 版 有關建立與維護服務協議,請參考服務交付流程 領域,以獲得更多的資訊。 9. 記錄定義事故應該結束時的準則。 不是所有的事故潛在原因都被解決,也不是所有 事故都有權宜之計。事故直到符合文件化的準則 後才會結束。 通常結案代碼被用來分類每一個事故。當這些代 碼資料被進一步分析時是有用的。 SP 1.2 建立事故管理系統 建立與維護事故管理系統以處理及追踪事故資訊。 事故管理系統包括儲存的媒介、程序及存取事故管理 系統的工具。這些儲存媒介、程序與工具可能是自動 化的,但不一定要自動化。例如,儲存媒體可能是一 個儲存文件的檔案系統。程序可能被記錄在紙本,而 工具可能是手用工具或不需自動化協助即可以完成工 作的器材。 歷史資料的收集包括已解決的事故、事故的潛在原 因、解決事故的已知方式,以及必須用來支援事故管 理的權宜之計。 典型的工作產品 1. 事故管理系統具有控制的工作產品 2. 事故管理系統的存取控制程序 細部執行方法 1. 確保事故管理系統允許事故在群組內的升級與轉 換。 事故可以在不同群組間轉換或升級,因為進入事 故的群組可能不是最適合採取行動解決它。 270 事故解決方案與預防 關於適用於服務的能力成熟度整合模式 1.2 版 2. 確保事故管理系統允許儲存、更新、存取及報告 對事故解決方案與預防有用的資訊。 事故管理系統的例子如下: • 客戶抱怨及解決方案的索引實體檔案 • 錯誤或議題追踪軟體 • 服務台軟體 3. 維護事故管理系統及其內容的整體性。 維護事故管理系統及其內容的整體性的例子如 下: • 備份及儲存事故檔案 • 歸檔事故檔案 • 修復事故錯誤中 • 維護預防未經授權存取的安全 4. 視需要維護事故管理系統。 SG 2 界定、控制與解決事故 界定、控制與解決事故。 這個執行方法涵括這個目標,包括與報告事故的人及 被事故影響的人互動。資料的處理與追踪發生在執行 方法間,直到事故被解決與結束。 事故的處理包括收集與分析資料以尋找潛在的事故或 簡單的等待最終使用者或客户報告事故。 這個目標的特定執行方法也可以依賴定義解決選定事 故的方式這個目標的執行方法。它通常是這個目標中 事故解決方案與預防 271 適用於服務的能力成熟度整合模式 1.2 版 的執行方法的個案,用來定義解決選定事故的方式, 如界定、控制與解決事故目標的要求。 通常,事故包含納入建構管理的工作產品。 有關追踪與控制變更,請參考建構管理流程領域,以 獲得更多的資訊。 SP 2.1 界定與記錄事故 界定事故並記錄有關的資訊。 能力、績效或可用度議題通常是潛在事故的訊號。 有關監督與分析能力與可用度,請參考容量與可用度 管理流程領域,以獲得更多的資訊。 典型的工作產品 1. 事故管理紀錄 細部執行方法 1. 界定事故在範圍內。 如何界定事故的例子如下: • 客戶以電話報告的事故到服務台 • 最終使用者以網頁格式報告事故 • 自動偵測系統偵測到事故 • 在資料收集時,異常的分析所獲得的事故 • 監督與分析外部資料來源(例如,RSS提 供、新服務及網站) 2. 記錄有關事故的資訊。 272 事故解決方案與預防 關於適用於服務的能力成熟度整合模式 1.2 版 當記錄一個事故的資訊時,記錄足夠的資訊以適 當地支援分析與解決方案活動。 記錄事故資訊的例子,如下: • 通報事故人員的姓名與聯絡資訊 • 事故的描述 • 事故所屬的類別 • 報告事故發生的日期與時間及報告的日期與時 間 • 事故包含的建構項目 • 結案代碼及資訊 • 發生事故情形的相關特性。 3. 分類事故。 使用建立在事故解決方案與預防的方式的類別, 指定事故到事故管理系統的相關類別。與其他報 告事故的人溝通其狀態,以使服務提供者及早確 認事故資訊。 SP 2.2 分析事故資料 分析事故資料以決定最佳行動。 最佳行動可能是不做任何處理、以個案為基礎的方式 解決事故、對事故提供權宜之計、移除事故的潛在原 因、教育最終使用者、監督服務干擾的指標,或建立 危機計畫。 典型的工作產品 1. 主要的事故報告 2. 事故指派報告 事故解決方案與預防 273 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 分析事故資料。 對於已知的事故,這個分析可能只是選擇事故的 型態。對於主要的事故,可能需要組成分開的事 故解決方案小組以分析事故。 2. 決定哪一個小組最適合採取行動解決事故。 哪一個小組最適合採取行動解決事故可能有不同 的因素考量,包括事故的型態、有關的地點及嚴 重程度等。 處理不同事故型態的小組的例子如下: • 一個健康保健小組處理有害的醫療產出物。 • 一個網路支援小組處理網路連結事故。 • 一個詢問台處理密碼相關事故。 3. 決定解決事故必須採取的行動。 行動的例子如下: • 代替損壞的組件 • 訓練客戶、最終使用者或服務交付人員 • 釋出一項宣布(例如,公關稿、媒體回覆、公 布欄、對客戶或其他關鍵人員的通知) 4. 規劃要採取的行動。 SP 2.3 對選定的事故提供權宜之計 對選定的事故實施權宜之計。 採取權宜之計可以減少事故的衝擊。權宜之計可能取 代解決事故的潛在原因。或是,可以暫時使用權宜之 計直到事故的潛在原因可能被解決。 274 事故解決方案與預防 關於適用於服務的能力成熟度整合模式 1.2 版 建立一個單一的包括所有已知權宜之計的儲存庫是重 要的。這個儲存庫可以用來快速地決定相關事故可使 用的權宜之計。 典型的工作產品 1. 更新事故管理紀錄 細部執行方法 1. 解決事故使用權宜之計。 2. 管理行動直到事故的衝擊直到可接受的程度。 3 . 記錄行動與結果。 SP 2.4 解決選定事故的潛在原因 解決選定事故的潛在原因。 事故的潛在原因被界定與分析,及使用這目標中的特 定執行方法「定義解決選定事故的方式」產生行動提 議後,事故的潛在原因必須被解決。 建立一個單一的,包括所有已知事故、他們的潛在原 因及方式,以及解決其潛在原因的儲存庫是重要的。 這個儲存庫可以用來快速地決定相關事故的原因。 典型的工作產品 1. 更新的事故管理紀錄 細部執行方法 使用分析事故潛在原因所得到的結果,做成的行 動提議,解決潛在原因。 事故解決方案與預防 275 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充資料 有關維護服務系統,請參考服務交付流程領域, 以獲得更多的資訊。 2. 管理行動直到潛在原因被解決。 管理行動可能包括事故的升級。 升級的準則的例子包括下列: • 當事故對組織或客戶的衝擊是大的 • 當解決事故的潛在原因會花費相當多的時間或 精力 3. 記錄行動與結果。 用來解決事故或其潛在原因的行動,及那些方式 的結果被記錄在事故管理系統以支援在未來解決 類似的事故。 SP 2.5 監督事故的狀態到結案 監督事故的狀態到結案,並視需要升級。 整個事故的生命及事故的狀態必須記錄、追踪、視需 要升級與結案。 有關提供專案進度的瞭解,以在專案績效明顯地徧離 計畫時,採取適當的矯正行動,請參考專案監控流程 領域,以獲得更多的資訊。 典型的工作產品 1. 結束的事故管理紀錄 細部執行方法 1. 記錄行動與監督與追踪事故直到它們符合服務協 議的條款與滿足事故的提出者。 276 事故解決方案與預防 關於適用於服務的能力成熟度整合模式 1.2 版 事故應該在整個生命週期中被追踪與升級,若需 要,確保它的解決方案。監督對通報事故的回應 及事故如何被解決直到它符合客戶或組織的滿意 而解決。 2. 與相關的關鍵人員審查解決方案與確認結果。 確認潛在原因成功地被解決,可以包含與通報事 故的人確認,或其他參加分析事故,而實際採取 行動,使事故不再發生的人。部份解決事故的結 果可能是客戶滿意的程度。 現在,事故已被解決,它必須被確認,服務再次 符合服務協議的條款。 3. 結束符合結案準則的事故。 SP 2.6 溝通事故的狀態 溝通事故的狀態。 溝通是提供服務,特別是當事故發生時的一個重要因 素。與通報的人員以及可能受它影響的人溝通,應該 被認為在事故管理系統中的整個事故生命的紀錄。獲 得充分通知的最終使用者及客戶會更瞭解及對成功地 解決事故有幫助。 通常,行動的結果會被通報事故的人審查,以確認行 動的確解決了事故,而滿足了傳送者。 典型的工作產品 1. 與客戶及最終使用者的溝通紀錄 SG 3 定義解決選定事故的方式 定義被選定事故的解決方式,以避免未來事故發生或減輕它們 的衝擊。 所有的事故有一個或多個潛在原因造成其發生。解決 某些事故的潛在原因可以減少干擾服務的可能性或衝 事故解決方案與預防 277 適用於服務的能力成熟度整合模式 1.2 版 擊,減少服務提供者的工作量,或改善服務等級。這 個目標的執行方法包括分析事故,以定義如何解決它 們。分析的結果回饋給那些控制與解決事故的人。 潛在原因可以用來界定事故及可能的未來事故。 例如,分析交付錯誤或系統中斷的原因及監督軟體記 憶體的使用,以儘速偵測到記憶體的漏電。 事故的根本原因通常與立即的潛在原因不同。例如, 一個事故可能由系統錯誤的組件造成(潛在原因), 而事故的根本原因是次好的供應商選擇流程。這個流 程領域彈性地使用「潛在原因」一詞,範圍從立即的 原因或情形到較深的根本原因,以允許可能的回應範 圍從權宜之計到避免相關事故的層級。 有關決定缺失與問題的原因,請參考原因分析與解決 方案流程領域,以獲得更多的資訊。 SP 3.1 分析選定事故的資料 選擇與分析事故的潛在原因。 執行事故原因分析的目的是決定解決事故最好的行 動,以便它們不會再發生。可能的行動包括不解決潛 在原因與在它們發生時,持續處理或提供權宜之計。 通常,分析事故包含在建構管理之下的工作產品。 有關追踪與控制變更,請參考建構管理流程領域,以 獲得更多的資訊。 典型的工作產品 1. 報告事故的潛在原因 2. 記錄原因分析的活動 278 事故解決方案與預防 細部執行方法 1. 界定事故的潛在原因 關於適用於服務的能力成熟度整合模式 1.2 版 界定事故的潛在原因的方式,舉例如下: • 分析客戶報告服務台的事故 • 監督服務系統以界定潛在的事故 • 分析使用資源的趨勢 • 分析服務系統的優勢與弱點 • 分析服務系統失敗與可用度的平均時間 • 分析外部資源的資訊,例如,警告、新聞提供 與網站 有關界定、分析與減輕風險,請參考風險管理流 程領域,以獲得更多的資訊。 2. 記錄有關一個事故或一組事故的潛在原因。 當記錄有關一個事件的潛在原因,記錄足夠的資 訊以適當地支援原因的分析與解決方案。 記錄的資料,舉例如下: • 受影響或可能被潛在原因影響的事故 • 有關的建構項目 • 事故發生或可能發生情形的相關特性 3. 與負責執行相關工作的人員共同執行原因分析。 對主要事故的潛在原因,分析可以包括建置一個 分開的小組去分析潛在原因。 有關決定缺失與問題的原因,請參考原因分析與 解決方案流程領域,以獲得更多的資訊。 事故解決方案與預防 279 適用於服務的能力成熟度整合模式 1.2 版 SP 3.2 規劃解決選定事故潛在原因的行動 界定選定事故的潛在原因,並建立行動建議以解決這 些原因。 在分析已決定事故的潛在原因後,如有的話規劃將採 取的行動。規劃包括決定誰、在何時及如何行動。所 有的資訊記錄在行動建議書中。行動建議書由那些採 取行動解決事故潛在原因的人員所使用。 典型的工作產品 1. 行動建議書 2. 已知解決事故潛在原因方式收集的貢獻 細部執行方法 1. 決定哪組最適合解決潛在原因。 哪組最適合解決潛在原因,可能決定於潛在原因 的型態、納入的建構項目與相關事故的嚴重性。 處理不同型態的潛在原因之群組與部門,舉例如 下: • 一個網路支援小組處理網絡議題。 • 一個UNIX支援小組處理伺服器建構議題。 • 人力資源控制人員與隱私議題。 • 法務部門控制智慧財產權、資訊公開、資料遺 失等相關議題。 • 公共關係負責組織聲譽相關議題。 2. 決定解決潛在原因採取的行動。 當分析標準事故,解決標準事故的行動可以記錄 為標準行動計畫。如果不是標準的事故,一個已 解決事故與已知的錯誤的歷史收集資料,可以搜 280 事故解決方案與預防 關於適用於服務的能力成熟度整合模式 1.2 版 尋是否與其他事故相關。應維護這資料,以允許 這類的分析,而節省時間及提高工作價值。 解決潛在原因所採取的行動,舉例如下: • 替換損壞的組件 • 訓練最終使用者或服務交付人員 • 修復軟體缺失 • 不解決潛在原因,因為處理此事故比起解決其 潛在原因,較便宜或較低風險。 有關分析可能的決策,使用已建立的準則評估界 定的替代方案的正式評估流程,請參考決策分析 與解決方案流程領域,以獲得更多的資訊。 3. 記錄將採取的行動於行動建議書中。 4. 驗證與確認行動建議書以確保有效地解決事故。 5. 溝通行動建議書相關的關鍵人員。 SP 3.3 建立選定事故的權宜之計 建立與維護選定事故的權宜之計。 權宜之計是重要的機制使服務即使在發生事故時也能 持續。因此,在它用來與客戶及最終使用者解決事故 之前,記錄與確認權宜之計的有效性,是重要的。 典型的工作產品 1. 權宜之計的說明與指示 2. 對事故權宜之計收集的貢獻 細部執行方法 1. 決定哪組最適合建立與維護權宜之計。 事故解決方案與預防 281 適用於服務的能力成熟度整合模式 1.2 版 決定哪組最適合定義權宜之計、描述步驟與適當 地溝通資訊。 2. 規劃與記錄權宜之計。 3. 驗證與確認權宜之計以確保它有效地解決事故。 4. 溝通權宜之計相關的關鍵人員。 282 事故解決方案與預防 關於適用於服務的能力成熟度整合模式 1.2 版 度量與分析 成熟度第二級的支援類流程領域 目的 度量與分析(Measurement and Analysis, MA)的目的在 發展與維持度量能力,以支援管理之資訊需求。 簡介 度量與分析 度量與分析流程領域包括下列活動: • 指定度量與分析的目標,使其配合已界定的資訊 需求與目標 • 指定度量、分析技術、資料蒐集、資料儲存以及 報告與回饋機制 • 執行資料的蒐集、儲存、分析及報告 • 提供客觀的結果以做出有根據的決策,並採取適 當的矯正措施 將度量與分析活動整合到專案流程中,可支援下列活 動: • 客觀的規劃與估計 • 根據建立的計畫和目標,追蹤實際績效 • 界定與解決流程相關議題 • 提供將度量納入未來增訂流程的基礎 283 適用於服務的能力成熟度整合模式 1.2 版 執行度量功能的同仁,不一定需參與組織層面的計 畫。度量功能可以整合至個別專案,或其他的組織功 能(例如:品質保證)。 度量活動最初的重點是在專案,而度量功能在處理組 織面與企業面的資訊需求上,亦經證明確實有用。為 支援度量功能,度量活動應支援多層次的資訊需求, 包括業務、組織單位及專案及當組織成熟時,支援減 低重工。 專案可選擇在專案特定儲存庫中儲存專案的資料與結 果。當資料廣為各專案分享時,可存放於組織度量儲 存庫。 針對供應商提供的產品組件進行度量與分析,對有效 管理專案的品質與成本是必要的。經由謹慎的管理供 應商協議,可深入瞭解支援供應商績效分析的資料。 相關流程領域 服務系統發展補充資料 有關發展與分析關鍵人員需求,請參考服務系統發展 流程領域,以獲得更多資訊。 有關建立組織度量儲存庫,請參考組織流程定義流程 領域,以獲得更多資訊。 有關監督專案規劃參數,請參考專案監督與管控流程 領域,以獲得更多資訊。 有關建立預測資料,請參考專案規劃流程領域,以獲 得更多資訊。 284 度量與分析 關於適用於服務的能力成熟度整合模式 1.2 版 有關導入統計方式以瞭解差異性,請參考量化專案管 理流程領域,以獲得更多資訊。 特定目標及執行方法摘要 SG 1 安排度量與分析的活動 SP 1.1 建立度量目標 SP 1.2 指定度量 SP 1.3 指定資料蒐集與儲存程序 SP 1.4 指定分析程序 SG 2 提供度量結果 SP 2.1 取得度量資料 SP 2.2 分析度量資料 SP 2.3 儲存資料與結果 SP 2.4 溝通結果 各目標的特定執行方法 SG 1 安排度量與分析的活動 度量目標與活動要配合已界定的資訊需求與目標。 本目標的特定執行方法,可同時處理或依任意順序處理: • 建立度量目標時,專家經常先考量界定度量和分析程序的 必要準則,同時也會考量資料蒐集與儲存程序的限制。 • 在處理度量規格、資料蒐集或儲存等細節之前,先界定需 進行的必要分析,通常是重要的。 SP 1.1 建立度量目標 建立並維護度量目標,此度量目標衍生自已界定的資訊需求 與目標。 度量目標記錄完成度量與分析活動的目的,並界定基於資料 分析的結果,需要採取何種行動。度量目標也可以確認所期 望的行為的改變,做為執行度量與分析活動的結果。 度量與分析 285 適用於服務的能力成熟度整合模式 1.2 版 度量目標的來源可能是管理、技術、專案、產品及流程實施 的需要。 度量目標可能受限於現行的流程、可用的資源或其他的度量 考量。需要判斷投入度量工作的資源與度量結果的價值是否 相當。 度量與分析的過程及結果,將影響已界定的資訊需求與目標 的修改。 資訊需求與目標的來源,舉例如下: • 專案計畫 • 專案績效的監控 • 與管理人員和其他具有資訊需求的人員進行訪 談 • 已建立的管理目標 • 策略計畫 • 經營計畫 • 正式需求或合約義務 • 再發的或其他棘手的管理或技術問題 • 專案或組織實體的經驗 • 外部產業評比 • 流程改善計畫 • 再發的或其他棘手的事故 286 度量與分析 度量目標舉例如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 減少交付時間 • 減少生命週期總成本 • 完整交付指定功能 • 改善優先層級的品質 • 改善優先客戶滿意度評等 • 維護與改善採購者及供應商的關係 • 改善關鍵人員的參與層級 服務系統發展補充資料 有關發展與分析關鍵人員需求,請參考服務系統發展 流程領域,以獲得更多資訊。 有關監督專案規劃參數,請參考專案監督與管控流程 領域,以獲得更多資訊。 有關建立預測資料,請參考專案規劃流程領域,以獲 得更多資訊。 有關維持需求和工作產品間的雙向直接可追溯性的相 關資訊需求,請參考需求管理流程領域,以獲得更多 資訊。 典型的工作產品 1. 度量目標 細部執行方法 1. 記錄資訊需求與目標。 度量與分析 287 適用於服務的能力成熟度整合模式 1.2 版 記錄資訊需求和目標以允許對接續的度量和分析 活動的追溯。 2. 排定資訊需求與目標的優先順序。 它不可能也不需要將所有在一開始確認的資訊需 求放到度量和分析。應在可利用資源的限制中, 設定優先順序。 3. 記錄、審查及更新度量目標。 仔細考量度量與分析的目的與預期的用途。 記錄度量目標,並交由管理人員和其他相關的關 鍵人員審查,必要時並予更新,使得接續的度量 與分析活動可以追溯,並幫助確保分析活動可適 當的說明資訊需求與目標。 將使用者的度量和分析資料放到執行計畫的度量 目標和決定中是很重要的。它可能也適合加入那 些提供度量資料的人。 4. 必要時提供回饋,以調修和釐清資訊需求與目 標。 設定度量目標後可能需修訂和釐清界定的資訊需 求與目標。資訊需求的初始描述可能不清楚或模 糊。現存的需求和目標之間可能產生抵觸。對一 個已經存在的度量,要求精確的目標可能是不切 實際的。 5. 維持度量目標和指定的資訊需求與目標之間的可 溯性。 對於我們為什要度量這項?必需有個好答案。 當然,也可以改變度量目標,以反映不斷發展的 資訊需求與目標。 288 度量與分析 SP 1.2 指定度量 指定度量以說明度量的目標。 關於適用於服務的能力成熟度整合模式 1.2 版 將度量目標調修為精確的、可量化的度量。 度量包括基礎度量與衍生度量,基礎度量資料得自於 直接度量,衍生度量資料來自其他資料,通常結合多 個基礎度量而得。 一般使用的基礎度量例子如下: • 工作產品規模的預測與實際度量(例如頁數) • 人力與成本的預測與實際度量(例如人力時 數) • 品質度量(例如依照嚴重程度的缺失的數量) 一般使用的衍生度量的例子,如下: • 所獲得的價值 • 排定的績效指標 • 缺失的密度 • 同儕檢視的涵蓋度 • 測試或驗證的涵蓋度 • 可信度的度量(例如到失敗的指定時間) • 品質的度量(例如依照嚴重程度/總缺失數量 的缺失數量) 衍生度量通常以比例、混合指標或其他合計度量來表 示。衍生度量由基礎度量產生,通常比基礎度量更具 數量可信度和說明意義。 度量與分析 289 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 基礎與衍生度量規格 細部執行方法 1. 依據文件化的度量目標,界定可能的度量。 度量目標被調修為特定的度量,根據度量的名稱 和單位,將這些可能的度量予以分類。 2. 維護度量到度量目標的可追溯性。 確認在候選的度量中的相互關係,以促使資料確 認和候選的分析支援度量的目標。 3. 界定已經存在且可以說明度量目標的度量。 度量規格可能已經存在,或許早期為其他目的而 建立,或存在於組織的某處。 4. 指定度量的操作定義。 以精確和明白的方式陳述操作定義,有下列兩個 重要準則: • 可溝通:度量什麼?如何度量?度量的單位是 什麼?包括或排除什麼? • 可重複:在相同的定義下,度量是否可以重複 執行,且獲得相同的結果? 5. 將度量排序,並予以審查及更新。 請可能的最終使用者和其他相關的關鍵人員,對 所建議之度量規格的適當性進行審查。可設定或 改變排序,必要時可更新度量規格。 SP 1.3 指定資料蒐集與儲存程序 指定度量資料如何獲得與儲存。 290 度量與分析 關於適用於服務的能力成熟度整合模式 1.2 版 明確規範蒐集方法可確保適當的蒐集正確的資料,也幫助更 進一步釐清資訊需求和度量目標。 注意儲存和取用程序,可協助確保資料將來的可用性及可存 取性。 典型的工作產品 1. 資料蒐集與儲存程序 2. 資料蒐集工具 細部執行方法 1. 界定由目前工作成果、流程或交易產生的資料來源。 現有的資料來源在特定的度量時已被確認。合適的收集 機制可以存在,不管是否已收集適當的資料。 2. 界定目前沒有資料但需要的度量。 3. 為每一項需要的度量,指定資料蒐集與儲存的方法。 明確的描述資料如何蒐集、從何處蒐集及何時蒐集,並 描述蒐集有效資料的程序。資料以容易取得的方式儲存 以便於分析,有助於決定資料是否需再分析或撰寫文件 之用。 描述資料也可以說明其他有關被收集的度量的背景資訊 的因素(例如,度量的時間,資料的年限),以協助確 認稍後分析的資料。 度量與分析 291 適用於服務的能力成熟度整合模式 1.2 版 通常考量的問題包括如下: 是否已經決定資料蒐集的頻率,以及在流程中執行度量 的時點? 是否已經建立將度量結果自資料蒐集處轉移到資料儲存 庫、其他資料庫或最終使用者處所的時序? 誰負責取得資料? 誰負責資料儲存、取得及安全維護? 是否已發展或取得必要之支援工具? 4. 建立資料蒐集的機制與流程指引。 資料蒐集與儲存的機制需與其他一般工作流程整合。資 料蒐集的機制可以包括人工或自動的表格與樣板。負責 這項工作的人員,提供清楚簡明的指引以正確執行工 作。視需要提供訓練,說明蒐集資料的必要流程,以便 蒐集完整與正確的資料,並減輕負責提供和記錄資料人 員的負擔。 5. 適當且可行時,支援資料蒐集自動化。 自動化的支援可以協助收集較完整及正確的資料 這類自動化支援的例子如下: • 時間印記活動紀錄 • 靜態或動態的人工資料分析 然而,有些資料的收集不能沒有人工的介入(例如, 客戶的滿意度,其他的人力判斷)以及其他建置自動 化所需的基礎建設可能花費較高的部分。 292 度量與分析 關於適用於服務的能力成熟度整合模式 1.2 版 6. 訂定順序、檢視及更新資料收集與儲存程序。 資料蒐集與儲存程序的適當性與可行性,必須經過負 責提供、蒐集及儲存資料人員的審查,他們對於如何 改進現行的流程或建議其他有用的度量和分析具備洞 察力。 7. 必要時更新度量與度量目標。 優先順序需要依下列事項重新設置: • 度量的重要性 • 為獲得資料所需的人力 考量在獲取資料時,是否需要新的格式、工具或 訓練。 SP 1.4 指定分析程序 指定度量資料如何被分析與溝通。 事先指定度量的分析程序,可確保執行適當的分析與 報告,以說明已記錄的度量目標(亦說明了資訊需求 和目標,因其為度量目標的基礎)。此方法也是必要 資料蒐集的一種查核。分析程序應考慮所有進入分析 的資料的品質(例如資歷、可信度,不管是從專案、 組織度量儲存庫或其他的來源)。應考量資料的品質 以協助選擇合適的分析程序和評估分析的結果。 典型的工作產品 1. 分析規格與程序 2. 資料分析工具 度量與分析 293 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 指定將要執行的分析與將準備的報告,並排定優 先順序。 及早注意所執行的分析,以及分析報告呈現的方 式。應符合下列準則: • 分析可以清楚的說明度量目標。 • 表達結果的方式,能讓需處理此結果的人員清 楚瞭解。 在可取得的資源內排定優先順序。 2. 選擇適當的資料分析方法與工具。 通常需考量的議題如下: • 視覺呈現及其他表現方式的選擇(例如,圓餅 圖、長條圖、長條統計圖、點狀圖、線型圖 表、點狀分布圖、目錄) • 適當的描述統計的選擇(例如,計算方式、中 位數、模式) • 有關統計樣本準則的決定,當不可能或不需要 檢驗每一個資料元素時 • 當遺失的資料元素呈現時,決定如何處理分 析。 • 選擇適當的分析工具 294 度量與分析 度量與分析 關於適用於服務的能力成熟度整合模式 1.2 版 敘述統計通常用於資料分析,以執行下列事項: • 審查指定度量的分佈(例如:集中趨勢、變化 程度、資料點呈現異常變異) • 審查指定度量之間的相互關係(例如:以產品 生命週期的不同階段或產品組件來比較缺失) • 顯示隨著時間的變化 有關瞭解變異和適當使用統計分析技術,請分別 參考量化專案管理流程領域之「應用統計方法瞭 解變異」和「選擇度量與分析技術」特定執行方 法,以獲得更多資訊。 3. 指定分析資料和溝通結果的管理程序。 通常需要被考慮的議題如下: • 確認負責分析資料和呈現結果的人員和團體 • 決定分析資料和呈現結果的時間表 • 決定溝通結果(例如進度報告、移轉紀錄、手 寫報告、員工會議等)的地點 4. 審查並更新分析與報告的內容和形式。 所有提出的分析與報告的內容和形式應予審查和 修正,包括分析方法和工具、管理程序及優先順 序。相關關鍵人員的諮詢應該包括預期的最終使 用者、贊助者、資料分析人員及資料提供人員。 5. 必要時,更新度量與度量目標。 正如同度量需求會導引資料分析,清楚的分析準 則會影響度量。以資料分析程序為基礎,某些度 量規格可能會進一步調修,其他度量可能並不需 要,或發現需要其他的度量。 295 適用於服務的能力成熟度整合模式 1.2 版 當描述度量如何分析和報告時,可能同時會建議 調修度量目標。 6. 指定評估分析結果有用性及評估度量與分析活動 的準則。 評估分析結果有用性的準則,可以考慮下列項目 的應用程度: • 分析結果是否(1)適時提供、(2)容易瞭解,以及 (3)可用來制定決策。 • 分析工作的執行成本不應比它提供的效益高。 度量與分析活動的評估準則可考慮下列項目的應 用程度: • 資料缺少與不一致的數量是否超出門檻。 • 資料取樣是否有偏差(例如:僅調查滿意的使 用者以評估最終使用者滿意度,或只評估不成 功的專案以決定整體生產力)。 • 度量資料是否可重複(例如:統計上的可靠 性)。 • 統計的假設是否滿足(例如:關於資料的分佈 或關於度量單位的合適性) SG 2 提供度量結果 提供度量結果,此度量結果說明已界定的資訊需求與目標。 進行度量和分析的主要理由,是要處理已界定的資訊 需求與目標。以客觀證據為基礎的度量結果,能夠幫 助監測績效、供應商協議中記錄的義務、制定有根據 的管理與技術決策,以及採取矯正措施。 296 度量與分析 SP 2.1 蒐集度量資料 獲得指定的度量資料。 關於適用於服務的能力成熟度整合模式 1.2 版 取得需分析的資料,並檢查其完整性和整合性。 典型的工作產品 1. 基礎度量資料集與衍生度量資料集 2. 資料完整性測試的結果 細部執行方法 1. 獲得基礎度量資料。 視需要蒐集資料,包括已使用的與新指定的基礎 度量。現存資料可從專案紀錄或在組織其他地方 蒐集。 請注意,我們稍早收集的資料可能在現行資料 庫、紙本記錄或正式儲存庫中無法再重複使用。 2. 產生衍生度量資料。 重新計算所有衍生度量的值。 3. 檢查資料一致性,使其儘可能接近原始資料。 所有度量在說明或記錄資料的過程中可能發生錯 誤,最好能在度量與分析週期的初期界定這些錯 誤,並能指出所缺資料的來源。 檢查應包括詳查缺少的資料、超出所訂範圍的資 料值,以及不尋常的型態和度量間的相關性。下 列工作特別重要: • 測試和修正人為判斷分類的不一致(亦即決定 工作人員根據相同資訊而做出不同分類決策的 頻率,否則稱作「互相轉譯的可靠度」)。 度量與分析 297 適用於服務的能力成熟度整合模式 1.2 版 • 以經驗審查用來計算衍生度量之度量間的關 係,如此可確保未忽視重要差異,以及傳達衍 生度量的預期的意義(否則稱作「準則有效性 (criterion validity)」)。 SP 2.2 分析度量資料 分析與解釋度量資料。 依照計畫分析度量資料,並視需要執行額外的分析。 分析結果需由相關的關鍵人員審查,並記錄將來分析 所需做的修正。 典型的工作產品 1. 分析結果與報告草案 細部執行方法 1. 進行初步分析並解釋結果,並導出初步結論。 資料分析的結果很少可以顯而易見。解釋結果與 產生結論的準則應予明確的陳述。 2. 必要時,執行額外的度量與分析,並準備進行簡 報。 規劃的分析結果可能提出進行額外、非預期分析 的建議。此外,為適當完成計畫內的分析工作可 能界定下列需求,例如:調修現行度量、計算額 外的基礎度量,或為額外的原始度量蒐集資料。 相同地,為了準備初步分析結果的簡報,可能界 定出額外、未預期的分析需要。 3. 與相關的關鍵人員審查初步分析結果。 298 度量與分析 關於適用於服務的能力成熟度整合模式 1.2 版 在分析結果廣泛傳佈之前,對結果的初步解釋及 其表達的方式加以審查是否適當。 在最初的結果釋出前加以檢視,以避免無謂的誤 解並可改善資料分析和呈現方式。 進行審查的相關關鍵人員包括預期的最終使用 者、贊助者、資料分析人員及提供人員。 4. 為未來的分析調修準則。 可改善未來工作之學習心得,經常來自於執行資 料分析和準備結果時。類似狀況,當有調修指定 的資訊需求與目標的構想時,改善度量規格及資 料蒐集程序的方式可能會變得明顯。 SP 2.3 儲存資料與結果 管理和儲存度量資料、度量規格和分析結果。 儲存度量相關資訊,使能更及時和經濟的使用歷史資 料與結果。此資訊也對資料詮釋、度量準則及分析結 果,提供充分的說明內容。 儲存的資訊通常包括如下: • 度量計畫 • 度量規格 • 已蒐集的資料 • 分析報告和簡報資料 度量與分析 儲存的資訊包含或參考下列資訊:瞭解和解釋度量的 資訊,以及評量其合理性及適用性之資訊(例如:進 行專案之間的比較時,不同的專案可能使用不同的度 量規格)。 299 適用於服務的能力成熟度整合模式 1.2 版 衍生度量的資料集通常可以重新計算,所以不需要儲 存,可能較適合儲存衍生度量的摘要(例如:圖表、 結果表格或報告)。 如果可以有效重建中間分析的結果,這中間分析結果 不需要個別儲存。 有關建立一個組裝管理系統,請參考組裝管理流程領 域,以獲得更多資訊。 有關建立組織度量儲存庫,請參考組織流程定義流程 領域的「建立組織度量儲存庫」特定執行方法,以獲 得更多資訊。 典型的工作產品 1. 儲存資料清單 細部執行方法 1. 審查資料以確保完整性、一致性、正確性與及時 性。 2. 根據資料儲存程序來儲存資料 3. 確定儲存的內容僅提供適當的團體與人員使用。 4. 防止資料不當使用。 避免資料和相關資訊的不適當使用的方式的例子,包 括管控存取資料和教育人員適當地使用資料。 300 度量與分析 關於適用於服務的能力成熟度整合模式 1.2 版 不當使用資料之情形,舉例如下: • 揭露秘密資訊 • 由於不完全、不相關或其他誤導的資訊,而造成 錯誤的解釋 • 不當的評估同仁的績效或進行專案評比 • 責難人員的正直與誠實。 SP 2.4 溝通結果 向所有相關的關鍵人員溝通度量與分析活動的結果。 用即時、有用的方式,向所有相關的關鍵人員報告度 量與分析的結果,以支援制訂決策與協助採取矯正措 施。 相關的關鍵人員包括預定的使用者、贊助者、資料分 析人員及資料提供人員。 典型的工作產品 1. 交付的報告和相關的分析結果 2. 能幫助詮釋分析結果的相關資訊或指引 度量與分析 細部執行方法 1. 及時告知相關的關鍵人員度量結果。 度量結果要依據預期的目的,及時地溝通使用。 如果報告隨意地被發送給那些需要知道結果的, 可能會不被使用。 在可能的範圍內,度量結果的使用者應親自參與 設定目標與決定度量與分析行動的計畫,就如同 他們執行企業的部分任務一般。進度和中間結果 定期持續告知使用者。 301 適用於服務的能力成熟度整合模式 1.2 版 有關執行進度檢視,請參考專案監督和管控流程 領域,以獲得更多資訊。 2. 協助相關的關鍵人員瞭解結果。 以清楚簡明的方式,對相關的關鍵人員溝通結 果。結果必須是易於瞭解、詮釋,並且與指定的 資訊需求及目標清楚連結。 不是度量專家的執行者對分析的資料通常不是很 明白。有關下列事項,結果的溝通必須是明確 的: • 如何與為何指定基礎度量和衍生度量 • 如何取得資料 • 如何使用資料分析方法解釋結果 • 結果如何說明資訊需求 協助瞭解結果的活動,舉例如下: • 與相關的關鍵人員討論結果 • 提供內含背景與解說的備忘錄 • 對使用者進行度量結果的簡報 • 提供關於適當使用和瞭解度量結果的教育訓 練。 302 度量與分析 關於適用於服務的能力成熟度整合模式 1.2 版 組織創新與推展 成熟度第五級的流程管理類流程領域 目的 組織創新與推展(Organizational Innovation and Deployment, OID)的目的,在於選擇與推展具漸進和 創新效果的各種改善措施。這些改善措施以可度量的 方式,改善組織流程和技術,也支持由組織經營目標 導出的品質和流程績效目標。 簡介 組織創新與推展流程領域藉由改善措施的選擇與推 展,加強組織能力,以滿足其品質和流程績效目標 (有關「品質和流程績效目標」的定義,請參見詞 彙)。 本流程領域所用的術語「改善」係指可變更組織流程 和技術的所有構想(含已證明及未證明的),以更符合 組織的品質和流程績效目標。 而流程和技術,當它們應用到服務系統時,則是指要 滿足服務需求和成功地交付服務。因此,如同在流程 領域中所調適的,流程和技術組成了服務系統的組 件。 本流程領域所說明的品質和流程績效目標,可包括: • 改善的產品品質(例如:功能、績效) 組織創新與推展 303 適用於服務的能力成熟度整合模式 1.2 版 • 提升的生產力 • 減低的週期時間 • 更高的客戶和最終使用者滿意度 • 因應變更功能、增加新特性或採用新技術,較短 的發展和生產時間 • 減少交付時間 • 減少適應新技術及經營需要的時間 這些目標的達成有賴於成功的建立一個基礎架構,以 促成並鼓勵所有同仁,提出組織流程和技術的可能改 善措施。這些目標的達成也有賴於有效地評估與推展 所建議的改善措施。所有同仁都能參與流程和技術的 改善活動,而且有系統的蒐集和處理同仁的建議。 在廣泛推展之前,具重大變革之未經實驗、高風險或 創新的改善建議,應進行試行以評估其影響。 自流程和技術的改善建議中挑選改善措施,以推展至 整個組織的準則如下所列: • 對組織現行品質和流程績效的量化瞭解 • 組織的品質和流程績效目標 • 推展流程和技術改善後,品質和流程績效改善的 預估值 • 推展流程和技術改善的預估成本,以及可用於該 推展的資源和資金 必須衡量流程和技術改善帶來的預期效益與其成本和 對組織的衝擊,並在變更與穩定之間小心取得平衡。 變更太大或太快,組織將無法承受,而且會毀壞組織 的學習投資,亦即破壞組織的流程資產。而一成不變 304 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 的穩定也會導致停滯不前,使不斷變動的經營環境腐 蝕組織的經營地位。 對新的與進行中的專案,適當地推展改善措施。 本流程領域的「流程和技術改善」係指對流程本身, 以及對流程或產品技術(包括專案工作環境)之漸進和 創新的改善。 撰寫本流程領域的助益性資料時,假設此特定執行方 法應用於對標準流程以及在可預期狀態下所期望的品 質與績效有量化瞭解的組織。在不考慮此前提的情況 下,本流程領域的特定執行方法也可適用,不過會降 低所產生的價值。 本流程領域的特定執行方法補充並擴大組織流程專注 流程領域的特定執行方法。本流程領域專注於流程改 善,乃以下列兩項量化的瞭解為基礎進行流程改善: 組織標準流程和技術,以及其在可預知情境下所期望 的品質和績效。在組織流程專注流程領域中,並沒有 關於改善之量化基礎的假設。 相關流程領域 有關採取正式的評估流程來分析可能的決策,而此評 估流程係用來評估已建立的準則的替代方案,請參考 決策分析與解決方案流程領域,以獲得更多的資訊。 有關結合度量與分析活動,且提供度量結果,請參考 度量與分析流程領域,以獲得更多資訊。 有關基於對現行組織流程與流程資產的優點與弱點的 通盤瞭解以規劃、執行及推展組織流程改善,請參考 組織流程專注流程領域,以獲得更多資訊。 組織創新與推展 305 適用於服務的能力成熟度整合模式 1.2 版 有關建立品質和流程績效目標、建立流程績效基準線 以及建立流程績效模式,請參考組織流程績效流程領 域,以獲得更多資訊。 有關提供所需的訓練,請參考組織訓練流程領域,以 獲得更多資訊。 特定目標及執行方法摘要 選擇改善措施 SP 1.1 蒐集並分析改善建議 SP 1.2 界定並分析創新 SP 1.3 試行改善措施 SP 1.4 選擇改善措施以便推展 SG 2 推展改善措施 SP 2.1 規劃推展計畫 SP 2.2 管理推展工作 SP 2.3 度量改善效果 各目標的特定執行方法 SG1 選擇改善措施 選擇有助於符合品質與流程績效目標的各種流程與技術改善措 施。 SP 1.1 蒐集並分析改善建議 蒐集並分析流程與技術的改善建議。 必須分析每個流程和技術的改善建議。 通常不需要詳細評估容易瞭解其效益及影響的簡單流 程和技術改善措施。 306 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 簡單流程與技術改善的範例如下: • 在同儕檢視的檢查清單中加入一個項目 • 整合供應商的技術檢視及管理檢視成為一個單 一的檢視 典型的工作產品 1. 已分析的流程和技術改善建議 細部執行方法 1. 蒐集流程和技術的改善建議。 流程和技術改善建議記錄對流程和技術之漸進和 創新的改善建議。組織中的管理者和成員,以及 客戶、最終使用者及供應商,都能提出流程和技 術改善建議。在提議到整個組織實施之前,流程 和技術改善措施應先局部實施。 組織創新與推展 307 適用於服務的能力成熟度整合模式 1.2 版 流程和技術改善建議的來源,舉例如下: • 流程評鑑的調查結果和建議 • 組織品質及流程績效目標 • 客戶和最終使用者的問題,以及客戶及最終使 用者滿意度的資料分析 • 專案績效與品質和生產力目標比較的資料分析 • 服務系統與服務交付績效度量的分析 • 流程和產品標竿學習工作的結果 • 可接受品質的資料分析 • 流程活動的度量成效 • 專案工作環境的度量成效 • 流程和技術改善建議於其他地方成功採用的範 例 • 先前提出之流程和技術改善建議的回饋 • 專案經理和成員自發的構想 有關整合經驗到組織流程資產和管理流程改善提 案,請參考組織流程專注流程領域,以獲得更多 資訊。 2. 適當地分析流程和技術改善建議的成本和效益。 流程的和技術改善的建議有很大比例的成本與獲 益被拒絕。 評估成本和效益的準則如下: • 滿足組織品質和流程績效目標的貢獻程度 • 對減輕已界定之專案和組織風險的影響 308 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 • 對專案需求、市場狀況及經營環境等變更的快 速反應能力 • 對相關流程和資產的影響 • 蒐集和定義資料的成本,該資料用以支援流程 和技術改善建議之度量與分析 • 改善建議的預期期限 不會改善組織流程的流程的和技術改善的建議會 被拒絕。 流程績效模式可以洞察流程變更在流程能力和績 效上的影響。 有關建立流程績效模式,請參考組織流程績效流 程領域,以獲得更多資訊。 3. 界定具創新的流程和技術改善建議。 「界定並分析創新」特定執行方法也界定並分析 創新的改善。 「界定並分析創新」特定執行方法用以主動尋求 和找出創新改善,而本特定執行方法用於分析被 動蒐集的建議。「界定及分析創新」特定執行方 法的「尋求」主要是從組織外找尋。 創新改善的界定通常藉由審查流程和技術改善建 議,或積極調查和追蹤其他機構所使用或研究文 獻所記載的創新著手。創新可能由內部的改善目 標或外在經營環境所激發。 創新的改善通常是流程的重要變更,它代表自舊 有做事方法的一種脫離,例如生命週期方法論的 變更。創新的改善也可能包括支援流程、加強流 程,或使流程自動化之產品的變更。例如:使用 現成品以支援流程。 組織創新與推展 309 適用於服務的能力成熟度整合模式 1.2 版 創新改善包括下列項目的新增或重大更新: • 支援工具 • 流程或生命週期模式 • 介面標準 • 再用元件 • 管理技術與方法 • 品質改善技術與方法 4. 界定推展流程和技術改善建議的潛在障礙和風險。 推展流程和技術改善的障礙,舉例如下: • 本位主義和狹窄的眼光 • 不清楚或不堅定的經營理念 • 缺少短期效益和可見的成功 • 對每個人的期望不清楚 • 同一時間有太多的變更 • 缺少來自相關的關鍵人員的參與和支援 310 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 影響流程和技術改善推展的風險因素,舉例如 下: • 改善措施與現有流程、價值觀及潛在最終使用 者技能的相容程度 • 改善的複雜度 • 實施改善的困難度 • 在全面推展前,展示改善價值的能力 • 在某些方面(如工具和訓練)進行大額、前期投資 的正當理由 • 因現有技術已成功地被大量成熟的最終使用者 所採用,故無法克服的「技術障礙」 5. 估計推展每個備選流程和技術改善建議所需的成 本、工作量及時程。 6. 在大規模推展前,先選擇一些流程和技術改善建 議進行試行。 依據定義,創新通常代表重大變更,所以大部分 的創新改善應先試行。 7. 記錄每個流程和技術改善建議的評估結果。 8. 監督每個流程和技術改善建議的狀況。 SP 1.2 界定並分析創新 界定並分析能增加組織之品質與流程績效的創新改善 措施。 「蒐集並分析改善建議」特定執行方法係分析被動蒐 集的建議,而本特定執行方法係主動尋求和找出創新 改善措施,而且主要是從組織外找尋。 組織創新與推展 311 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 備選的創新改善措施 2. 所建議之創新改善措施的分析 細部執行方法 1. 分析組織標準流程,以決定這些創新改善措施對 哪些領域最有幫助。 執行這些分析,以決定達到組織品質和流程績效 目標具關鍵性的子流程,以及可加以改善的備選 子流程。 2. 調查研究可改善組織標準流程的創新改善措施。 創新改善的調查,可包括下列活動: • 有系統地留意領先的工作相關技術和技術趨勢 • 定期尋求市面上可用的創新改善措施 • 蒐集來自專案和組織的創新改善建議 • 有系統地審查外界使用的流程和技術,並與組 織內部所使用的相互比較 • 界定已成功使用創新改善的領域,並審查這些 改善措施的資料和經驗文件 • 界定整合新技術到產品及專案工作環境的改善 措施 3. 分析具潛力的創新改善措施,以瞭解它們對流程 元件的效果,並預測它們對流程的影響。 流程績效模式提供基礎,以分析流程元件變更的 可能影響。 有關流程績效模式,請參考組織流程績效流程領 域,以獲得更多資訊。 312 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 4. 分析具潛力之創新改善措施的成本和效益。 成本到獲益佔很大比例的創新改善會被拒絕。 5. 針對可導致改善組織流程或技術的創新改善措施, 製作流程和技術改善建議。 6. 在大規模推展之前,應選擇創新改善措施進行試 行。 依據定義,創新通常代表重大變更,所以大部分 的創新改善應先試行。 7. 記錄創新改善措施的評估結果。 SP 1.3 試行改善措施 試行流程與技術改善措施,以選擇適合推展的措施。 在大規模推展之前,適當地試行創新改善,以評量新 的和未經證明的重大變更。 本特定執行方法可與原因分析與解決方案流程領域的 「實施行動建議書」特定執行方法重疊實施,例如: 當整個組織或跨多個專案實施原因分析與解決方案的 時候。 典型的工作產品 1. 試行的評估報告 2. 試行的學習心得 組織創新與推展 細部執行方法 1. 規劃試行計畫。 在規劃試行計畫時,定義用以評估試行結果的量 化準則。 2. 審查試行計畫,並取得相關關鍵人員的同意。 3. 提供諮詢和協助予執行試行計畫的人員。 313 適用於服務的能力成熟度整合模式 1.2 版 4. 在具有大規模推展性的環境下,執行每個試行計 畫。 5. 按照計畫,追蹤試行的情況。 6. 審查並記錄試行的結果。 試行結果是使用在進行試行規劃時,所定義的量 化準則加以評估。審查並記錄試行的結果,通常 包括下列活動: • 決定是否結束試行、重新規劃並繼續試行,或 進行流程和技術改善的推展 • 更新配合試行之流程和技術改善建議的安排 • 適當的界定並記錄新的流程和技術改善建議 • 界定並記錄在試行時所遇到的問題和學習心得 SP 1.4 選擇改善措施以便推展 選擇流程與技術的改善措施,以便在組織內推展。 推動整個組織的流程和技術改善措施,其選擇方式是 以可量化的準則為基礎,而該準則是由組織的品質和 流程績效目標衍生而來。 典型的工作產品 1. 已選定用以推展之流程和技術的改善措施 細部執行方法 1. 排定流程和技術改善措施的推展優先順序。 優先順序是以預估本益比的評估為基礎,該本益 比與品質和流程績效目標有關。 314 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 有關品質和流程績效目標,請參考組織流程績效 流程領域,以獲得更多資訊。 2. 選擇要在組織內推展的流程和技術改善措施。 流程改善措施的評選係以其優先順序和可用資源 為基礎。 3. 決定如何推展每個流程和技術改善措施。 何處可以推展流程和技術改善措施,舉例如下: • 組織流程資產 • 專案特定或一般的工作環境 • 組織的服務線 • 組織的能力 • 組織的專案 • 組織的團隊 4. 記錄評選過程的結果。 組織創新與推展 315 適用於服務的能力成熟度整合模式 1.2 版 評選過程的結果,通常包括: • 評選候選改善措施的準則 • 每個改善建議的處理方式 • 每個改善建議之處理方式的理由 • 每個選定的改善措施將變更的資產 SG 2 推展改善措施 針對組織的流程與技術,持續及有系統地推展各種可度量的改 善措施。 SP 2.1 規劃推展計畫 針對已選定的流程與技術改善措施,建立並維護推展 計畫。 已選定的流程和技術改善的推展計畫,可包含在組織 創新和推展計畫中,也可以個別文件記載。 本特定執行方法的實施,補足了組織流程專注流程領 域中,推展組織流程資產的特定執行方法,並加入量 化資料的使用,來指導推展,與決定有關品質及流程 績效目標的改善價值。 有關推展組織流程資產,請參考組織流程專注流程領 域,以獲得更多資訊。 本特定執行方法規劃已選定的流程和技術改善的推 展。而「規劃流程」一般執行方法則注重廣泛的規劃 活動,它涵蓋本流程領域的特定執行方法。 典型的工作產品 1. 已選定之流程和技術改善措施的推展計畫 細部執行方法 1. 決定如何調整每個流程和技術改善措施,以便在 整個組織內推展。 316 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 在有限範圍(如單一專案)內的流程和技術改善,如 果要適用於全組織,或許須進行一些修正。 2. 決定需要的變更,以便推展每個流程和技術改善 措施。 推展流程和技術改善措施,須進行的變更,舉例 如下: • 流程說明、標準及程序 • 工作環境 • 教育訓練 • 技能 • 現有承諾 • 現有活動 • 對最終使用者的持續支援 • 組織文化和特色 3. 界定各種策略,以便克服每個流程和技術改善措施 推展時的潛在障礙。 4. 建立度量和目標,以決定每個流程和技術改善措施 相對於組織經營目標的價值。 組織創新與推展 317 適用於服務的能力成熟度整合模式 1.2 版 決定流程與技術改善數值的度量範例如下: • 投資報酬 • 流程或技術改善的成本回收所需時間 • 專案或組織產品品質與流程績效的已度量改善 • 藉由流程和技術改善,減輕之專案和組織風險 的數目和類型 • 對專案需求、市場狀況及經營環境的變更快速 反應的能力 有關結合度量與分析活動及提供度量結果,請參 考度量與分析流程領域,以獲得更多資訊。 5. 記錄已選定的流程和技術改善措施的推展計畫。 6. 審查已選定的流程和技術改善措施的推展計畫, 並取得關鍵人員的同意。 7. 必要時,修訂已選定的流程和技術改善措施的推 展計畫。 SP 2.2 管理推展工作 針對已選定的流程與技術改善措施,管理其推展情 況。 本特定執行方法可與原因分析與解決方案流程領域的 「實施行動建議書」特定執行方法重疊實施,例如: 當整個組織或跨多個專案實施原因分析與解決方案的 時候。主要差異在於原因分析與解決方案流程領域的 規劃,是用於管理如何移除專案已調適流程之缺失或 問題的根本原因,而組織創新與推展流程領域的規 劃,是用於管理如何推展符合組織經營目標之組織流 程和技術的改善措施。 典型的工作產品 318 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 1. 最新的訓練教材(以反映已推展的流程和技術改善 措施) 2. 流程和技術改善措施推展活動的紀錄 3. 已修訂的流程和技術改善措施之度量、目標、優先 順序及推展計畫 細部執行方法 1. 使用推展計畫,監督流程和技術改善措施的推展 情形。 2. 協調組織內流程和技術改善措施的推展活動。 推展的協調活動,包括: • 協調每個流程和技術改善之專案、支援小組及 組織中各小組的活動。 • 協調相關之流程和技術改善的各項推展活動。 3. 以受管制、有紀律的適當方式,快速推展流程和 技術改善措施。 快速推展流程和技術改善措施的方法,舉例如 下: • 使用劃紅線、流程變更通告,或其他納管流程 的文件,作為暫時的流程說明 • 漸進地推展流程和技術改善措施,而非一步完 成 • 對流程和技術改善措施的早期採用者,提供廣 泛的顧問諮詢,以代替已修訂的正式訓練 組織創新與推展 4. 適當地把流程和技術改善措施整合至組織流程資 產。 有關組織流程資產,請參考組織流程定義流程領 域,以獲得更多資訊。 319 適用於服務的能力成熟度整合模式 1.2 版 5. 將流程和技術改善措施的推展,適當地融入專案 已調適流程。 有關協調流程改善的推展,並納入專案已調適流 程,請參考組織流程專注流程領域,以獲得更多 資訊。 6. 提供適當的諮詢服務,以支援流程和技術改善措 施的推展。 7. 提供最新的訓練教材,以反映組織流程資產的改 善。 有關訓練教材,請參考組織訓練流程領域,以獲 得更多資訊。 8. 確認所有流程和技術改善措施的推展皆已完成。 9. 決定已調適流程滿足品質和流程績效目標的能 力,是否受到流程和技術改善措施的負面影響。 必要時,採取矯正措施。 有關量化管理專案已調適流程以達成專案所設定 的品質和流程績效目標,請參考量化專案管理流 程領域,以獲得更多資訊。 10. 記錄並審查流程和技術改善措施推展的結果。 記錄並審查結果,包括: • 界定並記錄學習心得 • 界定並記錄新流程和技術的改善建議 • 修訂流程和技術改善的度量、目標、優先順序 及推展計畫 SP 2.3 度量改善效果 針對已推展的流程與技術改善措施,度量其效果。 320 組織創新與推展 關於適用於服務的能力成熟度整合模式 1.2 版 有關建立度量與分析的目標、界定待執行的度量與分 析、取得和分析度量資料,以及報告結果等,請參考 度量與分析流程領域,以獲得更多資訊。 本特定執行方法可與原因分析與解決方案流程領域的 「評估變更的效果」特定執行方法重疊實施,例如: 當整個組織或跨多個專案實施原因分析與解決方案的 時候。 典型的工作產品 1. 推展流程和技術改善效果度量的紀錄 細部執行方法 1. 度量推展每個流程和技術改善措施所需的成本、 工作量及時程。 2. 度量每個流程和技術改善措施的價值。 3. 度量改善措施在達成組織品質和流程績效目標的 進度。 4. 分析改善措施在達成組織品質和流程績效目標的 進度。必要時,採行矯正措施。 有關建立品質與流程績效目標、建立流程績效基 準線及建立流程績效模式,請參考組織流程績效 流程領域,以獲得更多資訊。 5. 儲存度量結果於組織度量儲存庫中。 組織創新與推展 321 適用於服務的能力成熟度整合模式 1.2 版 組織流程定義 成熟度第三級的流程管理類流程領域 目的 簡介 322 組織流程定義的目的是建立並維護可用的組織流程資 產與工作環境標準。 組織流程資產使整個組織有一致的流程績效,並且提 供組織一累積性、長期性效益的基礎。(「組織流程 資產」的定義在詞彙中) 組織流程資產館是蒐集資料項目的地方,並由組織維 護,以提供人員及專案使用。組織流程資產館蒐集的 資料項目包括:流程與流程元件的說明、生命週期模 式的說明、流程調適指引、流程相關的文件及資料。 組織流程資產館允許全組織共享最佳執行方法與學習 心得,以支援組織學習與流程改善。 專案引用組織標準流程,將其調適成專案定義的流 程。而其他組織流程資產可用來支援調適與執行已調 適流程。工作環境的標準是用來建立專案工作環境。 標準流程由其他流程或流程元件所組成。流程元件是 流程定義的基本單位(例如:原子),它說明一致性執 行工作的活動與工作項目。流程架構提供在標準流程 組織流程定義 關於適用於服務的能力成熟度整合模式 1.2 版 中連接流程元件的規則。組織標準流程可包含多個流 程架構。 「標準流程」、「流程架構」與「流程元件」的定 義,請參見詞彙。 依組織流程定義流程領域的建置,組織流程資產 可以多種方式組織起來。舉例如下: • 生命週期模式的說明,可以成為組織標準流程 的一部分,或是獨立成另一文件。 • 組織標準流程可以儲存在組織流程資產館,或 是單獨儲存。 • 可用單一儲存庫儲存度量及流程相關文件,或 是二者分開儲存。 相關流程領域 有關建立及維護標準服務以與策略需求及計畫一致, 請參考策略服務管理流程領域,以獲得更多資訊。 有關推展組織流程資產,請參考組織流程專注流程領 域,以獲得更多的資訊。 特定目標及執行方法摘要 SG 1 建立組織流程資產 SP 1.1 建立標準流程 SP 1.2 建立生命週期模式說明 SP 1.3 建立調適準則及指引 SP 1.4 建立組織度量儲存庫 SP 1.5 建立組織流程資產館 SP 1.6 建立工作環境標準 SP 1.7 建立整合團隊的規則及指引 組織流程定義 323 適用於服務的能力成熟度整合模式 1.2 版 各目標的特定執行方法 SG 1 建立組織流程資產 建立並維護組織流程資產。 SP 1.1 建立標準流程 建立並維護組織標準流程。 在企業中,標準流程可定義成多個層次,並且能以架 構性層次互相關聯。例如:一個企業的標準流程,可 由個別組織(例如:部門或地點)進行調適,以建立自 己的標準流程。標準流程可按各個組織經營領域或產 品線調適而得。因此組織標準流程可以參照在組織層 次所建立的標準流程,以及在組織較低層次所建立的 標準流程。某些組織可能只有單一層次的標準流程。 (「標準流程」與「組織的一組標準流程」的定義, 請參見詞彙。) 多個標準流程可能同時存在,以滿足不同的應用領 域、生命週期模式、方法及工具的需要。流程架構描 述流程元件之間的關聯,組織標準流程包含流程元件 (例如:估算工作產品規模大小的元件),而這些元件 在一個或多個流程架構中互相關聯。流程可能由一些 流程或流程元件組成。 組織標準流程通常包括技術、管理、行政、支援及組 織的流程。 組織標準流程應涵蓋組織與專案所需的全部流程,包 括成熟度第 2 級的流程領域。 典型的工作產品 1. 組織標準流程 324 組織流程定義 細部執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 1. 分解個別的標準流程為構成的流程元件,使詳細 到足以瞭解並說明流程。 每個流程元件包含一組緊密相關的活動。流程元 件的說明可能是供填寫的樣板、供完整組合的組 件、供進一步細緻化的抽象概念,或供調適或不 經修改即可採用的完整說明。這些元件以充分詳 盡的方式說明,以致於流程經完整地定義後,經 過適當訓練與具備技能的人員能夠一致地執行。 流程元件,舉例如下: • 客製的事故解決方案流程 • 發展服務協議的樣板 • 產出工作產品規模預測的樣板 • 工作產品設計方法論的描述 • 客製的同儕檢視方法論 • 執行管理審查的樣板 組織流程定義 325 適用於服務的能力成熟度整合模式 1.2 版 2. 界定每一流程元件的重要屬性。 重要屬性舉例如下: • 流程的角色 • 適用的標準 • 適用的程序、方法、工具及資源 • 流程績效目標 • 允入準則 • 輸入 • 產品與流程方式 • 驗證點(例如:同仁審查) • 輸出 • 介面 • 允出準則 3. 界定各流程元件的關聯。 關聯,舉例如下: • 流程元件的次序 • 流程元件之間的介面 • 與外部流程的介面 • 流程元件之間的相依性 說明流程元件之間關聯的規則叫做「流程架 構」,流程架構涵蓋重要的需求與指引。這些關 聯的詳細規格包含於已調適流程中,而已調適流 程是由組織標準流程調適而得。 4. 確保組織標準流程是遵循適用的政策、流程標準 與模式,以及產品標準。 326 組織流程定義 關於適用於服務的能力成熟度整合模式 1.2 版 遵循適用的流程標準與模式,通常以製作組織標 準流程與相關流程標準及模式的對照表來證明, 這個對照表是未來評鑑時有用的輸入資料。 5. 確保組織標準流程能滿足流程需要與組織目標。 有關建立組織流程需求,請參考組織流程專注流 程領域,以獲得更多資訊。 6. 確保組織標準流程中的各個流程,都能恰當地整 合。 7. 記錄組織標準流程。 8. 對組織標準流程執行同仁審查。 服務系統發展補充 有關呈現同仁審查,請參考服務系統發展流程領 域,以獲得更多資訊。 9. 必要時,修訂組織標準流程。 SP 1.2 建立生命週期模式說明 建立並維護生命週期流程模式的說明,經核准後在組 織中使用。 對於不同的客戶與不同的情況,可能發展多個生命週 期模式,因為只有一個生命週期模式可能不適用於所 有情況。生命週期模式常用來定義專案的階段,同時 組織對每一產品與服務種類,可能定義不同的生命週 期模式。 典型的工作產品 1. 生命週期模式的說明 組織流程定義 327 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 根據專案與組織的需要,選擇生命週期模式。 服務生命週期模式的選擇端視服務及環境的特性。某 些服務供應商依照他們的標準服務定義來調適生命週 期階段。 結合了服務生命週期的階段型態,舉例如下: • 規劃、調適、啟動和度量 • 規模定義、規劃、執行和結束 • 策略、設計、移轉、運作和改善 通常,個人的服務領域絕對含有生命週期,包含 溝通點、評估點和決策點。對這些點的描述可能 包括同意在組織內使用的一組生命週期模式的描 述。 用來發展服務系統的專案生命週期模式,舉例如 下: • 瀑布式 • 螺旋式 • 創新式 • 增值式的 • 反覆式的 2. 文件化生命週期模式的說明。 生命週期模式可以成為組織標準流程說明的一部 分文件,或獨立成另一文件。 3. 對生命週期模式執行同仁審查。 328 組織流程定義 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 有關呈現同仁審查,請參考服務系統發展流程領 域,以獲得更多資訊。 4. 必要時,修訂生命週期模式的說明。 SP 1.3 建立調適準則及指引 建立並維護組織標準流程的調適準則及指引。 調適準則及指引說明下列事項: • 如何引用組織標準流程及組織流程資產,以產生 已調適流程 • 已調適流程必須滿足必要的需求(例如:對於已調 適流程非常重要的組織流程資產的子集合) • 列出可選擇的項目及選擇的準則 • 執行與記錄流程調適時必須遵循的程序 組織流程定義 調適的原因,舉例如下: • 為新的產品線或主機環境而調適流程 • 為特定的應用或應用類別(例如:啟動發展、維 護或製作雛型)而將流程客製化 • 更詳盡的流程說明,以使已調適流程能夠執行 在調適與定義流程的彈性以及確保全組織流程的適當 一致性之間,須作平衡。彈性是需要的,以滿足範圍 的變數,例如:專業領域,客戶特性,成本、時程及 品質取捨分析,工作的技術難度,以及執行流程的人 員經驗。在組織中須有一致性,以能夠適當滿足組織 標準、目標及策略,並且能夠分享流程資料與學習心 得。 329 適用於服務的能力成熟度整合模式 1.2 版 調適準則與指引允許標準流程就是已調適流程,不需 要調適。 典型的工作產品 1. 組織標準流程的調適指引 細部執行方法 1. 界定用以調適組織標準流程的選擇準則及程序。 準則與程序,舉例如下: • 由組織核准的生命週期模式中進行選擇的準則 • 由組織標準流程中選擇流程元件的準則 • 為了適合特定流程的特性與需求,調適選定的 生命週期模式與流程元件的程序 調適行動,舉例如下: • 修改生命週期模式 • 組合不同生命週期模式的元件 • 修改流程元件 • 替換流程元件 • 重新排列流程元件的順序 2. 界定文件化已調適流程的標準。 3. 針對組織標準流程的需求,界定用以提出及取得 豁免權核准的程序。 4. 文件化組織標準流程的調適指引。 5. 對調適指引執行同仁審查。 330 組織流程定義 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 有關呈現同仁審查,請參考服務系統發展流程領 域,以獲得更多資訊。 6. 必要時,修訂調適指引。 SP 1.4 建立組織度量儲存庫 建立並維護組織度量儲存庫。 有關使用組織度量儲存庫於規劃專案活動,請參考整 合的專案管理流程領域的「使用組織流程資產規劃專 案活動」特定執行方法,以獲得更多資訊。 儲存庫包含與組織標準流程相關的產品度量與流程度 量。儲存庫也包含或引用瞭解與解釋度量,並評量其 合理性與適用性所需的資訊。例如:引用度量的定義 以比較不同流程的相同度量。 典型的工作產品 1. 組織標準流程的共通產品與流程度量的定義 2. 組織度量儲存庫的設計 3. 組織度量儲存庫(即儲存庫結構及支援環境) 4. 組織度量資料 細部執行方法 1. 決定組織儲存、取用及分析度量的需要。 2. 定義組織標準流程中產品及流程的共通度量。 組織流程定義 331 適用於服務的能力成熟度整合模式 1.2 版 共通度量是根據組織標準流程而選出。所選定的 度量是有能力提供流程績效之可視性,以支援預 期的商業目標。共同共通度量可能會因不同的標 準流程而不同。 度量的操作定義說明蒐集正確資料的程序及在流 程中的資料蒐集點。 共通使用的度量類別,舉例如下: • 工作產品規模的預測(例如,頁數) • 人力和成本的預測(例如,工時) • 規模、人力和成本的實際度量 • 品質的度量(例如,通報事故的數量) • 同仁審查的範圍 • 測試的範圍 • 可信度的度量(例如失敗的平均時間) 3. 設計及建置度量儲存庫。 4. 界定儲存、更新及取用度量的程序。 有關特定的資料收集和儲存程序,參考度量和分 析流程領域,以獲得更多的資訊。 5. 對於共通度量的定義,以及儲存、更新與取用度 量的程序,執行同仁審查。 服務系統發展補充 審查,請參考服務系統發展流程領域,以獲得更 多資訊。 6. 將指定的度量放入儲存庫。 332 組織流程定義 關於適用於服務的能力成熟度整合模式 1.2 版 有關界定度量,參考度量和分析流程領域,以獲 得更多資訊。 7. 使流程度量儲存庫的內容,能夠讓組織及專案恰 當地使用。 8. 當組織需求變更時,修訂度量儲存庫、共通度量 及程序。 共通度量需要修訂的時機,舉列如下: • 新增流程 • 修訂流程及需要新流程度量 • 需要更細節的資料 • 需要更具清晰度的流程 • 需要淘汰的度量 SP 1.5 建立組織流程資產館 建立並維護組織流程資產館。 組織流程定義 333 適用於服務的能力成熟度整合模式 1.2 版 儲存在組織流程資產館的資料項目,舉例如下: • 組織政策 • 流程的說明 • 程序(例如:估計程序) • 發展計畫 • 採購計畫 • 品質保證計畫 • 訓練教材 • 流程的輔助工具(例如:檢查清單) • 學習心得報告 典型的工作產品 1. 組織流程資產館的設計 2. 組織流程資產館 3. 已選定將要放入組織流程資產館的資料項目 4. 組織流程資產館資料項目的目錄 細部執行方法 1. 設計並建置組織流程資產館,包括組織流程資產 館的結構及支援環境。 2. 界定資料項目納入組織流程資產館的準則。 納入的資料項目主要依據它們與組織標準流程的 關聯性。 3. 界定儲存、更新與取用資料項目的程序。 4. 將已選擇的資料項目納入組織流程資產館中,並 編入目錄,使之容易參考及取用。 5. 使資料項目可供各專案使用。 334 組織流程定義 關於適用於服務的能力成熟度整合模式 1.2 版 6. 定期審查個別資料項目的使用情況 7. 必要時,修訂組織流程資產館。 需要修訂組織流程資產館的時機,舉列如下: • 新增資料項目 • 淘汰資料項目 • 變更現有資料項目版本 SP 1.6 建立工作環境標準 建立及維護工作環境標準 工作環境標準容許組織及專案,從共用的工具、訓練 及維護中獲益,同時從大量採購中節省成本。工作環 境標準描述所有相關關鍵人員的需要,並考量生產 力、成本、可用性、保全性及工作地點健全、安全 性,以及人因工程因素。工作環境標準包括調適與使 用豁免的指引,能讓工作環境標準適應並符合需要。 工作環境標準,舉例包括: • 工作環境操作、安全及保全性的程序 • 標準工作站的硬體及軟體 • 標準應用軟體及其調適指引 • 標準生產及機器等級 • 請求及核准調適或豁免的流程 • 服務供應商必須工作的客戶端工作環境的運 作、安全和保安程序。 典型工作產品 1. 工作環境標準 組織流程定義 335 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 評估適合組織之市售可用的工作環境標準 2. 採行現存工作環境標準,並以組織流程需要及目標 為基礎,發展新的工作環境標準來彌補差距。 SP 1.7 建立整合團隊的規則及指引 建立及維護組織規則及指引,以架構、組成與運作整 合團隊 當為整合團隊建立規則和指引時,確保他們符合所有 本地與國家的可能會影響團隊整合的法令規章。 整合團隊的運作規則及指引可用以定義及控制團隊如 何相互影響以完成目標。這些規則及指引也提倡有效 整合團隊的工作量、高績效,及生產力。整合團隊成 員必須了解工作的標準,並根據這些標準來參與。 架構整合團隊包括定義團隊的數目、團隊的類型、團 隊與團隊在此架構下的關聯。組成整合團隊包括為團 隊訂規章、任命團隊成員與領隊、提供每個團隊足以 完成所賦工作的資源。 典型工作產品 1. 架構及組成整合團隊的規則及指引 細部執行方法 1. 建立與維護活動的機制以促成及時的決策。 一個成功的團隊環境,必須建立清楚的責任和授 權管道。當一個整合團隊所獲得的授權太多或太 少,或由誰負責決策不清楚時,在組織的任何層 級都可能產生議題。記錄和推展組織指引,清楚 地定義整合團隊的權力,可以避免這些議題。 2. 建立架構及組成整合團隊的規則及指引 336 組織流程定義 關於適用於服務的能力成熟度整合模式 1.2 版 組織流程資產能幫助專案來架構及執行整合團 隊。這樣的資產包括如下: • 團隊架構指引 • 團隊組成指引 • 團隊授權及責任指引 • 建立溝通及授權的指引 • 團隊領導者選擇準則 3. 定義期望、規則及指引,引導整合團隊如何共同的 工作 這些規則及指引,建立了跨整合團隊的組織執 行方法之一致性。 • 整合團隊間的介面,如何建立與維護 • 如何接受指派 • 如何使用資源及輸入 • 如何完成工作 • 誰來檢查、審查及核准工作 • 如何核准工作 • 如何交付及溝通工作 • 誰向誰報告 • 什麼是報告的需求(例如成本、時程、績效狀 態)、度量及方式 • 使用何種進度報告度量及方式 4. 維護架構及組成整合團隊的規則及指引 5. 建立及維護組織指引,以幫助團隊成員平衡團隊及 隸屬組織責任。 組織流程定義 337 適用於服務的能力成熟度整合模式 1.2 版 隸屬組織是組織的一部分,當團隊成員不屬於整 合團隊,就可被指派。隸屬組織也可稱為功能組 織、隸屬基礎、隸屬辦公室,或直接組織。 338 組織流程定義 組織流程專注 成熟度第三級的流程管理類流程領域 目的 關於適用於服務的能力成熟度整合模式 1.2 版 組織流程專注(Organizational Process Focus, OPF)的目 的在於以充份瞭解現行組織流程及流程資產之優點與 缺點為基礎,規劃、執行與推展組織流程改善。 簡介 組織流程專注 組織流程包括組織與專案所使用的所有流程。組織流 程與流程資產的可能改善由不同的來源取得,包括流 程的度量、執行流程的學習心得、流程評鑑的結果、 產品評估活動的結果、以其他組織流程標竿比較的結 果,以及組織中其他改善構想的建議。 流程改善源於組織需要的範圍,以實現組織的目標。 組織鼓勵將要執行流程的人,參與流程改善活動。協 助與管理組織流程改善活動的責任(包括協調其他的 參與),通常指派給流程組。組織應提供長期的承諾 及所需的資源,以支持流程組,以及確保有效與適時 的推展改善。 為了保證整個組織流程改善的投入人力,有充分的管 理與實行,必須要有詳細的規劃。組織流程改善規劃 的成果為流程改善計畫。 組織流程改善計畫說明評鑑規劃、流程行動規劃、試 用規劃及推展規劃。評鑑計畫說明評鑑的時間與時 339 適用於服務的能力成熟度整合模式 1.2 版 程、評鑑的範圍、執行評鑑所需的資源、執行評鑑所 採用的參考模式及評鑑的後勤支援等。 流程行動計畫通常由評鑑的結果導出,並且以評鑑時 所發現的缺點為目標,製作如何執行改善的文件。有 時描述於流程行動計畫中的改善,應該在整個組織推 展前,先在小團體作測試。在此情況下,則會製作試 用計畫。 當要推展改善時,需建立推展計畫,該計畫說明整個 組織何時及如何推展改善。 組織流程資產說明、執行及改善組織流程(「組織流 程資產」的定義,請參考詞彙)。 相關流程領域 有關組織流程資產,請參考組織流程定義流程領域, 以獲得更多的資訊。 特定目標及執行方法摘要 SG 1 決定流程改善機會 SP 1.1 建立組織流程需要 SP 1.2 評鑑組織流程 SP 1.3 界定組織流程改善 SG 2 規劃與執行流程行動方案 SP 2.1 建立流程行動計畫 SP 2.2 執行流程行動計畫 SG 3 推展組織流程資產及彙整經驗 SP 3.1 推展組織流程資產 SP 3.2 推展標準流程 SP 3.3 監督執行 SP 3.4 彙整經驗納入組織流程資產 340 組織流程專注 各目標的特定執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 SG 1 決定流程改善機會 定期與在需要的時候,界定組織流程的優點、缺點與改善機 會。 可經由與流程標準或模式的比較,決定組織流程的優 點、缺點及改善機會。流程標準或模式例如:CMMI 模式或國際標準組織(ISO)的標準。流程改善應該選擇 以實現組織的需要。 SP 1.1 建立組織流程需要 建立並維護組織流程需要及目標的說明。 必須瞭解組織流程運作的經營範圍。組織經營的目 標、需要及限制決定組織流程的需要與目標。重要的 流程考慮項目通常包括:財務、技術、品質、人力資 源及市場等議題。 組織流程的需要與目標,涵蓋下列各方面: • 流程特性 • 流程績效目標,例如:產品上市時間與交付項 目品質 • 流程有效性 典型的工作產品 1. 組織的流程需要及目標 組織流程專注 細部執行方法 1. 界定適用於組織流程的政策、標準及經營目標。 2. 檢查相關的流程標準及模式,以建立最佳執行方 法。 3. 決定組織流程績效目標。 流程績效目標可以用定量或定性的術語表達。 341 適用於服務的能力成熟度整合模式 1.2 版 有關建立度量目標,請參考度量分析流程領域, 以獲得更多資訊。 記錄下來的流程績效目標陳述例子如下: • 客戶滿意度比例 • 週期 • 事故比率 • 生產力 4. 定義組織流程的重要特性。 組織流程的重要特性,根據下列項目來決定: • 組織中正在使用的流程 • 組織所利用的標準 • 組織客戶通常強加的標準 流程特性,舉例如下: • 詳細程度 • 流程符號 • 細部組成 5. 記錄組織流程的需要與目標。 6. 需要時,修訂組織流程的需要與目標。 SP 1.2 評鑑組織流程 定期與在需要的時候,評鑑組織流程,以維護對於流 程優點與缺點的瞭解。 342 組織流程專注 關於適用於服務的能力成熟度整合模式 1.2 版 執行流程評鑑的理由,舉例如下: • 界定出要改善的流程 • 確定進度並且使流程改善的效益顯而易見 • 滿足客戶與供應商關係的需要 • 鼓舞與支援 如果流程評鑑後,沒有接著執行以評鑑為基礎的行動 計畫,則在流程評鑑中所獲得的同意會被嚴重的忽 略。 典型的工作產品 1. 組織流程評鑑的各種計畫 2. 說明組織流程優缺點的評鑑調查報告 3. 組織流程的改善建議 細部執行方法 1. 取得高階管理人員對流程評鑑的贊助。 高階管理人員的贊助包括承諾讓組織的管理人員 及職員參與流程評鑑,並且提供資源及經費以進 行評鑑調查報告的分析與溝通。 2. 定義流程評鑑的範圍。 流程評鑑可在整個組織執行或在組織的一小部分 執行,例如:一個專案或經營領域。 流程評鑑的範圍說明下列各項: • 評鑑所涵蓋的組織定義(例如:地點或經營領域) • 在評鑑中能代表組織的專案與支援功能的界定 • 將接受評鑑的流程 3. 決定流程評鑑的方法與準則。 組織流程專注 343 適用於服務的能力成熟度整合模式 1.2 版 流程評鑑可能以許多形式進行。組織的需要與目 標會隨時間而變更,流程評鑑應滿足組織的需要 及目標。例如:評鑑可依據流程模式,如 CMMI 模式或依據國家或國際標準,如 ISO9001 [ISO 2000]。評鑑也可以用標竿比較的方式與其他組織 作比較,內容係來自界定那些對改善績效有貢獻 的執行方法。。評鑑方法可假設下列各種特性, 包括耗費的時間及工作量、評鑑組的組成,以及 調查的方法與深度。 4. 流程評鑑的規劃、時程安排及準備。 5. 執行流程評鑑。 6. 記錄與交付評鑑活動與調查報告。 SP 1.3 界定組織流程改善 界定組織流程及流程資產的改善。 典型的工作產品 1. 可能的流程改善的分析 2. 組織流程改善的界定 細部執行方法 1. 決定可能的流程改善。 344 組織流程專注 關於適用於服務的能力成熟度整合模式 1.2 版 可能的流程改善,可經由執行下列工作而決定: • 度量流程並分析度量結果 • 審查流程的有效性與合適性 • 評估客戶滿意度 • 審查從客製化的組織標準流程組學到的經驗 • 檢閱調適組織標準流程所得到的學習心得 • 審查組織管理者、職員及其他相關的關鍵人員 提出的流程改善建議 • 向組織高層管理者及其他領導者請求提供對於 流程改善的意見 • 檢查流程評鑑及其他流程相關審查的結果 • 審查其他組織改善構想的結果 2. 決定可能之流程改善的優先順序。 決定優先順序的準則如下: • 考慮執行流程改善的預計成本及人力。 • 評估對照組織改善目標和優先順序的預期改善 成果 • 決定流程改善的潛在障礙,並發展克服這些障 礙的策略。 組織流程專注 345 適用於服務的能力成熟度整合模式 1.2 版 幫助決定可能的改善,並定出執行的優先順序的 技術,舉例如下: • 比較預估成本人力與流程改善效益的成本效益 分析。 • 比較組織目前情況與最佳情況的落差分析 • 可能改善的著力點分析,用以界定流程改善可 能遭遇的障礙及克服這些障礙的策略 • 因果分析,用以提供可比較之不同改善之可能 效果的資訊 3. 界定並記錄要執行的流程改善。 4. 修訂計畫中的流程改善清單,以維持其最新狀 況。 SG 2 規劃與執行流程行動方案 規劃與執行組織流程與流程資產改善的流程活動 成功的執行改善,需要流程負責人(也就是執行流程 及支援組織的人)參與流程行動規劃與執行。 SP 2.1 建立流程行動計畫 建立並維護流程行動計畫,以實行組織流程與流程資 產的改善。 346 組織流程專注 關於適用於服務的能力成熟度整合模式 1.2 版 建立並維護流程行動計畫,通常包括下列各種角 色的參與: • 管理委員會建立策略,並督導流程改善活動 • 流程組協助與管理流程改善活動 • 流程行動組定義並執行改善 • 流程負責人管理推展 • 流程參與人員執行流程 關鍵人員的參與有助於在流程改善中獲得效益,並且 能增進有效推展的可能性。 流程行動計畫是詳細的執行計畫。這些計畫與組織流 程改善計畫不同的地方,在於它們規劃的改善,是以 處理通常於評鑑時發現的缺點為目標 典型的工作產品 1. 組織核准通過的流程行動計畫 細部執行方法 1. 界定策略、方法及行動,以實行已界定的流程改 善。 在彙整成正規使用以前,新的、未經證明的及重 大的變更需先經過試用。 2. 建立流程行動組,負責執行行動。 團隊和成員呈現流程改善的行動被稱“流程行動 團隊"。流程行動團隊通常包括流程的擁有者和 那些呈現流程的人。 3. 製作流程行動計畫。 組織流程專注 347 適用於服務的能力成熟度整合模式 1.2 版 流程行動計畫通常涵蓋下列項目: • 流程改善基礎架構 • 流程改善目標 • 要進行的流程改善 • 規劃及追蹤流程行動的程序 • 試用與執行流程行動的策略 • 執行流程行動的責任及授權 • 執行流程行動的資源、時程及工作指派 • 決定流程行動有效性的方法 • 流程行動計畫的風險 4. 與相關的關鍵人員審查並討論流程行動計畫。 5. 必要時,審查流程行動計畫。 SP 2.2 執行流程行動計畫 執行流程行動計畫。 典型的工作產品 1. 流程行動組之間的承諾 2. 執行流程行動計畫的狀況與結果 3. 試用計畫 細部執行方法 1. 使相關的關鍵人員可容易取得流程行動計畫。 2. 各流程行動組討論和記錄其承諾,如需要並修訂 其行動計畫。 3. 依流程行動計畫追蹤進度及承諾。 4. 與流程行動組及相關的關鍵人員聯合審查流程行 動的進度及結果。 348 組織流程專注 關於適用於服務的能力成熟度整合模式 1.2 版 5. 規劃需要的試用,以測試所選擇的流程改善。 6. 審查流程行動組的活動及工作產品。 7. 對執行流程行動計畫所遭遇的議題加以界定、記 錄及追蹤至結案。 8. 確保執行流程行動計畫的結果能符合組織流程改 善的目標。 SG 3 推展組織流程資產及彙整經驗 在組織中推展組織流程資產,並將流程相關經驗彙整至組織流 程資產中。 此特定目標中的特定執行方法描述持續進行的活動。 每一專案的生命期間,可能出現專案可從組織標準流 程及其變更中獲益的新機會。標準流程及其他組織流 程資產的推展,必須在組織中持續予以支援,特別對 於新專案剛啟動時。 SG 3.1 推展組織流程資產 在組織中推展組織流程資產。 組織流程資產的推展,或是組織流程資產變更的推 展,必須用有次序的方式執行。某些組織流程資產或 流程資產的變更,對組織的某些部門可能不適用(例 如:由於客戶的需求或目前執行的生命週期階段)。 因此,必要時,正在執行流程或即將執行流程的人 員,以及其他組織功能(例如:訓練及品質保證) 的人 員參與推展,是很重要的。 有關組織流程資產的推展,包括組織流程資產庫的支 援,請參考組織流程定義流程領域,以獲得更多的資 訊。 組織流程專注 349 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 在組織中推展組織流程資產及其變更的計畫 2. 推展組織流程資產及其變更的訓練教材 3. 組織流程資產的變更記錄文件 4. 推展組織流程資產及其變更的支援材料 細部執行方法 1. 在組織中推展組織流程資產。 推展時,執行的活動通常包括下列項目: • 界定執行流程人員應採用的組織流程資產。 • 決定如何讓組織流程資產可供使用(例如:藉由 網站) • 界定如何傳達組織流程資產的變更 • 界定支援組織流程資產的使用所需的資源(例 如:方法與工具) • 規劃推展 • 協助使用組織流程資產的人員 • 確定能提供使用組織流程資產人員所需的訓練 有關建立組織訓練能力,參考組織訓練流程領 域,以獲得更多資訊。 2. 記錄組織流程資產的變更。 記錄組織流程資產變更有兩個主要目的: • 使變更能夠傳達 • 瞭解組織流程資產變更與流程績效及結果的關 係 3. 在組織中推展組織流程資產的變更。 350 組織流程專注 關於適用於服務的能力成熟度整合模式 1.2 版 推展變更時,通常包括下列各項活動: • 決定哪些變更適合執行流程的人員 • 規劃部署 • 安排成功轉換流程變更所需的支援 4. 提供組織流程資產使用的指引與諮詢 SP 3.2 推展標準流程 在專案啟動時,推展組織標準流程至專案,並在每一 專案生命全程中,適當的推展變更至專案。 新專案使用已證明且有效的流程,以執行關鍵的早期 活動是重要的(例如:專案規劃、接受需求及取得資 源)。 當對組織標準流程的變更對專案有益時,專案也應該 定期更新已調適流程,以彙整最新的組織標準流程變 更至專案中。定期更新幫助確保所有專案的活動,獲 得其他專案學習心得的全部效益。 有關組織標準流程與調適指引,請參考組織流程定義 流程領域,以獲得更多資訊。 典型的工作產品 1. 組織的專案清單及每一專案流程推展狀況(例如: 現有與規劃的專案) 2. 新專案推展組織標準流程的指引 3. 調適及執行組織標準流程的紀錄 組織流程專注 351 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 界定組織內已啟動的專案。 2. 界定將從執行組織現有標準流程獲益的進行中專 案。 3. 對已界定的專案,建立執行組織現有標準流程的計 畫。 4. 協助專案調適組織標準流程,以符合專案需要。 有關建立專案的調適流程,請參考整合的專案管 理流程領域,以獲得更多資訊。 5. 維護已界定專案調適與執行流程的紀錄。 6. 確保流程調適產生的已調適流程,已納入流程符合 度稽核計畫中。 流程符合度稽核是專案活動依據專案已調適流程 的客觀評估。 7. 當組織標準流程更新時,界定哪些專案應執行變 更。 SP 3.3 監督執行 對所有專案,監督組織標準流程的執行及流程資產的 使用。 藉由監督執行,組織確保組織標準流程與其他流程資 產,適當地推展至所有專案。監督執行也幫助組織瞭 解組織流程資產的使用及在組織中何處使用。監督執 行也幫助建立廣泛的內涵,以解釋與使用流程及產品 度量、學習心得、以及由專案取得的改善資訊。 典型的工作產品 1. 監督專案流程的執行結果 352 組織流程專注 2. 流程符合度稽核的狀況與結果 關於適用於服務的能力成熟度整合模式 1.2 版 3. 審查選定的流程成果(流程調適與執行的部份產出) 的結果 細部執行方法 1. 監督專案使用組織流程資產及其變更。 2. 審查選定的流程結果(每一專案生命期間的產出)。 審查選定的流程結果(每一專案生命期間的產出), 確保所有專案適當的使用組織標準流程。 3. 審查流程符合度稽核的結果,以決定組織標準流程 推展的良窳。 有關客觀地評流程,請參考流程與產品品質保證 流程領域以獲得更多資訊。 4. 界定、記錄與追蹤有關執行組織標準流程的議題至 結案。 SP 3.4 彙整經驗至組織流程資產 納入流程相關的工作產品、度量及導自規劃與執行流 程的改善資訊,至組織流程資產。 典型的工作產品 1. 流程改善建議 2. 流程學習心得 3. 組織流程資產的度量值 4. 組織流程資產的改善建議 5. 組織流程改善活動的紀錄 6. 組織流程資產及其改善的資訊 組織流程專注 353 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 定期審查組織標準流程及相關的組織流程資產相 對於組織經營目標的有效性及適用性。 2. 取得使用組織流程資產的回饋意見。 3. 導出來自於定義、試用、執行及推展組織流程資 產的學習心得。 4. 使組織人員可適當地取得學習心得。 確保能適當地使用學習心得,可能需採取一些行 動。 不適當的使用學習心得,舉例如下: • 評估人員績效 • 判斷流程績效或結果 避免不適當的使用學習心得的方法,舉例如下: • 控制學習心得的取得 • 教育人員如何適當地使用學習心得 5. 分析從組織使用的一組通用的度量所獲得的資料。 有關分析度量資料,請參考度量及分析流程領 域,以獲得更多的資料。 有關建立組織度量儲存庫,請參考組織流程定義 流程領域,以獲得更多的資訊。 6. 評鑑在組織中使用的流程、方法及工具,並發展 用來改善組織流程資產的建議。 354 組織流程專注 評鑑通常包括下列各項: 關於適用於服務的能力成熟度整合模式 1.2 版 • 決定哪些流程、方法及工具,可能用在組織的 其他的部門 • 評鑑組織流程資產的品質與有效性 • 界定組織流程資產的可能改善 • 決定組織標準流程及調適指引的符合程度 7. 使組織中的人員適當地充分運用組織的流程、方 法及工具。 8. 管理流程改善建議。 流程改善建議能夠說明流程與技術改善兩者。 管理流程改善建議的活動,通常包括下列各項: • 徵求流程改善建議 • 收集流程改善建議 • 審查流程改善建議 • 選擇要執行的流程改善建議 • 追蹤流程改善建議的執行 流程改善建議,應適當地以流程變更要求或問題 報告方式做成文件。 有些流程改善建議可彙整納入組織流程行動計 畫。 9. 建立並維護組織流程改善活動的紀錄。 組織流程專注 355 適用於服務的能力成熟度整合模式 1.2 版 組織流程績效 成熟度第四級的流程管理類流程領域 目的 簡介 組織流程績效(Organizational Process Performance, OPP) 的目的在於建立並維護量化模式,以藉此瞭解組織用 於支援達成品質與流程績效目標之標準流程的績效, 並提供流程績效資料、基準及模式,以便以量化方式 管理組織的專案。 流程績效是遵循流程而達成之實際結果的度量,流程 績效以流程度量(例如:工作量、週期時間及缺失移 除的有效性),以及產品度量(例如:可靠度、缺失密 度、能力、反應時間及成本)來描述其特性。 組織的共通度量由流程及產品度量所構成,可用以描 繪組織內個別專案之實際的流程績效。藉由分析度量 結果,建立度量結果的分佈或範圍,以描繪個別專案 執行此流程的預期績效。 在本流程領域,「品質及流程績效目標」這個名詞涵 括產品品質、服務品質及流程績效的目標及需求。如 同上述的概念,「流程績效」一詞包含品質,然而, 為強調品質的重要性,因此使用「品質及流程績效目 標」而不是只使用「流程績效目標」。 預期流程績效可用來設定專案的品質及流程績效目 標,亦可作為與實際專案績效比較的基準。本資訊用 於以量化方式管理專案。每個量化管理的專案依序地 356 組織流程績效 關於適用於服務的能力成熟度整合模式 1.2 版 提供實際的績效結果,以成為組織流程資產之基準資 料的一部分。 流程績效模式用於展現過去及目前的流程績效,並預 測流程的未來結果。例如:在產品驗證活動中所界定 的缺失度量,可用來預測交付產品的潛在缺失。 當組織對各項關鍵流程產品及服務特性具有度量、資 料及分析技術時,就可以進行下列事項: • 決定流程的表現是否具備一致性或有穩定的趨勢 (亦即,具可預測性)。 • 界定績效在常態範圍的流程,此常態範圍在不同 的流程執行團隊是一致的。 • 建立相關的準則,以界定流程或子流程是否應採 統計管理,並決定用於此管理程序的相關度量及 分析技術。 • 界定顯示不正常(例如:偶發或不可預測的)行為 的流程。 • 界定組織標準流程中可改善之處。 • 界定實行最佳之流程。 相關流程領域 有關選擇度量及分析技術以用來管理服務系統的能力 及可利用度,請參考能力與可利用度管理流程領域, 以獲得更多資訊。 有關收集與分析組織能力及其客戶需求的資訊,請參 考策略服務管理流程領域,以獲得更多資訊。 有關指定度量、獲得以及分析度量資料,請參考度量 與分析流程領域,以獲得更多資訊。 組織流程績效 357 適用於服務的能力成熟度整合模式 1.2 版 有關量化管理專案、使用流程績效模式及建立子流程 的試驗自然限制,請參考量化專案管理流程領域,以 獲得更多資訊。 特定及執行方法摘要 SG 1 建立績效基準及模式 SP 1.1 選定流程 SP 1.2 建立流程績效度量 SP 1.3 設定品質及流程績效目標 SP 1.4 建立流程績效基準 SP 1.5 建立流程績效模式 各目標的特定執行方法 SG1 建立績效基準及模式 建立並維護基準及模式,用以描述組織標準流程預期流程績效 的特性。 建立流程績效的基準與模式之前,應先決定哪些流程 適合度量(「選定流程」特定執行方法)、哪些度量對 決定流程績效是有用的(「建立流程績效度量」特定 執行方法),以及這些流程的品質與績效目標(「設定 品質及流程績效目標」特定執行方法)。這些特定執 行方法彼此相互關聯,而且可能需同時執行以選定合 適的流程、度量,以及品質與績效目標。通常流程、 度量或品質與績效目標的選擇都會限定其他兩者的選 擇,例如:選定特定的流程之後,度量及品質與績效 目標的選擇就可能受限於流程本身。 SP 1.1 選定流程 於組織標準流程中,選定將納入組織流程績效分析的 流程或子流程。 358 組織流程績效 關於適用於服務的能力成熟度整合模式 1.2 版 有關組織流程資產結構,請參考組織流程定義流程領 域,以獲得更多資訊。 組織標準流程包含一組標準流程,而標準流程又由眾 多的子流程所組成。 將統計的管理技術應用到組織標準流程的所有流程或 子流程,通常是不可能、沒有效果且不符合經濟效益 的。以組織及專案的需要及目標為基礎,選擇納入量 化流程績效分析的流程或子流程。 選擇流程或子流程作為組織流程績效分析的準 則,舉例如下: • 子流程對主要經營目標的關係 • 目前與子流程相關之有效歷史資料的可利用性 • 目前資料的變動程度 • 子流程穩定性(例如,可比較案例的穩定績效) • 可用以建立預測模型之公司或商業資訊的可用 性 存在指示流程或子流程已穩定或可以穩定之專案資 料,可用來作為選擇流程或子流程的有用準則。 典型的工作產品 1. 納入流程績效分析的流程或子流程清單 SP 1.2 建立流程績效度量 建立並維護納入組織流程績效分析之度量的定義。 有關如何界定度量,請參考度量與分析流程領域,以 獲得更多資訊。 典型的工作產品 1. 所選定流程績效度量的定義 組織流程績效 359 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 決定哪些組織品質與流程績效的經營目標應由哪 些度量來說明。 2. 選定能適當洞察組織品質與流程績效的度量。 目標問題制式範例是一個可以用來選擇度量的方 法,而此度量提供了對組織商業目標的重要意 見。 選擇度量的準則,舉例如下: • 度量與組織經營目標的關聯性 • 提供度量對產品或服務生命期的涵蓋度 • 度量是否能確實表現流程績效 • 度量的可用性 • 度量的客觀程度 • 度量資料的蒐集頻率 • 度量受流程或子流程改變的控制程度 • 度量可用以代表使用者對於有效流程績效觀點 的程度 3. 將所選定的度量納入組織的共通度量。 有關如何建立組織流程資產,請參考組織流程定 義流程領域,以獲得更多資訊。 4. 必要時修訂度量。 SP 1.3 設定品質及流程績效目標 設定並維護組織品質及流程績效的量化目標。 組織的品質與流程績效目標,應具有下列屬性: • 以組織的經營目標為基礎 360 組織流程績效 • 以專案過去的績效為基礎 關於適用於服務的能力成熟度整合模式 1.2 版 • 用以度量流程績效,例如:產品品質、生產力週期 時間或反應時間 • 受限於原有的變異或選定之流程或子流程的常態範 圍 典型的工作產品 1. 組織品質與流程績效目標 細部執行方法 1. 檢視品質與流程績效相關的組織經營目標。 經營目標,舉例如下: • 在特定期間內完成某一特定版本產品的發展工 作。 • 平均回應時間少於特定的服務版本的一段時間 • 在預估成本的目標百分比內,交付產品的功能 • 減少指定百分比的產品維護成本。 • 增加服務系統組件的可利用度至特定的百分比 2. 定義組織品質與流程績效的量化目標 設定流程或子流程度量(例如:工作量、週期時間 及缺失移除的有效性)、產品度量(例如:可靠度及 缺失密度),以及適當服務度量(例如:容量及反應 時間)的目標。 組織流程績效 361 適用於服務的能力成熟度整合模式 1.2 版 品質與流程績效目標,舉例如下: • 達成指定的生產力。 • 交付少於指定之潛在缺失數的工作產品。 • 在流程績效基準的指定+/-5 百分比內,縮短交付 時程。 • 減少現有及新產品的整個生命週期成本達百分 之 15。 • 交付百分之百產品指定的功能。 • 達成服務系統組件的特定可利用度。 • 減少回應時間至特定的百分比 • 改善服務層級協議績效至特定的百分比 3. 定義組織品質與流程績效目標的優先順序。 4. 與相關的關鍵人員審查和協商組織品質與流程績 效目標及其優先順序,並取得其承諾。 5. 必要時修訂組織品質與流程績效的量化目標。 組織品質與流程績效量化目標的修訂時機,舉例 如下: • 當組織經營目標改變時 • 當組織流程改變時 • 當實際的品質與流程績效與目標有極大差異時 SP 1.4 建立流程績效基準 建立並維護組織流程績效基準。 組織流程績效基準是組織標準流程之不同詳細程度的 績效度量,這些流程包括: • 相聯流程的次序 362 組織流程績效 • 涵蓋整個專案的流程 • 發展個別工作產品的流程 關於適用於服務的能力成熟度整合模式 1.2 版 組織可能需要多套的流程績效基準,以描述組織次團 體績效的特性。 用以分類組織次團體的準則,舉例如下: • 產品線 • 經營種類 • 應用領域 • 複雜度 • 團隊規模大小 • 工作產品規模大小 • 從組織標準流程選出的流程元件 組織標準流程所容許的調適,可能會顯著影響納入流 程績效基準資料的相容性,調適的結果應列入建立基 準的考量。根據容許的調適,績效基準可能分別針對 每一種調適種類。 有關量化管理專案、使用流程績效模式及建立子流程 的試驗自然限制,請參考量化專案管理流程領域,以 獲得更多資訊。 典型的工作產品 1. 組織流程績效的基準資料 細部執行方法 1. 從組織各專案蒐集度量結果。 組織流程績效 363 適用於服務的能力成熟度整合模式 1.2 版 度量時正在使用的流程或子流程應加以記錄,以 便日後可適當的使用此紀錄。 有關界定度量資料是如何獲得與儲存,請參考度 量與分析流程領域,以獲得更多資訊。 2. 從蒐集的度量資料及分析結果,建立並維護組織 的流程績效基準。 有關結合度量和分析活動,以及提供度量結果, 請參考度量及分析流程領域,以獲得更多資訊。 流程績效基準係由分析蒐集的度量資料,以建立 結果的分佈或範圍所衍生而來,其描述組織的專 案,在使用選定流程或子流程的預期績效。 應盡可能使用專案之穩定子流程所取得的度量結 果,其他資料可能不可靠。 3. 與相關關鍵人員審查組織流程績效基準,並達成 協議。 4. 將組織流程績效資訊納入組織度量儲存庫,以供整 個組織使用。 專案可使用組織流程度量基準,以估計流程績效 的常態範圍。 有關如何建立組織度量儲存庫,請參考組織流程 定義流程領域,以獲得更多資訊。 5. 比較組織流程績效基準與相關的目標。 6. 必要時修訂組織流程績效基準。 364 組織流程績效 關於適用於服務的能力成熟度整合模式 1.2 版 組織流程績效基準的修訂時機,舉例如下: • 當流程改變時 • 當組織的結果改變時 • 當組織的需要改變時 • 當供應商流程改變時 • 當供應商改變時 SP 1.5 建立流程績效模式 建立並維護組織標準流程的流程績效模式。 配合其他流程、產品及服務度量獲得的數值,流程績 效模式可用來估計或預測一個流程績效度量的數值。 這些流程績效模式,通常使用由整個專案執行過程所 蒐集的流程及產品度量數值,來推估非到專案執行過 程後段才能度量的目標達成進度。 流程績效模式之使用如下: • 組織運用它們以估計、分析及預測與組織標準流程 相關的變更流程之流程績效。 • 組織運用它們以評量組織改善活動的(潛在)投資報 酬。 • 專案運用它們以估計、分析及預測其已調適流程的 流程績效。 • 專案運用它們以選擇使用的流程或子流程。 這些度量及模式用來提供必要的洞察力及能力,以預 測對經營有價值的關鍵流程及產品特性。 組織流程績效 365 適用於服務的能力成熟度整合模式 1.2 版 模式可能有用的專案相關領域,舉例如下: • 時程及成本 • 可靠度 • 缺失界定及移除比率 • 缺失移除有效性 • 潛在的缺失估計 • 反應時間 • 專案進度 • 上述領域的組合 • 服務系統可供應度 流程績效模式,舉例如下: • 系統動態模式 • 可靠度成長模式 • 複雜度模式 有關量化管理專案、使用流程績效模式及建立子流程 的試驗自然限制,請參考量化專案管理流程領域,以 獲得更多資訊。 典型的工作產品 1. 流程績效模式 細部執行方法 1. 以組織標準流程及組織流程績效基準為基礎,建 立流程績效模式。 2. 以組織過去的結果及目前的需要為基礎,調整流 程績效模式。 366 組織流程績效 關於適用於服務的能力成熟度整合模式 1.2 版 3. 與相關關鍵人員審查流程績效模式,並達成協 議。 4. 支持流程績效模式在專案的運用。 5. 必要時修訂流程績效模式。 流程績效模式的修訂時機,舉例如下: • 當流程改變時 • 當組織的結果改變時 • 當組織的需要改變時 組織流程績效 367 適用於服務的能力成熟度整合模式 1.2 版 組織訓練 成熟度第三級的流程管理類流程領域 目的 組織訓練(Organizational Training, OT)的目的在於發展 人員的技能與知識,使其有效執行他們的任務。 簡介 組織訓練包括兩方面的訓練:一是支援組織策略性經 營目標的訓練,一是滿足專案與支援團隊共同需要的 實務訓練。個別專案與支援團隊階層負責處理其界定 的訓練需要,而且不包含在組織訓練範圍之內。專案 與支援團隊負責界定及提出他們的訓練需要。 有關專案所需的知識和技能,請參考專案規劃流程領 域,以獲得更多的資訊。 組織訓練計畫包括下列各項活動: • 界定組織所需要的訓練 • 取得並提供訓練以滿足需要 • 建立並維護訓練能力 • 建立並維護訓練紀錄 • 評量訓練成效 有效的訓練需要對需求、規劃、教學設計及適當訓練 媒體 (例如:規範手冊、電腦軟體) 進行評量,並需要 一訓練流程資料的儲存庫。如同組織流程一樣,訓練 的主要元件包括一套被管理的訓練發展計畫、計畫 書、具訓練與其他知識領域的專精人員,以及用以度 量訓練計畫成效的機制。 368 組織訓練 關於適用於服務的能力成熟度整合模式 1.2 版 流程訓練需求主要根據執行組織標準流程所需的技能 來界定。 有關標準流程,請參考組織流程定義流程領域,以獲 得更多的資訊。 某些技能可有效的透過課堂以外的方式傳授(例如: 非正式的顧問指導),其他技能則需要較正規的訓練 方式(例如:課堂教學、網路教學、自修或正式的在 職訓練計畫等)。以訓練需求與需解決之績效落差的 評量為基礎,採用正規或非正規的訓練方式。本流程 領域所使用的「訓練」字眼,泛指正規或非正規訓練 方式的學習活動。 依據企業執行新的或正在進行的活動中,應用訓練所 獲取的技能與知識的有用性來度量訓練成功與否。 技能與知識可以是技術的、組織的或人際關係的。技 術性技能是指專案或流程所需之設備、工具、材料、 資料及流程的使用能力。組織技能是指依據員工的組 織結構、角色與責任,以及一般性運作原則與方法有 關的行為。人際關係技能是指專案及支援團隊在組織 及社會關係中,成功執行所需的自我管理、溝通及人 際關係的能力。 「專案及支援團隊」一詞,經常使用於流程領域的敘 述,用來指明組織階層的觀點。 相關流程領域 有關使用正式的評估流程以評估已界定的替代方案是 否符合已建立準則,來分析可能的決策,請參考決策 分析與解決方案流程領域,以獲得更多的資訊。 組織訓練 369 適用於服務的能力成熟度整合模式 1.2 版 有關組織流程資產,請參考組織流程定義流程領域, 以獲得更多資訊。 有關規劃所需的知識和技能,請參考專案規畫流程領 域,以獲得更多資訊。 特定目標及執行方法摘要 SG 1 建立組織訓練能力 SP 1.1 建立策略性訓練需求 SP 1.2 決定哪些訓練需求是組織的責任 SP 1.3 建立組織訓練的實施計畫 SP 1.4 建立訓練能力 SG 2 提供必要的訓練 SP 2.1 實施訓練 SP 2.2 建立訓練紀錄 SP 2.3 評量訓練成效 各目標的特定執行方法 SG 1 建立組織訓練能力 建立與維護用以支援組織之管理與技術任務的訓練能力。 組織應界定訓練需求,以增進執行企業活動必要的技 能與知識。一旦需求被界定,即可提出滿足這些需求 的訓練計畫。 SP 1.1 建立策略性訓練需求 建立並維護組織的策略性訓練需求。 藉由彌補重大知識的落差、引用新技術或實施重大行 為變更,策略性訓練需要說明長期的目標,以建立能 力。策略性規畫通常往後看二至五年。 370 組織訓練 組織訓練 關於適用於服務的能力成熟度整合模式 1.2 版 策略性訓練需求的來源,舉例如下: • 組織的標準流程 • 組織的策略性經營計畫 • 組織的流程改善計畫 • 企業層級的想法 • 技術評量 • 風險分析 • 採購及供應商管理 典型的工作產品 1. 訓練需求 2. 評量分析 細部執行方法 1. 分析組織的策略性經營目標與流程改善方案,以 界定未來潛在的訓練需求。 2. 記錄組織的策略性訓練需求。 訓練需求的種類,舉例如下(但不限於所舉範例): • 流程分析與文件製作 • 工程(例如:需求分析、設計、測試、建構管理 及品質保證) • 服務交付 • 供應商的選擇與管理 • 管理(例如:估計、追蹤及風險管理) • 災難復原與運作的持續性 3. 決定實施組織標準流程所需的角色與技能。 371 適用於服務的能力成熟度整合模式 1.2 版 4. 記錄組織標準流程中各角色所需的訓練。 5. 記錄維護安全、保全及持續經營運作所需的訓 練。 6. 必要時,修訂組織的策略性需求及所需的訓練。 SP 1.2 決定哪些訓練需求是組織的責任 決定哪些訓練需求是組織的責任,以及哪些是個別專 案或支援團隊的責任。 有關規劃所需的知識和技能,請參考專案規畫流程領 域,以獲得更多資訊。 組織訓練除了滿足策略性訓練需求外,同時也要滿足 跨專案與支援團隊的共同訓練需求。專案及支援團隊 的主要責任,是界定與提出他們的特定訓練需求。組 織訓練的工作人員,僅須負責提出跨專案及支援團隊 的共同訓練需求,例如:多專案共同的工作環境訓 練。然而,有些情況是在訓練資源允許及組織訓練優 先的前提下,在組織訓練的工作人員與專案及支援團 隊協商後,可能會提出額外的訓練需求。 典型的工作產品 1. 專案與支援團隊的共同訓練需求 2. 訓練承諾 細部執行方法 1. 分析由專案與支援團隊所界定的訓練需求。 專案與支援團隊需求的分析意指界定能夠最有效 滿足整個組織的共同訓練需求,這些需求分析的 活動,通常是先從專案與支援團隊階層中,察覺 到未來的訓練需求。 2. 與專案和支援團隊協調如何滿足他們的訓練需 求。 372 組織訓練 關於適用於服務的能力成熟度整合模式 1.2 版 在訓練資源允許及組織訓練優先的前提下,由組 織訓練的工作人員提供支援。 適合由專案或支援團隊執行的訓練,舉例如下: • 專案應用或服務領域的訓練 • 專案或支援團隊所使用之特殊工具與方法的訓 練 • 安全、保全與人際關係的訓練 3. 記錄將提供予專案與支援團隊的訓練承諾。 SP 1.3 建立組織訓練的實施計畫 建立並維護組織訓練的實施計畫。 組織訓練的實施計畫是與訓練內容和組織責任相關的 計畫,對個人有效的執行其角色是必要的。此一計畫 解決短期訓練的執行,會因應相關因素的變化(如需 求或資源)與訓練成效的評估而進行週期性的修訂。 典型的工作產品 1. 組織訓練實施計畫。 細部執行方法 1. 建立計畫的內容。 組織訓練 373 適用於服務的能力成熟度整合模式 1.2 版 組織訓練實施計畫,通常包含下列內容: • 訓練需求 • 訓練主題 • 以訓練活動及其相依性為基礎的時程表 • 訓練所使用的方法 • 訓練教材的需求與品質標準 • 訓練工作項目、角色及責任 • 所需的資源,包括:工具、設備、環境、人 員、技能與知識。 2. 建立對計畫的承諾。 為使計畫有成效,有必要記錄負責執行與支援計 畫人員的承諾。 3. 必要時,修訂計畫與承諾。 SP 1.4 建立訓練能力 建立並維護訓練能力,以滿足組織的訓練需求。 有關使用正式的評估流程以評估已界定的替代方案是 否符合已建立準則,來分析可能的決策,請參考決策 分析與解決方案流程領域,以獲得更多的資訊。 典型的工作產品 1. 訓練教材與支援物品 細部執行方法 1. 選擇適當的方法,以滿足組織訓練需求。 許多因素可能會影響訓練方法的選擇,包括聽眾 特定的知識、成本與時程,以及工作環境。選擇 374 組織訓練 關於適用於服務的能力成熟度整合模式 1.2 版 方法時,必須考量在既定的限制下,提供最有效 的技能與知識的方法。 訓練方法,舉例如下: • 教室訓練 • 電腦輔助教學 • 自修 • 正式的師徒傳授課程 • 視訊教學 • 用圖解說明的演講 • 午餐討論會 • 有系統的在職訓練 2. 決定內部自行發展或自外部取得教材。 決定內部發展訓練及自外部取得訓練的成本與效 益。 可用以決定獲取知識、技能最有效率方式的準 則,舉例如下: • 績效目標 • 準備專案執行的可利用時間 • 經營目標 • 內部專業人才的可用性 • 外部訓練來源的可用性 組織訓練 375 適用於服務的能力成熟度整合模式 1.2 版 外部訓練來源,舉例如下: • 客戶提供的訓練 • 可取得的商業化訓練課程 • 學術課程 • 專業研討會 • 專題討論會 3. 發展或取得訓練教材。 訓練可由專案、支援團隊、組織或外部組織來提 供。無論提供來源為何,組織訓練的工作人員, 應協調訓練的取得與實施。 訓練教材,舉例如下: • 課程內容 • 電腦輔助教學 • 教學錄影帶 4. 培訓或尋求合格講師。 為確保由組織內部訓練講師具備必需的知識與教 學技能,可訂定發掘、培訓、評定內部講師的準 則。若為外部訓練,組織訓練的工作人員可以檢 視該外部機構如何選定講師人選。選定講師的方 式也可做為選取或持續引用外部訓練機構的因素 之一。 5. 於組織訓練課程中,說明訓練內容。 376 組織訓練 關於適用於服務的能力成熟度整合模式 1.2 版 每個課程在訓練說明中所提供的資訊,舉例如 下: • 訓練涵蓋的主題 • 預期的訓練對象 • 參加訓練的必備條件與準備事項 • 訓練目標 • 訓練期間 • 課程計畫 • 課程的完成準則 • 允許訓練豁免的準則 6. 必要時,修訂訓練教材與支援物品。 訓練教材與支援物品可能需修訂的時機,舉例如 下: • 訓練需求改變(例如:與訓練主題相關的新技術 可取得時) • 訓練的評估結果界定出變更需求(例如:訓練成 效調查、訓練計畫績效評量或教學評量表的評 估) SG 2 提供必要的訓練 提供個人必要的訓練,使其能有效地執行任務。 當選擇受訓人員時,應考量下列事項: 組織訓練 377 適用於服務的能力成熟度整合模式 1.2 版 • 參與受訓目標人選的背景 • 受訓的必備資格 • 人員執行任務所需的技能與能力 • 針對跨專業的技術管理訓練需求,包括專案管 理 • 管理人員接受適當組織流程訓練的需求 • 對安排特定工程領域基本工作方式,以支援人 員的品質管理、建構管理及其他相關支援功能的 訓練需求 • 提供關鍵功能領域之發展能力的需求 • 維護個人能力與資格,以運作與維護對眾多專 案共同的工作環境。 SP 2.1 378 實施訓練 依據組織的訓練實施計畫提供訓練。 典型的工作產品 1. 實施的訓練課程 細部執行方法 1. 選擇需有效率行使角色的人員接受訓練。 訓練的目的是要傳授知識與技能予組織內執行各 種任務的人員。某些人已擁有必須圓滿執行指定 任務所必要的知識與技能。對於這些人而言,可 以免除訓練,但應小心謹慎,避免訓練豁免權被 濫用。 2. 排定訓練時程,包括任何必要的資源(如設備及講 師)。 組織訓練 關於適用於服務的能力成熟度整合模式 1.2 版 訓練應規劃和排定時程。訓練的提供,對預期的 工作績效有直接影響。因此,最佳的訓練對於預 期的工作績效有立竿見影的效果。 這些績效期望常包含下列: • 使用特定工具的訓練 • 人員如何執行新程序的訓練 3. 進行訓練。 訓練應由有經驗的講師執行。如果可以的話,訓 練應在非常類似實際的執行情況下實施,並包括 活動以模擬實際的工作情況。此方法包括用以發 展能力之工具、方法及程序的整合。訓練應與工 作責任結合,如此一來,在職的活動或其他外來 的經驗,在訓練辦理後合理的時間內,將可強化 其訓練。 4. 追蹤訓練是否依計畫進行。 SP 2.2 建立訓練紀錄 建立並維護組織訓練的紀錄。 本執行方法適用於組織層級所執行的訓練。對於專案 或支援贊助之訓練紀錄的建立及維護,由個別專案或 支援團隊負責。 典型的工作產品 1. 訓練紀錄 2. 更新於組織儲存庫的訓練 組織訓練 細部執行方法 1. 對於每項訓練課程或其他核准的訓練活動,保存 所有完成與未完成訓練的學員紀錄。 2. 保存所有豁免訓練之人員的紀錄。 379 適用於服務的能力成熟度整合模式 1.2 版 允許豁免訓練的理由必須加以記錄;學員必須取 得負責經理及其直屬經理的核准才可豁免訓練。 3. 保存所有成功完成必要訓練的學員紀錄。 4. 讓適當人員可取得訓練紀錄,作為指派工作的考 量。 訓練紀錄可以做為訓練組織所發展之技能資料表 的一部分,以提供人員經驗及教育的彙整,以及 組織所負責的訓練。 SP 2.3 評量訓練成效 評量組織訓練計畫的成效。 應存在決定訓練成效的流程(即:訓練是如何符合組 織的需求)。 評量訓練成效的方法,舉例如下: • 受訓內容的測驗 • 受訓後對受訓人員的調查 • 經理對受訓後效果的滿意度調查 • 教育軟體內建的評量機制 針對專案與組織目標,訓練所產生的附加價值可用度 量來評量,不同訓練方法的需求也必須加以注意,例 如:將訓練團隊視為一個整體的工作單位。當實行度 量時,績效目標應與課程參與者分享,且為清楚、顯 著及可驗證的。訓練成效評量的結果應用以修訂上述 「建立訓練能力」特定執行方法所述的訓練教材。 典型的工作產品 1. 訓練成效調查 2. 訓練計畫績效評量 380 組織訓練 3. 教學評估表 4. 訓練測驗 關於適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 評量進行中或已完成專案,以決定人員知識是否 足以完成專案工作。 2. 針對已建立的組織、專案或個人學習(或績效)目 標,提供評量每一訓練課程成效的機制。 3. 取得學員有關訓練活動是否符合其需求的評估。 組織訓練 381 適用於服務的能力成熟度整合模式 1.2 版 專案監控 成熟度第二級的專案管理類流程領域 目的 簡介 專案監控(Project Monitoring and Control, PMC)的目的 在瞭解專案進度,以便在專案執行績效嚴重偏離專案 計畫時,可採取適當的矯正措施。 文件化的專案計畫是監控各項活動、溝通狀態及採取 矯正措施的基礎。專案進度主要決定於工作產品、工 作屬性、工作量,以及成本的實際值與規定於里程碑 或專案時程之控制階層或分工結構圖(WBS)之規劃值 的比較結果。當專案執行績效重大偏離原訂計畫時, 適當的專案進度能見度可促使採取及時的矯正措施。 如果重大偏離未解決,則會阻礙專案達成目標。 這些執行方法使用「專案計畫」一詞,以代表管制專 案的全盤計畫。 當專案實際狀況重大偏離預期值時,應適當地採取矯 正措施。上述措施可能需要重新進行專案規劃,而重 新規劃可能包括修訂原計畫、訂定新的協議,或在現 行計畫中增加額外的降低活動。 相關流程領域 382 有關監督與分析能力和可利用度,參考能力與可利用 管理流程領域,以獲得更多資訊。 有關提供度量結果,參考度量與分析流程領域,以獲 得更多資訊。 專案監控 關於適用於服務的能力成熟度整合模式 1.2 版 有關發展專案計畫,參考專案規劃流程領域,以獲得 更多資訊。 特定目標及執行方法摘要 SG 1 依計畫監控專案 SP 1.1 監控專案規劃之各項參數 SP 1.2 監控承諾事項 SP 1.3 監控專案風險 SP 1.4 監控資料管理 SP 1.5 監控關鍵人員的參與 SP 1.6 進行進度審查 SP 1.7 進行里程碑審查 SG 2 管理矯正措施直到結案 SP 2.1 分析議題 SP 2.2 採取矯正措施 SP 2.3 管理矯正措施 各目標的特定執行方法 SG 1 依計畫監控專案 依專案計畫監控專案實際執行績效與進度。 SP 1.1 監控專案規劃之各項參數 依專案計畫監控專案規劃參數之實際值。 專案規劃參數構成專案進度與執行績效的代表性指 標,它包含工作產品與工作項目、成本、工作量、時 程等參數之屬性。工作產品與工作項目的屬性包含規 模大小、複雜度、重量、形狀、安裝或功能等。 專案監控 383 適用於服務的能力成熟度整合模式 1.2 版 要考慮的參數應該包括監督的頻率。頻率的考量可以 包括監督每一個服務需求或事故的可能需求,以及其 甚至可能持續監督持續的交付服務。 監控通常包含度量專案規劃參數的實際值、比較實際 值與計畫的估計值,以及界定其重大偏離。記錄專案 規劃參數的實際值包含記錄前後相關的資訊,以協助 對度量的瞭解。分析重大偏離的影響,以決定須採取 之矯正措施是屬於本流程領域的第二個特定目標及其 特定執行方法。 典型的工作產品 1. 專案執行績效的紀錄 2. 重大偏離的紀錄 細部執行方法 1. 依時程表監控專案進度。 進度監控通常包含: • 定期度量活動與里程碑的實際完成度 • 將活動與里程碑的實際完成度,與專案計畫時 程比較 • 界定與專案計畫的經費與時程預估之重大偏 差。 2. 監控專案的成本與耗用人力。 384 專案監控 專案監控 關於適用於服務的能力成熟度整合模式 1.2 版 耗用人力與成本的監控,通常包括: • 定期度量實際耗用的人力與成本,以及成員指 派 • 將實際的投入人力、成本、人員配置與訓練, 與專案計畫預算及各項估計進行比較 • 界定與專案計畫之預算及時程的重大偏差 3. 監控工作產品與工作項目的屬性。 有關發展與維持度量能力以支援管理資訊的需 要,請參考度量與分析流程領域,以獲得更多資 訊。 有關工作產品與工作項目屬性的預測,請參考專 案規劃流程領域,以獲得更多資訊。 監控工作產品及工作項目之屬性,通常包括: • 定期度量工作產品與工作項目的實際屬性,例 如:規模大小或複雜度(及屬性的變更) • 將實際工作產品與工作項目的屬性(含屬性的變 更),與專案計畫的各項估計值互相比較 • 界定與專案計畫的各項估計值之重大偏差 4. 監控所提供與使用的資源。 有關監督和分析能力,參考能力與可利用度管理 流程領域,以獲得更多資訊。 有關規劃專案資源,參考專案規劃流程領域,以 獲得更多資訊。 385 適用於服務的能力成熟度整合模式 1.2 版 資源的例子如下: • 實際的設施 • 電腦、週邊設備、設計使用的軟體、製造、測 試及運作 • 網路 • 安全的環境 • 專案人員 • 流程 5. 監控專案人員的知識與技能。 有關規劃所需的知識與技能,請參考專案規劃流 程領域,以獲得更多資訊。 監控專案人員的知識與技能,通常包括: • 定期度量專案人員知識與技能的獲得狀況 • 將實際獲得的訓練,與專案計畫所記載的互相 比較 • 界定與專案計畫之估計值的重大偏差 6. 記錄專案規劃參數的重大偏差。 SP 1.2 監控承諾事項 依專案計畫監控所界定的承諾。 典型的工作產品 1. 承諾審查紀錄 細部執行方法 1. 定期審查承諾(包含外部及內部的)。 2. 界定尚未滿足或有重大風險以致無法滿足的承諾。 386 專案監控 3. 記錄承諾審查的結果。 關於適用於服務的能力成熟度整合模式 1.2 版 SP 1.3 監控專案風險 依專案計畫監控所界定的風險。 有關界定專案風險,請參考專案規劃流程領域,以獲 得更多資訊。 有關在潛在的問題發生前加以界定,以當產品或專案 週期中需要時,能規劃及啟動風險處理活動,減輕在 達成目標可能產生的反面影響,參考風險管理流程領 域,以獲得更多資訊。 典型的工作產品 1. 專案風險監控紀錄 細部執行方法 1. 在專案目前所處之情況及環境下,定期審查記載 風險的文件。 一個例子是風險狀態的改變可能對運作持續的一 項威脅,或來自最終使用者對一項平均綜合的服 務需求型態的改變。如果風險已變得比較可能或 可能的影響較嚴重,則需要矯正措施。 2. 當有新增資訊時,修訂風險文件。 當專案進度(特別是長時間的或持續的運作)、 新風險產生及對這些新風險的界定、分析和規劃 適當的回應(或減輕)是重要的。例如,軟體、 設備及使用的工具可能被淘汰;或主要的人員可 能在專案或組織的某個長期的重要領域逐漸地喪 失技能。界定、分析和說明這些新的風險。 3. 與相關關鍵人員溝通風險狀態。 專案監控 387 適用於服務的能力成熟度整合模式 1.2 版 風險狀態,舉例如下: • 風險發生機率的改變 • 風險優先順序的改變 SP 1.4 監控資料管理 依專案計畫監控專案資料的管理。 有關界定應管理的資料類型及如何規劃其管理,請參 考專案規劃流程領域的「規劃資料管理」特定執行方 法,以獲得更多資訊。 資料管理活動應該被監督,以確保資料管理需求能被 滿足。依照專案需求、情形或狀態的監督及改變結 果,它可能需要重新規劃專案的資料管理活動。 典型的工作產品 1. 資料管理紀錄 細部執行方法 1. 定期審查資料管理活動,是否依專案計畫所述。 2. 界定與記錄重大議題及其影響。 關於顯著議題的一個例子是,當關鍵人員無法存 取專案資料,而需要實現他們的角色為相關的關 鍵人員。 3. 記錄資料管理活動審查的結果。 SP 1.5 監控關鍵人員的參與 依專案計畫監控關鍵人員的參與。 有關界定相關的關鍵人員及規劃他們適當的參與,請 參考專案規劃流程領域的「規劃關鍵人員之參與」特 定執行方法,以獲得更多資訊。 388 專案監控 關於適用於服務的能力成熟度整合模式 1.2 版 關鍵人員的參與應該被監督,以確保有適合的反應。 端視對專案需求、情形或狀態的監督與改變結果,它 可能需要再規劃關鍵人員的參與。 典型的工作產品 1. 關鍵人員參與的紀錄 細部執行方法 1. 定期審查關鍵人員參與的情形。 2. 界定與記錄重大議題及其影響。 3. 記錄關鍵人員參與情形審查的結果。 SP 1.6 進行進度審查 定期審查專案的進度、執行績效及議題。 專案進度是在特定的時間檢視專案進度,由關鍵人員 檢視(特別專案的代表及專案管理人員)專案活動到 目前為止的呈現及其結果及影響,以決定是否有顯著 的議題或績效的不足需要說明。 進度審查是用以使關鍵人員瞭解狀況的專案審查。 這些專案審查可為非正式的,且可能未在專案計畫中 明確說明。 典型的工作產品 1. 專案審查結果紀錄 細部執行方法 1. 定期與相關關鍵人員,溝通所指派之活動與工作 產品的狀態。 審查人員可適當地包含:管理者、專案成員、 客戶、最終使用者、供應商及組織內其他相關 關鍵人員。 專案監控 389 適用於服務的能力成熟度整合模式 1.2 版 2. 審查度量之蒐集與分析的結果,以控制專案。 度量審查包括收集在專案規劃中已界定的服務 參數度量(例如,可利用度、使用者數量), 可以包括為客戶滿意度收集的度量。 有關結合度量與分析活動及提供度量結果,參 考度量與分析流程領域,以獲得更多資訊。 3. 界定與記錄重大議題以及與專案計畫的偏差。 4. 記錄工作產品與流程所發現的變更要求與問題。 有關追踪及管控變更,請參考建構管理流程領 域,以獲得更多資訊。 5. 記錄審查的結果。 6. 追蹤變更要求和問題報告直到結案。 SP 1.7 進行里程碑審查 於專案里程碑,審查專案的完成情形及執行結果。 有關提供度量結果,參考度量和分析流程領域,以獲 得更多資訊。 有關界定主要的里程碑,請參考專案規劃流程領域, 以獲得更多資訊。 執行狀態的整體審查的里程碑預先規劃的事件或次數 是為了要瞭解如何符合關鍵人員的需求。(如果專案 包括發展的里程碑,那麼執行審查是為了確保符合伴 隨里程碑的假設和需求)。里程碑可以伴隨整體專案 或特定的服務型態或事件。里程碑因此可能是以事件 為基礎或以日曆天為基礎。 里程碑審查應在專案規劃時予以規劃,且通常為正式 的審查。 390 專案監控 關於適用於服務的能力成熟度整合模式 1.2 版 進度審查和里程碑審查不需分別舉辦。一個單一的審 查可以說明二者的內容。例如,一個單一的規劃前審 查能評估一段依照計畫期望規劃完成的時間(或里程 碑)的進度、議題和績效。 典型的工作產品 1. 里程碑審查結果紀錄 細部執行方法 1. 在專案時程的重要時間點(如階段的完成),與相關 的關鍵人員進行里程碑審查。 審查人員可適當地包含:管理者、專案成員、客 戶、最終使用者、供應商及組織內其他相關關鍵 人員。 2. 審查專案的承諾、計畫、狀態及風險。 審查可以包括為收集客戶滿意度度量的分析。 3. 界定並記錄重大議題及其影響。 4. 記錄審查、行動項目及決策的結果。 5. 追蹤行動項目直到結案。 SG 2 管理矯正措施直到結案 當專案的執行績效或結果重大偏離計畫時,管理矯正措施直到 結案。 SP 2.1 分析議題 蒐集與分析議題,並決定採取必要的矯正措施以解決 議題。 專案監控 391 適用於服務的能力成熟度整合模式 1.2 版 這項分析是為不同的目的而呈現,且通常是不同的議 題,比起事故分析、問題分析或改變需求分析等部分 的分析呈現。然而,相同的或類似的用來分析的機制 以分析議題的型態,管理它們直到結案。是否執行一 個通用的解決方案以用做分析和管理直到結案,端視 無法適當處理和替代解決方案重複發生的成本的風 險。 典型的工作產品 1. 需要採取矯正措施的議題清單 細部執行方法 1. 蒐集議題,以備分析之用。 從審查及其他流程的執行,蒐集議題。 蒐集的議題,舉例如下: • 經由執行驗證與確認活動所發現的議題 • 專案計畫估計值中,專案規劃參數的重大偏離 • 尚未滿足的承諾(內部或外部的) • 風險狀態的重大改變 • 資料存取、蒐集、隱私或安全的議題 • 關鍵人員的代表性或參與的議題 • 在變得明顯前累計重複的差異,但其解決方案 應該加以說明 • 產品、工具或環境移轉的假設(或其他客戶或 供應商的承諾)尚未達成 2. 分析議題,以決定採取矯正措施的必要性。 392 專案監控 關於適用於服務的能力成熟度整合模式 1.2 版 有關矯正措施標準,請參考專案規劃流程領域, 以獲得更多資訊。 當議題懸而未決並可能妨礙專案達成其目標時, 應採取矯正措施。 SP 2.2 採取矯正措施 對界定的議題,採取矯正措施。 專案監控 典型的工作產品 1. 矯正措施計畫 細部執行方法 1. 決定並記錄須採取的適當行動,來解決已界定的 議題。 有關發展專案計畫,參考專案規劃流程領域,以 獲得更多資訊。 可能的矯正措施,舉例如下: • 修改工作說明書 • 修改需求 • 修訂估計值與計畫 • 再協商承諾事項 • 增加資源 • 變更流程 • 修訂專案風險 2. 與相關關鍵人員,審查將採取的矯正措施,並取 得協議。 393 適用於服務的能力成熟度整合模式 1.2 版 3. 協商內部與外部承諾的改變。 SP 2.3 管理矯正措施 管理矯正措施直到結案。 典型的工作產品 1. 矯正措施結果 細部執行方法 1. 監控矯正措施直到完成。 有關監督事故到結案的狀態,參考事故解決方案 及預防流程領域,以獲得更多資訊。 2. 分析矯正措施的結果,以決定矯正措施的有效 性。 3. 決定並記錄適當行動,以修正矯正措施與規劃結 果的偏離。 矯正措施的實施學習心得,可以作為規劃與風險 管理流程的輸入。 394 專案監控 專案規劃 成熟度第二級的專案管理類流程領域 關於適用於服務的能力成熟度整合模式 1.2 版 目的 簡介 專案規劃 專案規劃(Project Planning, PP)的目的,在建立並維護 用以定義專案活動的計畫。 在能力與成熟度管理整合中,“專案"一詞的定義是 廣泛的,如此一來,使用這個術語的執行方式得以適 當地廣泛應用。“專案"一詞是關於一組投入規劃、 監督及執行已調適的流程人及資源,以共同達成一組 目的。這些目的包括(或可以從中衍生)商業的目 標,但可以包括伴隨客戶的目標,雖然專案起始時可 能未經客戶界定(或現行的服務協議)。 上述對專案的定義包括那些有企圖終結所做的努力 (例如發展產品,在服務協議中有特定的結束日期下 交付服務)。以及那些組織不想結束的部份(例如, 提供健保,在社區中提供火警安全服務)。有些人不 習慣對專案一詞的廣泛解釋,以及習慣性地限制它使 用在已調適的結束點的那些努力。然而,對CMMI 的流程領域、目標及執行方式的持續努力完全與傳統 專案所需重疊。因此,CMMI模式使用單一術語 “專案"包含二種型態的努力,就是避免不必要的區 分和模式組件間的重複。 專案可以由多種專案組成,在這類的例子,CMMI 專案相關的執行方式也應用到這些較低層級的專案, 395 適用於服務的能力成熟度整合模式 1.2 版 雖然他們可能較不正式地被導入,因為他們的應用層 級移到一個別的組及因為失敗的風險減少。 組織一詞是指較高層級的管理提供政策、資訊、標準 流程及對數個專案的其他支援。從相關流程領域的執 行方式獲得商業價值需要,部分地,正確地界定這些 努力為專案。(參見詞彙中“專案"和“組織"的定 義) 有效地管理專案的關鍵之一是專案規劃。專案規劃流 程領域包括下列活動: • 發展專案計畫 • 適當地與關鍵人員互動 • 取得對計畫的承諾 • 維護計畫 規劃包括:估計工作產品及工作項目之屬性、決定資 源需求、協商承諾、產生時程,以及界定和分析專案 風險,上述活動對專案計畫的訂定可能需要反覆執 行。專案計畫提供專案活動之執行及控制基礎,以完 成對專案客戶的承諾。 專案進行時,專案計畫常因下列情況而修訂:需求及 承諾變更、不準確的估計、矯正措施及流程變更。說 明規劃及重新規劃的特定執行方法,包含在本流程領 域之內。 在本流程領域的一般與特定執行方法中,全部使用 「專案計畫」這個術語,來描述控制專案的全盤計 畫。 專案對由最終使用者不斷提出的服務要的回應可能需 要一個對資源到工作配置計畫及工作排序管理(例如 396 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 在維修商店中修護工作的指派)。這些低層級的操作 計畫可以被認為是整體專案計畫細節的擴張。 相關流程領域 有關確認有效的服務系統績效及確認資源被提供及有 效率地被使用以支援服務需求,參考能力及可利用度 管理流程領域,以獲得更多資訊。 有關準備服務系統運作,參考服務交付流程領域,以 獲得更多資訊。 服務系統發展補充 有關發展與分析關鍵人員需求及發展服務系統,參考 服務系統發展流程領域,以獲得更多資訊。 有關收集與分析組織的策略需求與能力,參考策略服 務管理流程領域,以獲得更多資訊。 有關律定專案度量項目,請參考度量與分析流程領 域,以獲得供多資訊。 有關在專案期間管理更新的需求改變,參考需求管理 流程領域,以獲得更多資訊。 有關界定、分析和減輕風險,參考風險管理流程領 域,以獲得更多資訊。 專案規劃 397 適用於服務的能力成熟度整合模式 1.2 版 特定目標及執行方法摘要 SG 1 建立估計值 SP1.1 建立採購策略 SP 1.2 估計專案範圍 SP 1.3 建立工作產品與工作項目屬性的估計值 SP 1.4 定義專案生命週期 SP 1.5 估計工作量與成本 SG 2 發展專案計畫 SP 2.1 建立預算和時程 SP 2.2 界定專案風險 SP 2.3 規劃資料管理 SP 2.4 規劃專案的資源 SP 2.5 規劃所需知識和技能 SP 2.6 規劃關鍵人員之參與 SP 2.7 建立專案計畫 SG 3 取得對計畫的承諾 SP 3.1 審查影響專案的各種計畫 SP 3.2 調整工作和資源水準 SP 3.3 取得計畫承諾 各目標的特定執行方法 SG 1 建立估計值 建立並維護專案規劃參數的估計值。 專案規劃參數包括專案從事規劃、組織、用人、督 導、協調、報告及預算等活動所需之所有資訊。 規劃參數之估計值應有可信賴的基礎,以逐漸建立信 心,使得以此估計值為基礎所做的計畫,都有能力支 援專案目標。 398 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 估計這些參數值時,通常考慮的因素舉例如下: • 專案策略 • 專案需求,包括產品需求、組織需求、客戶需 求及影響專案的其他需求 • 專案範圍 • 已界定之工作項目及工作產品 • 已界定的服務及服務層級 • 事故與要求如何處理 • 擇定的專案生命週期模式(例如,瀑布式、增 值式的、螺旋式的) • 工作產品與工作項目的屬性(例如:規模大小或 複雜度) • 時程 • 把工作產品與工作項目屬性轉換成投入工時與 成本的模式或歷史性資料 • 決定所需材料、技能、工時及成本的方法(模 式、資料、演算法) 為了關鍵人員對專案計畫的審查與承諾,以及在專案 執行過程中維護專案計畫,記錄估計理由與相關參考 資料是必要的。 SP 1.1 建立採購策略 建立與維護採購策略 專案策略提供專案規劃與管理的商業框架。策略包括 在適當的摘要層級,對下列因素的考量: • 專案目標和限制 • 符合那些目的和限制的可能措施 專案規劃 399 適用於服務的能力成熟度整合模式 1.2 版 • 可能需要的資源(例如,技能、環境、工具和新 技術) • 伴隨這些因素的風險及他們如何被陳述 專案策略通常是專案的長期觀點,反應它整體範圍, 考慮長期風險及說明不同關鍵人員扮演的角色,包括 供應商、客戶及其他專案。 專案策略可以扮演不同的角色,但通常,剛開始它是 資深管理人員同意一個專案和承諾投入資源的基準。 當專案規劃進行,以及解決方案、流程、資源和風險 被發掘和發展,專案策略可能需要修改。 對短期的專案,專案策略可能不會有或只發展一次, 這種情形下,當專案流程和更細節的規劃變得可能 時,它會被專案計畫取代。 對長期的專案,策略扮演一個持續的角色以協助維護 一個專案長期的觀點及其合理性得符合專案計畫的不 同要素,但是在更高層的摘錄;反之,專案計畫通常 將在較短的時間水平內,反應細節的較低層。 專案策略剛開始由組織發展或相關的專案人員發展, 可能與潛在的客戶和供應商或其他人員的組合共同合 作,以提供專案觀點的策略商業觀點。 專案策略可以包括所提供的服務的高階描述,發展服 務系統的方式及服務交付的方式。 典型的工作產品 1. 專案策略 細部執行方法 1. 界定專案的目標及所欲提供的能力 400 專案規劃 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 組織可以維持一個整體的商業策略說明專案建立 組織所需的能力時,專案所扮演的角色。在細部 執行方式描述的專案相關的目的和能力可能從整 體商業的這類考量中衍生出來,但傾向有特定的 或近期的一組目的和能力。 有關建立與維護與策略需求和計畫一致的標準服 務,參考策略服務管理流程領域,以獲得更多資 訊。 2. 界定達成目的或提供能力所使用的方式。 通常會有發展交付服務所需的基礎建設的措施 (也就是技術措施)以及交付客戶滿意度、所需 的技能層級、可利用的技能層級、成本及風險的 措施。 有關建立服務交付措施,參考服務交付流程領域 以獲得更多資訊。 3. 記錄商業上的考量 商業上的考量包括在長期需求和利潤的潛在成本 和利益、智慧財產權、競爭的氛圍、產業老化的 影響,加強組織的核心競爭力,從其他單位獲得 的核心競爭力,社會、貿易和技術的未來趨勢。 4. 界定主要資源需求 檢視專案措施可以協助界定專案所需的資源類 別,及這些資源的供應商(例如組織內其他的業 務部門,特定的功能部門、人力資源、智財權專 家、法律部門、行銷部門、業務夥伴及外部供應 商)。 有關確認有效的服務系統績效和確認支援服務需 求的資源被提供及有效的使用,參考能力與可利 用度管理流程領域,以獲得更多資訊。 401 適用於服務的能力成熟度整合模式 1.2 版 5. 界定專案中扮演重要角色的關鍵人員。 計畫關鍵人員參與的特定執行方式提供一個較細 節,雖然可能較短期的,對關鍵人員參與專案及 以何種方法參與的考量。 專案措施可以提昇外部關鍵人員(例如現行的及 潛在的客戶及業務夥伴)以提供某些需要的資 源。 6. 界定使用的協議型態。 為了成功,專案必須與主要的關鍵人員建立協 議。那些協議的本質部分依照考量每一個對象的 需求、目的、期望、限制和風險而決定。協議的 型態選擇應該是業務考量的一部分,如此說明了 不同的單位將如何分享專案的風險、成本和利 益。 7. 界定風險和風險如何配置到不同的關鍵人員。 在這個流程領域的界定專案風險特定執行方式提 一個較細節,雖然可能較短期的,專案可能遇到 的風險的考量。 8. 界定用來維護專案中安全和保全的措施。 關心安全和保安應該呈現在所有主要的規劃活動 中(例如,那些與專案目的、資源、風險和關鍵 人員相關的),但細部執行方式建議對安全和保 安議題與風險,以及專案可能描述它們的活動, 採取全面的觀點與焦點。 9. 與資深管理階層檢視策略並取得它的協議。 從下列主要的業務觀點檢視專案策略: • 這些目的是正確的嗎? • 措施合理嗎? 402 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 • 策略有妥適的長期配置組織資源嗎? • 什麼是投資報酬率? • 策略的結果會開展什麼機會? • 組織將會有大量風險嗎? • 某些尚未界定的主要關鍵人員在專案的成功 中,可能扮演什麼角色? • 客戶、供應商和競爭者可能有什麼反應? 10. 視需要修改專案策略。 視專案的持續時間,它可能需要調整專案策略以 反應目的、措施、資源可利用度、市場情形、客 戶需求、流程和產品技術等的改變。 SP 1.2 估計專案範圍 建立高階的分工結構圖(WBS),以估計專案的範圍。 分工結構圖隨專案進行而漸進發展。剛開始時,高階 的分工結構圖用於初期估計。分工結構圖把整個專案 分成一組可管理並相互連結的組件。 通常分工結構圖是一個產品、工作產品或任務導向的 結構,提供一種綱要結構,以識別與安排工作管理的 邏輯單元,該邏輯單元稱之為「工作包(work packages)」。通常,分工結構圖提供工作指派、時程 安排及權責的參考與組織的機制,並做為規劃、安排 及管制專案工作的基本架構。 在分工結構圖裏的活動可以用不同的方式組織,但通 常以時間或持續性作為範圍,以說明服務系統發展和 維護兩者以及服務交付。一些服務界定可能持續地交 付;其他可能照特定的要求回覆。兩者(可能在未 來)都界定在服務協議中。 專案規劃 活動可能依照一個或多個面向進一步地組織。例如, 產品維護的例子,我們可以進一步依據那些經歷產品 403 適用於服務的能力成熟度整合模式 1.2 版 完整週期(從產品交付到產品處置)的活動加以區 別,與管理和執行服務協議相關的活動,及與個別事 故或服務需求相關的活動。 典型的工作產品 1. 工作項目描述 2. 工作包描述 3. 分工結構圖 細部執行方法 1. 以產品架構為基礎,發展分工結構圖。 分工結構圖提供組織專案工作的結構。分工結構 圖應該允許界定下列項目: • 風險與風險降低工作 • 與交付項目及支援活動相關的工作 • 與技能及知識取得相關的工作 • 與發展工作所需之支援計畫,如:建構管 理、品質保證及驗證等計畫相關的工作 • 整合與管理非發展類項目之相關的工作 2. 界定工作包,須詳細到足以估計專案工作項目、責 任及時程。 上層分工結構圖旨在協助量測專案各項工作的工 作量,以及組織所應擔負的各項角色與責任。在 本層的分工結構圖詳細程度有助於發展實際可行 的時程,從而減少專案資源預留之需要。 3. 界定會從外部取得的產品及產品組件。 有關管理產品的採購和供應商的服務,參考供應 商協議管理流程領域,以獲得更多資料。 404 專案規劃 4. 界定會重複使用的工作產品。 關於適用於服務的能力成熟度整合模式 1.2 版 SP 1.3 建立工作產品與工作屬性的估計值 建立並維護工作產品與工作項目屬性的估計值。 規模大小是許多模式用來估計工作量、成本及時程的 主要輸入。這些模式也可根據關連性、複雜度及結構 做為輸入的基礎。 度量規模大小的工作,舉例如下: • 服務系統發展和交付 • 服務系統監督 • 預防性的維護或修護 • 運作中訓練 • 事故管理和解決方案 • 監督及說明廢棄 • 更新服務團隊使用的設備和供應品 • 後勤支援 • 設施維護 • 系統處置 專案規劃 405 適用於服務的能力成熟度整合模式 1.2 版 規模大小之度量方式,舉例如下: • 需求數 • 介面的數目與複雜度 • 技術風險項目數量 • 資料數量 • 服務層級的數量 • 服務的可利用度,依照服務層級(例如,回轉 時間、運作可利用率、每小時諮詢處應該可以 處理的電話數量) • 不同服務層級影響的關鍵人員數量 這些估計值應與專案需求一致,俾決定專案之工作 量、成本及時程。每個規模大小之屬性,均應指定一 個相對的困難度或複雜度的等級。 典型的工作產品 1. 工作項目及工作產品的規模大小及複雜度 2. 估計模式 3. 屬性估計值 細部執行方法 1. 使用適當方法決定工作產品及工作項目之屬性, 以估計資源需求。 決定產品大小與複雜度之方法,應依據已確認之 模式或歷史資料。 對產品特性與屬性的關係瞭解越多,決定屬性的 方法也將隨之漸進發展。 406 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 2. 估計工作產品及工作項目之屬性。 SP 1.4 定義專案生命週期 定義專案生命週期各階段,並據此建立專案規劃之範 圍。 專案生命週期階段之律定,決定了何時該進行評估與 決策制訂,通常用以支援針對資源投入與技術方法所 做重大承諾之決策點,並據以規劃相關工作,以執行 專案方向修訂、未來工作範圍與成本訂定等作為。 專案生命週期之瞭解,對下列工作是極為重要的:決 定規劃工作的範圍、決定開始規劃的時機及決定計畫 修訂之時機與標準(關鍵里程碑)。 選擇服務發展與交付的生命週期端視服務及其環境的 特性。有些服務供應商依照其標準服務定義調適其階 段。 有關建立標準服務,參考策略服務管理流程領域,以 獲得更多資訊。 通常,個別服務有隱含的生命週期伴隨著他們,包括 溝通、評估和決策的點,以及應該考量當預測支援這 類服務交付時的所需。 典型的工作產品 1. 專案生命週期各階段 SP 1.5 估計工作量與成本 依照預測的基本原理,估計工作產品和工作項目所需 之專案工作量和成本。 工作量及成本的估計值,通常根據模式分析的結果, 或應用於規模大小、活動及其他規劃參數的歷史資料 而來。對這些估計值之信心,是來自估計模式的邏輯 原理及歷史資料的本質。有時候歷史資料不適用,例 專案規劃 407 適用於服務的能力成熟度整合模式 1.2 版 如當工作欠缺前例或工作項目類型與模式不合。所謂 工作欠缺前例,是指組織沒有這類產品的經驗。 典型的工作產品 1. 估計理由 2. 專案工作量估計值 3. 專案成本估計值 細部執行方法 1. 蒐集估計模式或歷史資料,以將工作產品及工作項 目的屬性,轉換成工時及成本的估計值。 許多已開發的參數化模式可協助估計成本及時 程。並不建議只使用這些模式作為估計的單一來 源,因為它們所依據的歷史專案資料,可能並不 適合你的專案。使用多種估計模式及(或)多種估計 方法可以確保估計上的高度信心。 歷史資料包含先前執行專案的成本、工作量及時 程,以及考慮不同專案規模及複雜度的調適資 料。 2. 估計工作量及成本時,應納入支援工作執行與產品 運作之基礎環境所需的項目。 支援基礎建設包括從產品的發展和持續觀點來 看,所需的資源。 考量發展環境中需要的基礎建設資源,測試環 境、產品環境、目標環境,或當預測工作量和成 本時,這些環境適當的組合。 408 專案規劃 基礎建設資源舉例如下: • 重要的電腦資源 • 服務團隊將安裝的工具 • 設施、機械和裝備 關於適用於服務的能力成熟度整合模式 1.2 版 3. 用估計模式及歷史資料,估計所需工作量及成本。 專案規劃 409 適用於服務的能力成熟度整合模式 1.2 版 用來估計工作量及成本的輸入,通常包括: • 專家(群)所提供的判斷估計(例如:Delphi 預估法) • 風險因素,包括工作欠缺前例的影響程度 • 執行工作所需之核心能力與關鍵角色 • 服務和服務系統需求 • 產品和產品組件需求 • 專案策略 • 分工結構圖 • 工作產品、工作項目和預計改變的規模預測 • 外部要求產品的成本 • 已選定之專案生命週期模式與流程 • 生命週期成本估計 • 提供工具的能力 • 執行工作的管理人員與工作人員之技能水準 • 所需知識、技能和訓練 • 所需的設施(例如,為發展與維護服務系統和 服務交付) • 製造流程的能力 • 差旅 • 工作項目、工作產品、硬體、軟體、人員及工 作環境之安全程度 • 客服中心及產品保證之服務水準協議 • 直接人工與間接費用 410 專案規劃 SG 2 發展專案計畫 關於適用於服務的能力成熟度整合模式 1.2 版 建立並維護專案計畫,以做為管理專案的基礎。 專案計畫以專案需求及已建立的估計值為基礎,是用 來管控專案執行的正式核定文件。 專案計畫應考慮專案生命週期的所有階段。專案規劃 時應確保所有影響專案的計畫與主計畫之間的一致 性。 SP 2.1 建立預算與時程 建立並維護專案預算與時程。 專案預算及時程係依據已發展的估計值來安排,並確 保預算分配、工作複雜度、工作項目的依存關係均已 適當考量。 面對專案風險時,事件驅動且有資源限制的時程安排 已證明具有實效。若工作開始之前,就清楚界定完成 時將要展示的成果,則有下述好處:提供事件處理的 時間彈性、對預期成果的共識、較佳的專案狀態願 景,以及較精確的專案工作項目狀況掌握。 這個特定執行方式的細部執行方式和典型的工作產品 應該在整體專案層級和每一個服務型態中均適當地說 明。也就是說,個別服務要求(例如修改遠端設施的 一項設備、運送一個包裹到目的地)可以有個別的里 程碑、工作項目條件、資源配置及限制排程,這些應 該一起考量並與較大的專案預算和時程活動加以協 調。 典型的工作產品 1. 專案時程表 2. 時程相依關係 3. 專案預算 專案規劃 411 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 界定重要的里程碑。 里程碑是預先規劃的事件或時間點。在里程碑中 執行一個整體狀態的檢視,以瞭解關鍵人員的需 求如何被滿足。(如果專案包括一個發展的里程 碑,那麼執行檢視以確保伴隨里程碑的預測和需 求有被滿足。)里程碑可能附有整個專案或特別 的服務型態或情形。里程碑用來協助確定交付項 目能如期完成。里程碑可以事件或日期為基準。 若為後者,一旦決定日期後就不易更改。 2. 界定時程安排的假設前題。 當開始發展時程時,通常需要假設某些活動的期 程。這些假設通常涉及一些缺少估計資料的工作 項目。界定這些假設前題,可提供對全程之信心 程度(不確定性)的洞察力。 3. 界定限制條件。 必須儘早界定會影響管理方法彈性的限制因素, 檢驗工作產品與工作項目的屬性,常會促使這些 因素浮現。這些屬性可包括:工作項目之工期、 資源需求、輸入及輸出。 4. 界定工作相依關係。 可用於決定工作活動最佳次序的工具,舉例如下: • 關鍵路徑法(CPM) • 計畫評核術(PERT) • 資源限制排程法 5. 定義預算與時程。 412 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 建立並維護專案預算及時程通常包括下列事項: • 定義已承諾或已預期之資源與設施的可用時段 • 決定專案活動的時段 • 決定附屬時程的分類 • 定義專案活動間的相依關係(先後順序關係) • 定義精確度量進度所需的排程活動及里程碑 • 界定交付客戶產品的里程碑 • 定義適當工期的專案活動 • 定義適當時間間隔的里程碑 • 根據滿足時程與預算要求之信心度,定義管理 上需預留的資源空間 • 用適當的歷史資料來驗證時程 • 定義階段性/分期的經費需求 • 記錄專案的假設與理由 6. 建立矯正措施標準。 建立構成嚴重偏離專案計畫的判斷標準。議題與 問題的衡量對矯正措施執行時機十分重要。矯正 措施可能需要重新執行專案規劃,包含修訂原計 畫、建立新協議,或減少目前計畫內的活動。 矯正措施的準則係依據採購策略中,利用流程、 產品與服務水準度量項目所定義的關鍵目標。這 個準則回溯到特定的關鍵人員需求和專案成功的 門檻值。專案計畫定義被應用的準則和被誰應用 (在何種情形,以何種頻率)。 SP 2.2 界定專案風險 界定並分析專案風險。 專案規劃 413 適用於服務的能力成熟度整合模式 1.2 版 有關風險監測活動,請參考專案監控流程領域的特定 執行方法,以獲得更多資訊。 有關在潛在問題發生前予以界定,以跨產品或專案週 期,在它們發生前,規劃及視需要喚起風險處理活 動,以減輕達成目的時負面影響,參考風險管理流程 領域,以獲得更多資訊。 界定或發現風險並分析以支援專案規劃。本特定執行 方法必須延伸到影響專案的所有計畫,以確保與風險 相關的所有關鍵人員之間已能溝通無誤。 專案規劃之風險界定與分析,通常包括下列各項: • 界定風險 • 分析風險以決定其影響程度、發生機率及可能發 生問題的時間點 • 排列風險的優先順序 典型的工作產品 1. 已界定的風險項目 2. 風險的影響程度及發生機率 3. 風險的優先順序 細部執行方法 1. 界定風險 風險界定包括找出對工作成果與計畫造成負面影 響的各種潛在問題、危險、威脅及弱點。在分析 風險之前,必須先以容易瞭解的方式,界定及描 述風險。界定風險時,最好能採用定義風險的標 準方法。可使用風險界定及分析工具,以協助界 定可能的問題。 414 專案規劃 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 風險界定及分析工具,舉例如下: • 風險分類 • 風險評量 • 結構化訪談 • 腦力激盪 • 績效模式 • 成本模式 • 網路分析 • 品質因素分析 風險的例子如下: • 任務改變 • 客戶或最終使用者改變 • 專案策略改變 • 所需設施可利用度的改變 • 設備、工具和部分廢棄 • 缺失 • 喪失技能 • 供應商失敗 • 服務中斷 2. 記錄風險。 3. 與相關的關鍵人員審查已記錄風險之完整性與正確 性,並取得其同意。 4. 適當地修訂風險。 415 適用於服務的能力成熟度整合模式 1.2 版 已界定的風險須要修訂的情況,舉例如下: • 新風險已被界定 • 當風險變成問題 • 風險已消失 • 專案環境有大幅變動 SP 2.3 規劃資料管理 規劃專案資料的管理。 資料是種文件的形式,用以支援專案的全部領域(例 如:行政管理、工程、建構管理、財務、後勤、品 質、安全、製造及採購)。資料可能有多種型式(例 如:報告、手冊、筆記、圖表、規格書、檔案或往來 書函),並可存放於各種媒體(例如:不同材質的印刷 本或繪圖本、照片、電子媒體或多媒體)。 資料可能是交付項目(例如列於合約中的項目),或是 非交付項目(例如:非正式資料、市場研究及分析資 料、內部會議紀錄、內部設計審查文件、學習心得及 行動資料),其也有多種分送方式,包括可用電子方 式傳送。 專案資料需求,應就資料項目的格式與內容,按共通 或標準的資料需求來建立。統一的資料項目內容及格 式,使資料內容更容易瞭解,亦有助於資料資源的一 致性管理。 蒐集每份文件的理由必須要很清楚。這工作包括分析 和驗證專案交付及非交付項目、資料需求,以及客戶 提供的資料。資料蒐集時,常不瞭解將如何使用該資 料,蒐集成本很高,應該只在需要時才蒐集。 416 專案規劃 專案規劃 典型的工作產品 1. 資料管理計畫 關於適用於服務的能力成熟度整合模式 1.2 版 2. 列管資料總表 3. 資料內容及格式描述 4. 對採購者與供應商的資料需求清單 5. 隱私需求 6. 安全需求 7. 安全程序 8. 資料檢索、複製及分發機制 9. 專案資料的蒐集時程 10. 待蒐集的專案資料清單 細部執行方法 1. 建立確保資料隱私與安全的需求及程序。 並非每人都有取用專案資料的需要或權限。必須 建立程序,以界定什麼人可在什麼時候取用什麼 資料。 需求和程序可以包含在服務協議條款下,對保安 資料有責任的服務員工。 2. 建立將資料存檔及取用已存檔資料的機制。 取用的資訊應該以容易瞭解的型式(例如:電子型 式或從資料庫的電腦輸出)表達,或以其原始建立 的型式表達。 3. 決定待界定、蒐集及分發的專案資料。 4. 決定提供給關鍵人員資料存取和散布的需求。 417 適用於服務的能力成熟度整合模式 1.2 版 專案計畫其他要素的檢視可以協助決定誰需要存 取或接收專案資料及資料的範圍。 5. 決定那些專案資料與計畫需要有版本控制或更嚴 謹之建構控制,並建立機制以確保專案資料之管 控。 SP 2.4 規劃專案資源 規劃執行專案所需之必要資源。 按照估計初始值,定義專案資源(人工、機器/設備、 材料及方法)及執行專案活動的資源需求數量。同時 也提供更多的資訊,以展開用來管理專案的分工結構 圖。 先前發展的高階 WBS (當作估計機制),通常經由分 解成代表單一工作單元之工作包而展開,工作包可分 別指派、執行及追蹤,以便分配管理責任,並提供較 好的管理控制。 分工結構圖的每一工作包或工作產品,應指定唯一的 識別符號(例如:數字)以便追蹤。WBS 可按需求、專 案活動、工作產品或上述的任意組合而建立,並需伴 隨者每一工作包之工作描述說明書。 典型的工作產品 1. 分工結構圖工作包 2. 分工結構圖工作說明書 3. 依專案規模大小及範圍的用人需求 4. 關鍵設施/設備表 5. 流程/工作流程的定義及圖表 6. 專案行政管理需求表 7. 狀態報告範本 418 專案規劃 專案規劃 細部執行方法 1. 決定流程需求。 關於適用於服務的能力成熟度整合模式 1.2 版 必須界定、定義用以管理專案的流程,並與所有 關鍵人員協調,以確保專案執行期間能有效率的 執行流程。 2. 決定溝通機制的需求 這些需求說明在服務交付期間用來與客戶、最終 使用者、服務供應商人員及其他關鍵人員溝通的 機制種類。這類需求部分自流程需求、服務協議 和專案策略中衍生出來。 溝通機制可以在服務系統發展時產生,必須定期 檢視、客製化及儘可能提供用來符合進行中的服 務交付需求。 服務系統發展補充 有關發展服務系統,參考服務系統發展流程領 域,以獲得更多資訊。 3. 決定用人需求。 專案的用人應依分工結構圖的工作包來安排。工 作包的分割是從達成專案需求著眼,將需求分做 工作項目、執行角色及責任。 用人需求必須考慮每個職位所需的知識與技能, 如「規劃所需知識和技能」特定執行方法所述。 有關確保有效的服務系統績效及確保資源被提供 及有效地使用以支援服務需求,參考能力與可利 用度管理流程領域,以獲得更多資訊。 4. 決定設施、設備及組件需求。 419 適用於服務的能力成熟度整合模式 1.2 版 多數專案在概念上都是獨一無二的,因此需要一 組獨特的資產,以完成專案目標。及時決定並取 得這些資產,對專案成功極為重要。 對那些有前置時間的資產項目,必須及早界定以 決定處理方式。即使所需資產不具特殊性,整理 一份所有設施、設備及零件(例如:專案成員工作 所需的電腦數目、應用軟體、辦公空間等等)的清 單,可清楚瞭解工作涵蓋之範圍,尤其是某些易 被忽略的項目。 5. 決定其他持續的資源需求。 在決定流程、報告範本、員工、設施及設備以 外,對其他型態的資源可能有持續的需求,以有 效地實現專案活動,包括: • 消耗品(例如,電力、辦公室用品) • 使用智慧財產權 • 使用運輸(對人及設備) 這類資源的需求是從建立在(現行的及未來的) 協議(例如,客戶協議、服務協議、供應商協 議)、專案策略措施及管理與維護一段時間的專 案運作的需求等衍生出來的。 SP 2.5 規劃所需知識和技能 規劃執行專案所需之知識與技能。. 有關發展人員的技能與知識,以使他們能有效率且有 成果地展現他們的角色,請參考組織訓練流程領域, 以獲得更多資訊。 專案之知識導入涵蓋專案成員的訓練,以及從外界獲 取知識。 420 專案規劃 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 用人需求必須根據執行專案所需之知識與技能而定。 訓練的規劃說明專案成員及支援人員為展現工作項目 需要的知識與技能。知識與技能的需求可來自專案風 險。 例如,如果專案提供一個成功的服務交付,需要熟悉 複雜設備的細節,訓練的規劃確認了指派到專案的人 員對這類的設備有適當的專業,或提供專案團隊在那 些領域的訓練。 訓練也可以包括口頭說明執行專案工作項目所需的產 業知識及專案流程。專案也可以界定及規劃其供應商 所需的知識與技能。規劃包括確保成本和資金來源支 應可提供的訓練和足夠的前置時間來獲得資金和訓 練。 對長期和持續運作的專案,所需的知識和技能將更 新,當下列事件發生時: • 專案人員在專案內外輪調(或從一個服務型態到 另一個) • 在服務系統使用的技術或個別的服務修改 • 在發展或客戶環境改變時使用的流程和技術 例如,專案人員的修改造成需要決定新的專案成員所 需的知識和技能。在專案不同的階段(或新的服務或 增加服務層級)需要新的知識與技能。規劃所需的知 識與技能應該說明改變的來源。 有關準備服務系統轉移及為修改準備關鍵人員。 典型的工作產品 1. 所需技能項目 421 適用於服務的能力成熟度整合模式 1.2 版 2. 用人與新人聘僱計畫 3. 人力資料庫(如技能與訓練) 4. 訓練計畫 細部執行方法 1. 界定專案執行所需的知識與技能 2. 評量可用的知識與技能。 3. 選擇提供所需知識與技能的機制。 機制舉例如下: • 內部訓練(公司與專案) • 外部訓練 • 用人及聘僱新人 • 向外採購所需技能 當選擇以內部或外包訓練來取得所需知識與技能 時,應依據訓練專業能力、專案時程及經營目標 來決定。 4. 將選定的機制納入專案計畫。 SP 2.6 規劃關鍵人員之參與 規劃已界定的關鍵人員之參與。 藉由界定專案代表的人員與功能,及描述他們在專案 活動的關聯和互動程度,來界定專案生命週期所有階 段的關鍵人員。製作關鍵人員和專案活動的二維矩陣 對照表以實現關聯是很方便的形式。矩陣的每一格 (即每一縱橫座標交叉點),即可用來描述某一關鍵人 422 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 員,在某特定活動中的關係和被期望參與該活動的角 色與份量。 要讓關鍵人員的參與發揮效用,必須慎選相關的關鍵 人員。專案每個主要活動,都應界定出會受該活動影 響的關鍵人員,以及有專案技術來引導該活動的關鍵 人員。相關關鍵人員的名單應隨專案生命週期階段而 調整。先期的專案工作(如需求和設計決策)會影響到 後期工作,故應確保列名於專案後期生命週期階段的 相關關鍵人員,能及早表達對影響他們的需求與設計 決策的意見。 相關關鍵人員的例子可能包括專案成員、管理階層、 供應商、客戶、最終使用者、組織的產品線成員及必 須協調的專案的其他相關產品和服務的供應商。 有關建立服務協議,參考服務交付流程領域,以獲得 更多資訊。 關鍵人員互動計畫應包括的內容,舉例如下: • 相關關鍵人員名單 • 關鍵人員參與的理由 • 專案生命週期各階段中相關關鍵人員的角色與 責任 • 關鍵人員間的關係 • 專案生命週期各階段中關鍵人員對專案成功的 重要性 • 所需的資源(例如:訓練、材料、時間、經 費),以確保關鍵人員的互動 • 關鍵人員分階段互動的時程 專案規劃 423 適用於服務的能力成熟度整合模式 1.2 版 本特定執行方法之實施,有賴與前述「規劃所需知識 與技能」執行方法相互分享或交換資訊。 典型的工作產品 1. 關鍵人員參與計畫 SP 2.7 建立專案計畫 建立並維護全盤的專案計畫。 在說明所有相關規劃項目,以取得所有要執行或支援 該計畫的個人、團體、組織的相互了解、承諾、及執 行時,一份書面計畫是必要的。 計畫從專案中產生定義工作量的所有面向,將下列以 合邏輯的方式連結在一起: • 專案生命週期的考量 • 專案工作項目 • 預算和時程 • 里程碑 • 資料管理 • 風險確認 • 資源與技能需求 • 關鍵人員界定和交流 基礎建設的描述包括專案人員、管理階層和支援組織 的責任和授權關係。 典型的工作產品 1. 全盤專案計畫 細部執行方法 1. 記錄專案計畫。 424 專案規劃 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 專案可能包含其他較低階的專案。一個專案可能 包含服務系統發展專案和服務交付專案。一個服 務交付專案可能包含數個自此流程領域中不同的 規劃和執行方式獲益的服務。參考簡介以瞭解有 關此流程領域特定執行方式的應用能力對專案的 額外意見。當專案包含其他專案時,整個專案計 畫應該包括或參考較低階專案的專案計畫,而所 有相關計畫應該相容及適當地相互支援。 2. 適當地包含、參考和調和規劃活動的結果。 為獲得相關關鍵人員的支持,專案計畫應該記錄 一個彈性和敏感的措施以符合他們的需求、期望 和限制。這類的計畫需要不同的規劃元素是合理 地完整和一致的。(至少在數個星期或數個月產 生下一個計畫版本之前)。 如果執行合宜,此流程領域特定執行方式說明了 計畫和流程的一般執行方式,在流程改善工作的 範圍內,應用到其他專案相關的流程領域。但除 了執行結果以外,一般執行方式也應該在細部執 行方式中考量。 3. 與相關關鍵人員檢視專案計畫並取得同意。 下一個特定目標的特定執行方式—獲得對計畫的 承諾,描述了一些活動以協助確認專案計畫中說 明了為符合需求、期望及相關關鍵人員限制的實 際措施,並協助確認這些相關關鍵人員將如專案 計畫中所載,實現他們的角色,包括專案執行期 間提供資源和其他型式的支援。 4. 視需要修改專案計畫。 一般而言,當修改專案計畫,它可能需要重複很 多在此流程領域所描述的規劃活動,以協助確認 相關關鍵人員維持對計畫的承諾。 425 適用於服務的能力成熟度整合模式 1.2 版 SG 3 取得對計畫的承諾 建立並維護對專案計畫的承諾。 計畫必須獲得負責執行及支援人員的承諾才生效。 SG 3.1 審查影響專案的各種計畫 審查影響專案的所有計畫,以瞭解專案承諾。 其他流程領域所發展的計畫,通常包括與全盤專案計 畫同類的資訊。這些計畫可能提供額外且詳細的指 引,應配合與支持全盤專案計畫,以指出權責與管制 的人。影響專案的所有計畫應予審查,以確保其涵蓋 專案成功所需的範圍、目標、角色及關係的共識。很 多影響專案的計畫描述於規劃流程的一般執行方法 中。 典型的工作產品 1. 影響專案計畫的審查紀錄 SP 3.2 調整工作和資源水準 調整專案計畫,以調和可用及預估的資源。 為使所建立的專案是可行的,獲取相關的關鍵人員的 承諾,以及調整預估與實際可用資源之間的差距是重 要的。調整的方式通常包括:降低或延後技術效能的 需求、爭取更多資源、找尋增進生產力的方法、委 外、調整專案人員的技能組合、修訂影響專案的所有 計畫或其時程表。 典型的工作產品 1. 已修訂的方法與對應的預估參數 (例如:較好的工 具、使用現成品組件) 2. 重新協商的預算 3. 已修訂的時程 4. 已修訂的需求表 426 專案規劃 5. 重新協商的關鍵人員協議 關於適用於服務的能力成熟度整合模式 1.2 版 SP 3.3 取得計畫承諾 從負責執行與支援計畫之相關關鍵人員取得承諾。 取得承諾涉及所有專案內外部相關關鍵人員之間的互 動。做了承諾的個人及小組應有信心在預定之成本、 時程及執行的限制條件下完成工作。一般在進行全面 承諾前,可先暫時性承諾以使工作啟動並容許進行相 關研究,以增加信心到適當程度後進行全面承諾。 典型的工作產品 1. 承諾要求紀錄 2. 承諾紀錄 細部執行方法 1. 界定所需支援,並與相關關鍵人員協商承諾。 可用分工結構圖為檢查表,以確保所有工作項目 都獲得承諾。 關鍵人員互動計畫應界定所有取得承諾之對象。 2. 記錄組織所有全面性與臨時性的承諾,並確保由適 當層級的人員簽署。 承諾須文件化,以確保相互瞭解的一致性與提供 追蹤及維護。臨時性的承諾應附有相互關係的風 險描述。 3. 適時與資深管理人員一起審查內部承諾。 4. 適時與資深管理人員一起審查外部承諾。 專案規劃 427 適用於服務的能力成熟度整合模式 1.2 版 管理者可能具有必要的洞察力及權威,以降低與 外部承諾相關聯的風險。 5. 界定存在於專案元件與其他專案及組織單位之間的 介面承諾,以利監督。 定義良好的介面規格是承諾的基礎。 428 專案規劃 關於適用於服務的能力成熟度整合模式 1.2 版 流程與產品品質保證 成熟度第二級的支援類流程領域 目的 簡介 流程與產品品質保證的目的,在提供成員與管理階層 客觀洞察流程與相關工作產品。 流程與產品品質保證流程領域包括下列活動: • 依據適用的流程說明、標準及程序,客觀評估所 執行的流程、及工作產品及服務 • 界定並記錄不符合的議題 • 對專案成員與管理人員,提供品質保證活動結果 的回饋 • 確保不符合議題已經處理 流程與產品品質保證流程領域藉由提供專案成員和各 階層的管理人員,對於專案生命週期中的流程和工作 產品提供適當的能見度和回饋,以支援交付高品質的 產品和服務。 流程與產品品質保證流程領域的執行方法可確保實行 所規劃的流程,而驗證服務系統發展流程領域的執行 方法則確保滿足特定的需求。這兩個流程領域可從不 同的觀點檢視同樣的工作產品,專案應注意將投入的 重複性降到最低。 流程與產品品質保證評估的客觀性,是專案成功的關 鍵(「客觀評估」的定義,詳見詞彙)。客觀性可藉由 流程與產品品質保證 429 適用於服務的能力成熟度整合模式 1.2 版 獨立與使用準則來達成。由未參與生產工作產品的 人,依據準則進行評估,經常混合使用不同的方法、 較不正式的方法,可用於涵蓋日常的活動,較正式的 方法,則週期性的使用以確保客觀性。 執行客觀評估的方法包含如下: • 由獨立的品質保證組執行的正式稽核 • 執行不同形式的同仁審查 • 深入的實地審查(辦公桌稽核) • 工作產品分散式的審查和評論 傳統上,為了提供客觀性,品質保證組常獨立於專案 之外。但對於某些組織而言,在並非獨立的狀況下實 施流程與產品品質保證,可能也是適合的方式。 例如:在一個具有開放、品質導向文化的組織,流程 與產品品質保證的角色由同仁部分或全部擔任,且品 質保證功能可能植入於流程之中。對小型組織而言, 這種內植法可能是最可行的方法。 如果品質保證功能植入於流程中,必須處理下列幾個 議題以確保客觀性。執行品質保證活動的每個人必須 接受訓練。執行工作產品品質保證活動的人員,應該 與直接參與發展與維護工作產品的人員有所區隔。品 質保證人員必須有獨立的報告管道,以對組織適當管 理層級報告,必要時讓不符合的議題向上反應。 430 流程與產品品質保證 關於適用於服務的能力成熟度整合模式 1.2 版 例如:當以同仁審查做為執行客觀評估的方法 時,必須注意下列問題: • 參加同仁審查的人要接受訓練並被指派角色。 • 指派未參與生產工作產品的同仁審查成員,擔 任品質保證的角色。 • 具備支援品質保證活動的檢核表。 • 缺失會成為同仁審查報告的一部份,且加以追 蹤,並於必要時提升到專案之上的層次。 品質保證工作應開始於專案建立的初期,參與建立專 案的計畫、流程、標準及程序,為專案增加價值,並 滿足專案和組織政策的需求。執行品質保證的人員參 與建立計畫、流程、標準及程序,可確保符合專案需 要,在執行品質保證評估時,也相當有用。此外,需 指定專案將進行評估的流程及相關工作產品。此項指 定以抽樣或客觀準則為基礎,而且與組織政策、專案 需求及專案需要相符合。 當界定不符合議題時,盡可能先在專案內處理與解 決。無法在專案內解決的不符合議題,需提升到適當 的管理階層解決。 本流程領域主要用於評估專案活動和工作產品,也適 用於其他活動及工作產品,例如:訓練組織的支援 組。對於這些活動和工作產品,「專案」專案這個術 語,應予適當的解釋。 相關流程領域 流程與產品品質保證 431 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 有關驗證選定的服務系統組件是否符合界定的需求, 請參考服務系統發展流程領域,以獲得更多資訊。 特定目標及執行方法摘要 SG 1 客觀評估流程與工作產品 SP 1.1 客觀評估流程 SP 1.2 客觀評估工作產品及服務 SG 2 提供客觀的洞察力 SP 2.1 溝通並確保解決不符合的議題 SP 2.2 建立紀錄 各目標的特定執行方法 SG 1 客觀評估流程與工作產品 客觀評估執行的流程、相關的工作產品及服務,對適用的流程 說明、標準及程序的遵循程度。 SP 1.1 客觀評估流程 根據適用的流程說明、標準及程序,客觀評估所指定 的執行流程。 品質保證評估的客觀性是專案成功的關鍵。須定義品 質保證報告的管道及如何確保客觀性。 典型的工作產品 1. 評估報告 2. 不符合的報告 3. 矯正措施 細部執行方法 1. 建立鼓勵員工參與界定並報告品質議題的環境(建 立該環境成為專案管理的一部分)。 432 流程與產品品質保證 關於適用於服務的能力成熟度整合模式 1.2 版 2. 建立並維護明確陳述的評估準則。 此細部執行方法的目的在依據業務需求提供準則: • 評估的標的物 • 流程評估的時間或頻繁 • 評估進行的方式 3. 使用上述準則評估所執行之流程,對流程說明、標 準及程序的遵循程度。 4. 界定評估時發現的每一個不符合事項。 5. 界定能改善未來產品及服務流程的學習心得。 SP1.2 客觀評估工作產品及服務 根據適用流程說明、標準和程序,客觀評估指定的工 作產品。 典型的工作產品 1. 評估報告 2. 不符合的報告 3. 矯正措施 細部執行方法 1. 取樣時,根據文件化的取樣準則,選擇需評估的工 作產品。 不論服務的接收者屬於專案或組織的內部或外 部,工作產品可包能括流程所產生的服務。 2. 建立並維護明確陳述的準則,以供評估所選定的工 作產品。 此細部執行方法的目的在依據業務需求提供準 則: • 評估工作產品時的評估項目 流程與產品品質保證 433 適用於服務的能力成熟度整合模式 1.2 版 • 工作產品評估的時間或頻繁 • 評估進行的方式 3. 使用上述準則評估工作產品。 4. 在工作產品交給客戶前或期間,在適當的時間評估 所選定的工作產品。 5. 針對所選定的工作產品,在發展過程的已選定里程 碑中,依據流程描述、標準與程序,進行立即或漸 進的評估工作產品。 如果被評估的服務具有流程描述,那麼 SP1.1 包 含依據流程描述的服務評估。則此特定執行方法 不只聚集服務本身-亦即其結果、影響等。 6. 界定評估時發現的每一個不符合事項。 7. 界定能改善未來產品及服務流程的學習心得。 SG 2 提供客觀的洞察力 客觀追蹤與溝通不符合的議題,並確保解決議題。 SP 2.1 溝通並確保解決不符合的議題 溝通品質議題,並和成員與管理者確保解決不符合的 議題。 評估時發現的不符合議題,反映出對適用標準、流程 說明或程序缺乏遵循。不符合議題的狀況可提供品質 趨勢的指標。品質議題包括不符合議題和趨勢分析的 結果。 當不符合議題不能在專案內解決時,使用已建立的向 上反應機制,確保適當的管理階層可以解決議題。追 蹤不符合議題直到解決為止。 典型的工作產品 1. 矯正措施報告 434 流程與產品品質保證 2. 評估報告 3. 品質趨勢 關於適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 盡可能與適當的成員解決每一個不符合的議題。 2. 當不符合議題在專案內無法解決時,需予以記錄。 專案內解決不符合事項的方法,舉例如下: • 修改不符合處 • 修改違反的流程說明、標準或程序 • 取得不符合的豁免 3. 不符合議題在專案內無法解決時,提升到適當的管 理階層,以瞭解議題並採取行動。 4. 分析不符合議題,以瞭解是否有品質趨勢需要界定 和處理。 5. 確定相關關鍵人員即時知道評估的結果和品質趨勢。 6. 定期與指派的管理者審查未結案的不符合議題和趨 勢,以瞭解議題並採取行動。 7. 追蹤不符合議題直到解決為止。 SP 2.2 建立紀錄 建立並維護品質保證活動的紀錄。 典型的工作產品 1. 評估紀錄 2. 品質保證報告 3. 矯正措施的狀況報告 流程與產品品質保證 435 適用於服務的能力成熟度整合模式 1.2 版 4. 品質趨勢報告 細部執行方法 1. 詳細記錄流程與產品品質保證活動,以瞭解狀況和結果。 2. 視需要修正品質保證活動的狀況與歷史。 436 流程與產品品質保證 量化專案管理 成熟度第四級的專案管理類流程領域 目的 關於適用於服務的能力成熟度整合模式 1.2 版 簡介 量化專案管理(Quantitative Project Management, QPM) 流程領域的目的,在於以量化的方式管理專案已調適 流程,以達成專案既定的品質及流程績效目標 量化專案管理流程領域包括下列活動: • 設定並維護專案的品質及流程績效目標 • 以流程績效基準或模式的穩定性及能力的歷史資 料為基礎,界定組成專案已調適流程的適當子 流程 • 從專案已調適流程中,選定採統計化管理的子流 程 • 監控專案,以決定是否符合專案的品質及流程績 效目標,並界定適當的矯正措施 • 選定用於統計化管理所選定子流程的度量及分析 技術 • 運用選定的度量及分析技術來建立並維護對所選 定子流程變異的理解 • 監控所選定子流程的績效,以決定子流程是否符 合其品質及流程績效目標,並界定矯正措施 • 將統計及品質管理資料記錄於組織度量儲存庫 量化專案管理 437 適用於服務的能力成熟度整合模式 1.2 版 438 此處所界定的品質與流程績效目標、度量及基準,是 由組織流程績效流程領域的內容發展而來。因此,實 施量化專案管理流程領域相關的流程(例如:度量定 義項目與度量資料等),將成為組織流程績效流程領 域所指組織流程資產的一部分。 為有效說明本流程領域的特定執行方法,組織必須建 立一組標準流程及相關的組織流程資產,例如:每一 專案用來建立其已調適流程的組織度量儲存庫及組織 流程資產館。 專案已調適流程是為構成整合且藕合之專案活動而構 成的整合且藕合之專案活動的框架生命週期的一組子 流程,其一部分是由組織標準流程挑選及調適而來。 (有關「已調適流程」的定義,請參見詞彙)。 專案應確保能取得供應商工作量與進度的度量資料。 要成功的完成本流程領域的特定執行方法,也需要與 供應商建立有效的關係至為重要。 流程績效是實際流程執行結果的一個度量。流程績效 以流程度量(例如:工作量、週期時間及、缺失移除 的有效程度)及產品度量(例如:可靠度、缺失密度 及、反應時間)來表示。 子流程是一個更大已調適流程的定義組件。例如一個 典型組織的服務系統發展流程可能由諸如需求發展、 設計、建置、測試、與同仁審查等子流程所構成。這 些子流程又可再進一步分解為其他子流程或流程元 件。 量化管理的一個基本要素是要對估計值要有信心(也 就是說,要能夠預測專案品質及流程績效目標的達成 度)。需要統計化管理的子流程是基於可預測的績效 需要來選定。(有關「統計化管理流程」「品質與流 程績效目標」與「量化管理流程」的定義,請參見詞 彙) 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 量化管理的另一個基本要素是要瞭解實際流程績效差 異的本質及差異程度,並認知在什麼時候,專案實際 績效並無法協助達成專案品質及流程績效目標。 統計化管理涉及統計化的思維及各種統計技術的正確 運用,如執行圖(run charts)、控制圖、信賴區間、預 測區間及假設檢定等統計技術。量化管理是運用由統 計化管理所得到的資料,來協助專案預計是否能達成 其品質及流程績效目標,並界定必須採取的矯正措 施。 本流程領域應用於管理一個專案,但其相關的概念可 運用於管理其他小組與功能群。將這些相關概念應用 於其他小組與功能群,並不必然對達成組織經營目標 有所幫助,但可能可以協助這些小組與功能群控制其 流程。 可從使用本流程領域獲益的其他小組與功能群, 舉例如下: • 品質保證 • 流程定義及改善 • 工作量報告 • 客戶抱怨處理 • 問題追蹤及報告 相關流程領域 量化專案管理 有關確保有效的系統績效與確保資源的提供和運用可 以有效支援服務需求,請參考容量與可用度管理流程 領域,以獲得更多資訊。 有關建立並維護標準服務並與策略需要及規劃取得一 致,請參考策略服務管理流程領域,以獲得更多資 訊。 439 適用於服務的能力成熟度整合模式 1.2 版 有關界定缺失及其他問題的原因,並採取行動以預防 未來再度發生,請參考原因分析與解決方案流程領 域,以獲得更多資訊。 有關建立並維護專案已調適流程,請參考整合的專案 管理流程領域,以獲得更多資訊。 有關設定度量目標、指定調正度量及分析項目,取得 及分析度量活動,以及報告提供度量結果,請參考度 量與分析流程領域,以獲得更多資訊。 有關選定及推展漸進與創新的改善措施,以增進組織 的流程與技術支援組織品質及流程績效目標,請參考 組織創新與推展流程領域,以獲得更多資訊。 有關包含組織度量儲存庫的建立組織流程資產,請參 考組織流程定義流程領域,以獲得更多資訊。 有關建立並維護對組織標準流程績效的量化理解,以 支援達成組織品質及流程績效目標、提供流程績效資 料流程績效分析、流程績效基準及流程績效模式以量 化管理組織的專案,請參考組織流程績效流程領域, 以獲得更多資訊。 有關如何監控專案與採取矯正措施,請參考專案監控 流程領域,以獲得更多資訊。 特定目標及執行方法摘要 SG 1 量化管理專案 SP 1.1 設定專案目標 SP 1.2 組合已調適流程 SP 1.3 選定納入統計化管理的子流程 SP 1.4 管理專案績效 SG 2 統計化管理子流程的績效 SP 2.1 選定度量及分析技術 440 量化專案管理 SP 2.2 應用統計方法瞭解變異 SP 2.3 監控選定的子流程績效 SP 2.4 記錄統計管理資料 特定目標的特定執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 SG 1 量化管理專案 依品質及流程績效目標,以量化的方式管理專案。 SP 1.1 設定專案目標 設定並維護專案品質及流程績效目標。 事先思考要將哪些組織標準流程納入專案的已調適流 程,並思考歷史資料相關的流程績效顯示什麼意義, 經常能對設定專案品質及流程績效目標的工作有所幫 助。藉由這些事前的思考將有助於設定實際可行的專 案目標。日後當知道專案實際的績效並且更容易預測 時,也許需要修訂專案的目標。 典型的工作產品 1.專案品質及流程績效目標。 細部執行方法 1. 審查組織的品質及流程績效目標。 審查的目的是要確保專案瞭解專案必須運作的整 體經營背景。專案的品質及流程績效目標是依據 整個組織的目標發展而來。 有關組織建立品質及流程績效目標,請參考組織 流程績效流程領域,以獲得更多資訊。 2. 界定客戶、最終使用者及其他相關關鍵人員,對 品質及流程績效的需求及優先順序。 量化專案管理 441 適用於服務的能力成熟度整合模式 1.2 版 應界定需要與優先順序的品質及流程績效屬性, 舉例如下: • 期間 • 回應時間 • 可用性 • 可靠度 • 服務持續性 • 可預測性 3. 界定如何度量品質與流程績效。 考量組織所建立的度量是否適用於評量進度,以 履行客戶、使用者及其他關鍵人員的需要及優先 順序。必要時,需補充其他額外的度量。 可度量的品質屬性,舉例如下: • 系統失靈的平均間隔時間 • 客戶抱怨的數量與嚴重程度 • 可用性 • (服務績效)回應時間 可度量的流程績效屬性,舉例如下: • 週期時長 • 重工工時百分比 • 服務水準協議的符合度 有關界定度量的定義,請參考度量與分析流程領 域,以獲得更多資訊。 4. 定義並記錄專案可度量的品質及流程績效目標。 442 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 定義並記錄專案的目標包括以下事項: • 納入組織的品質及流程績效目標 • 記錄目標及目標的度量方法,這些目標須能反 映品質與流程績效需要,以及客戶、最終使用 者和其他關鍵人員的優先順序 5. 於適當時機,針對生命週期每一階段,推衍出過 渡性目標,以監控達成專案目標的進度。 預測流程未來結果的一個方法是:運用流程績效 模式,並使用在產品驗證活動(例如:同仁查核 及、測試)所界定的過渡性缺失度量,來預測未來 交付產品的潛在缺失。 6. 解決專案品質及流程績效目標間的衝突(例如:如 果一個目標沒有妥協,另一個目標將無法達成)。 解決衝突包括下列活動: • 設定各項目標的相對優先順序 • 依長期經營策略及短期需要,衡量各項備選目 標 • 邀集客戶、最終使用者、高階管理人員、專案 管理人員及其他有關的關鍵人員參與取捨的決 定 • 必要時修訂目標以反映衝突解決的結果 7. 從來源建立專案品質及流程績效目標的可追溯 性。 量化專案管理 443 適用於服務的能力成熟度整合模式 1.2 版 目標的來源,舉例如下: • 需求 • 組織的品質及流程績效目標 • 客戶的品質及流程績效目標 • 經營目標 • 與客戶及潛在客戶討論 • 市場調查 「品質機能展開(QFD)」是界定及追蹤這些需求及 優先順序的一個方法。 8. 定義並協商供應商的品質及流程績效目標。 有關在建立招標文件與供應商契約協議中加入專 案的品質及流程績效目標,請參考招標與供應商 協議管理契約發展流程領域,以獲得更多資訊。 9. 必要時修訂專案品質及流程績效目標。 SP 1.2 組合已調適流程 以過去的穩定性及能力資料為基礎,選定組成專案之 已調適流程的子流程。 有關建立並維護專案已調適流程,請參考整合的專案 管理流程領域,以獲得更多資訊。 有關包含已知及必需能力之流程元件的組織流程資產 館,請參考組織流程定義流程領域,以獲得更多資 訊。 有關組織建立流程績效基準及流程績效模式,請參考 組織流程績效流程領域,以獲得更多資訊。 444 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 從組織標準流程的流程元件及組織流程資產館的流程 產品,界定子流程。 典型的工作產品 1. 用以界定納入專案已調適流程備選子流程的準則 2. 納入專案已調適流程的備選子流程 3. 確定納入專案已調適流程的子流程 4. 所選定的子流程缺乏流程歷史績效資料時,所界 定的風險 細部執行方法 1. 建立用以界定有效備選子流程的評估準則。 界定的基礎包括: • 品質及流程績效目標 • 具體的流程績效資料 • 產品線標準 • 專案生命週期模式 • 客戶關鍵人員需求 • 法規 2. 決定欲納入統計化管理及從組織流程資產所取得 的子流程,是否適合採行統計化管理。 某子流程如果有以下的歷史紀錄,可能將更適合 採行統計化管理: • 過去類似的案例具穩定的績效 • 流程績效資料滿足專案品質及流程績效目標 量化專案管理 445 適用於服務的能力成熟度整合模式 1.2 版 歷史資料主要是由組織流程績效基準取得,不 過,並不是所有子流程都有這些資料。 3. 分析子流程的相互關係,以瞭解子流程間的關連 性以及各子流程的度量屬性。 可採用的分析技術,如系統動態模式及模擬方 法。 4. 界定無任何子流程滿足品質及流程績效目標時的 風險(也就是說,沒有具能力的子流程或不瞭解子 流程的能力)。 即使某子流程並未被選為採用統計化管理,其歷 史資料及流程績效模式,亦可能可以指出該子流 程未能滿足品質及流程績效目標。 有關界定及分析風險,請參考風險管理流程領 域,以獲得更多資訊。 SP 1.3 選定欲納入統計化管理的子流程 從專案已調適流程中,選定欲納入統計化管理的子流 程。 選定納入統計化管理的子流程通常是同步及重複進行 的流程,以界定可用的專案與組織的品質及流程績效 目標、選定子流程,以及界定用以度量與控制的流程 及產品屬性。通常在選擇流程、品質與流程績效目標 或度量的屬性時,選擇其中一者會限制其他二者,例 如:選定一個特別的流程之後,相關的度量屬性與流 程績效目標都會因選定的流程而受限制。 典型的工作產品 1. 統計化管理所要追求的品質及流程績效目標 2. 用於選定納入統計化管理子流程的準則 446 量化專案管理 3. 納入統計化管理的子流程 關於適用於服務的能力成熟度整合模式 1.2 版 4. 應度量及控制之子流程的已界定流程及產品屬 性 細部執行方法 1. 界定專案有哪些品質及流程績效目標將納入統計 化管理。 2. 界定用以選擇對達成既定品質及流程績效目標最 有影響且極具績效可預測性之子流程的準則。 用於選定子流程的準則來源,舉例如下: • 與品質及流程績效相關的客戶關鍵人員需求 • 客戶所設定的品質及流程績效目標 • 組織所設定的品質及流程績效目標 • 組織的績效基準與模式 • 其他專案子流程穩定的績效 • 法規 3. 利用選取準則選定將被統計化管理的子流程。 可能無法對某些子流程進行統計化管理(例如:新 的子流程及正在試行的技術。) 在某些情形,應用 統計技術於某些的子流程可能不符經濟效益。 4. 界定用以度量與控制子流程的產品及流程屬性。 產品及流程屬性,舉例如下: • 服務水準協議的符合百分比 • 回應時間 量化專案管理 447 適用於服務的能力成熟度整合模式 1.2 版 SP 1.4 管理專案績效 監控專案,以決定是否符合其品質及流程績效目標, 並於適當時機界定矯正措施。 有關取得與分析及使用度量資料,請參考度量與分析 流程領域,以獲得更多資訊。 進行本項決定的前提之一是:專案已調適流程所選定 的子流程已採統計化管理,並充分瞭解其流程能力。 特定目標 2 的特定執行方法對於統計化管理所選定的 子流程,提供詳細的說明。 典型的工作產品 1. 專案品質及流程績效目標達成度的估計值(亦即預 測值) 2. 達成專案品質及流程績效目標的風險文件 3. 達成專案目標過程中,用以解決缺失的行動措施 文件 細部執行方法 1. 定期審查每個選定納入統計化管理之子流程的績 效與能力,以評估達成專案品質及流程績效目標 的進度。 參考該子流程既定的品質及流程績效目標,來決 定每個所選定子流程的流程能力。這些目標是從 專案品質及流程績效目標中,以專案整體的觀點 推衍而來。 2. 定期審查生命週期中每個階段性目標的實際達成 狀況,以評估達成專案品質及流程績效目標的進 度。 3. 追蹤供應商品質及流程績效目標的達成狀況。 448 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 4. 運用關鍵屬性度量所調整的流程績效模式,以估 計達成專案品質及流程績效目標的進度。一些到 專案生命週期後期才能度量的進度,可運用流程 績效模式加以估計,例如:可運用流程績效模 式,並使用同仁查核時的過渡度量,預測交付產 品時的潛在缺失。 一些到專案生命週期後期才能度量的進度,可運 用流程績效模式加以估計,例如:可運用流程績 效模式, 藉由修護的間隔時間,預測當機頻率。 流程績效模式用於估計進度目標,該目標一定要 在專案生命週期的未來階段,才能度量。例如運 用流程績效模式,並使用同仁查核時的過渡度 量,預測交付產品時的潛在缺失。 有關建立流程績效模式,請參考組織流程績效流 程領域,以獲得更多資訊。 流程績效模式的調整是以執行先前細部執行方法 所得的結果為基礎。 5. 界定並管理達成專案品質及流程績效目標的相關 風險。 有關界定、分析及管理降低風險,請參考風險管 理流程領域,以獲得更多資訊。 量化專案管理 449 適用於服務的能力成熟度整合模式 1.2 版 風險的來源,舉例如下: • 組織度量儲存庫內缺乏穩定性及能力資料 • 子流程缺乏績效或能力 • 供應商未能達成其品質及流程績效目標 • 對供應商的能力缺乏深入瞭解 • 用於預測未來績效的組織流程績效模式內不正 確 • 預測流程績效(估計進度)時的缺失 • 其他與所界定缺失相關的風險 6. 決定並記錄在達成專案品質和流程績效目標的過 程中,用以解決缺失的行動措施。 這些行動措施的目的,是要規劃及推展正確的活 動、資源即時程,將專案帶回正軌,以達成專案 目標。 在達成專案目標過程中,用以解決缺失的行動措 施,舉例如下: • 改變品質及流程績效目標,使得這些目標在專 案已調適流程的預期範圍內。 • 改善專案已調適流程的實行過程,以降低其常 態的變異性(在不必移動平均值的情形下,藉由 降低變異,將專案績效帶回專案目標之內) • 採行可能滿足目標及管理相關風險的新子流程 及技術。 • 界定這些缺失的風險及降低風險的策略 • 終止專案 450 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 有關採取管理矯正措施至結案,請參考專案監控 流程流程領域,以獲得更多資訊。 SG 2 統計化管理子流程績效 以統計化方式管理專案的已調適流程中選定的子流程績效。 此特定目標描述在本流程領域中用以達成「量化管理 專案」特定目標的重要活動,此特定目標的特定執行 方法描述如何統計化管理依第一個特定目標下的特定 執行方法所選取的子流程,當這些選定的子流程被統 計化管理時,便可確定各子流程達成目標的能力,藉 此,就可能預測專案是否可以達成其目標,此即為量 化專案管理的關鍵。 SP 2.1 選定度量及分析技術 選定將用於統計化管理所選定子流程的度量及分析技 術。 有關設定調正度量目標,指定需執行之度量及分析、 獲得、分析與更新度量活動,以及提供度量報告結 果,請參考度量與分析流程領域,以獲得更多資訊。 量化專案管理 典型的工作產品 1. 用於(或建議採用)統計化管理所選定子流程之度量 及分析技術的定義 2. 度量的操作定義,它們在子流程的蒐集點,以及 如何確定度量的完整性 3. 度量的可追溯性,可回溯至專案品質及流程績效 目標 4. 支援自動化資料蒐集的工具化組織支援環境 細部執行方法 1. 從支援統計化管理的組織流程資產中,界定共通 性度量。 451 適用於服務的能力成熟度整合模式 1.2 版 有關針對組織標準流程,定義流程和產品的共通 性度量,請參考組織流程定義流程領域,以獲得 更多資訊。 有關共通性度量,請參考組織流程績效流程領 域,以獲得更多資訊。 可運用產品線或其他分層準則將共通性度量分 類。 2. 界定此實體所需的額外度量,以涵蓋所選定子流 程的關鍵產品及流程屬性。 在某些情形,度量可能是研究導向的,應特別標 示這些度量。 3. 界定適用於統計化管理的度量。 選擇統計化管理度量的關鍵性準則如下: • 可控制的(例如:改變子流程的執行方式,是否 能改變度量值?) • 適當的績效指標(例如:以子流程達成重要目標 的程度來看,其度量是否是個好的指標?) 子流程度量,舉例如下: • 需求變動性 • 規劃參數估計值相對於度量值的比例(例如:規 模大小、成本即時、時程) • 訓練的成效(例如:訓練計畫的完成比例及、測 驗分數) 4. 制定度量的操作定義,它們在子流程的蒐集點, 以及如何確定度量的完整性。 452 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 說明操作定義時,必須明確而不含糊,以下是兩 個重要的說明準則: • 明確傳達:說明度量的內容、如何進行度量、 度量的單位,以及納入或排除的度量項目。 • 可重複性:度量是否可以重複,在於是否給予 相同的定義以獲取相同的結果。 5. 分析指定度量與組織及專案目標之間的關聯性, 並推衍出目標,說明每個選定子流程的度量屬 性,必須符合的特定目的之度量或範圍。 6. 建構支援統計化度量資料蒐集、推導及分析的工 具化組織或專案支援環境。 此工具化的基礎包括: • 組織標準流程的描述 • 專案已調適流程的描述 • 組織或專案支援環境的能力 7. 界定適用於子流程統計化管理的適當統計分析技 術。 「一雙鞋子一種尺寸無法適合所有人」的觀念無 法可應用到統計分析技術。決定某一特定的統計 技術是否適用的因素,不僅是度量的類型,更重 要的是:度量如何使用、實際情況是否確保可應 用該技術等。選擇的適當性須隨時加以審查。 統計分析技術的範例將在下個特定執行方法中說 明。 8. 必要時修訂度量及統計分析技術。 量化專案管理 453 適用於服務的能力成熟度整合模式 1.2 版 SP 2.2 應用統計方法瞭解變異 運用選定的度量及分析技術,以建立並維護對所選定 子流程之變異的瞭解。 有關蒐集、分析及運用調正度量與分析活動,同時提 供度量結果,請參考度量與分析流程領域,以獲得更 多資訊。 蒐集並分析流程及產品度量資料,可以瞭解部分的流 程變異性,藉此可以進一步界定及說明造成變異的特 殊原因,以達成預期的績效。 流程變異的特殊原因是流程執行時產生非預期性的改 變,特殊的原因也稱為「可指定的原因」,因為這些 原因可以界定、分析及說明,以預防變異重複發生。 界定變異的特殊原因應先區隔系統變異的共同原因, 區隔的方式包括使用極端的數值或其他由子流程或相 關工作產品蒐集而來可辨別的資料形式。通常,有關 流程變異的知識、判斷異常型態來源的洞察力是發掘 特殊原因時應具備的能力。 流程變異異常型態的來源,包括: • 與流程不符 • 數個子流程對資料產生的不明影響 • 子流程內部活動的順序與時機 • 子流程的未控管輸入 • 子流程執行時環境的改變 • 時程壓力 • 不恰當的資料取樣或組合 454 量化專案管理 量化專案管理 典型的工作產品 1. 蒐集的度量資料 關於適用於服務的能力成熟度整合模式 1.2 版 2. 每個選定子流程之度量屬性的流程績效常態分布 3. 與每個選定子流程之度量屬性的流程績效常態範 圍相比較的流程績效 細部執行方法 1. 針對具適當歷史績效資料的子流程,設定試驗性 質的常態範圍。 有關組織建立流程績效基準,請參考組織流程績 效流程領域,以獲得更多資訊。 屬性的常態範圍是變異發生的正常範圍,所有流 程在執行過程中,均會出現流程及產品度量數值 上的一些變異。但存在的議題是:這些變異是起 因於流程正常執行的共同變異原因,或是起因於 某些應加以界定並解決的特殊原因。 當一子流程開始執行時,設定試驗性的常態範 圍,有時可從該子流程或相類似流程的先前實 例、流程績效基準或流程績效模式取得合適資 料。這些資料通常包含於組織度量儲存庫。執行 子流程時,可蒐集特定案例的資料,以更新及取 代試驗性的常態範圍值。不過,如果有疑慮的流 程已經過大幅的調適,或情況已和過去的執行狀 況有很大的差異,度量儲存庫的資料可能就不適 當,且不應該使用。 在某些情形,可能沒有類似的歷史資料(例如:當 引進一項新的流程、進入一個新的應用領域或子 流程已有顯著改變時)。針對這些情形,應使用子 流程的初期流程資料,建立試驗性的常態範圍, 這些試驗性的常態範圍應隨著流程的進行,適時 地調修及更新。 455 適用於服務的能力成熟度整合模式 1.2 版 決定資料是否可進行比較的準則,舉例如下: • 標準服務與服務產品線 • 應用領域 • 工作產品及任務屬性) • 工作產品及任務服務系統屬性(例如:產品規模 大小、複雜度、關鍵人員的數量) 2. 依選定的度量,蒐集執行子流程時的度量資料。 3. 針對每一度量屬性,計算流程績效的常態範圍。 計算常態範圍之統計技術,舉例如下: • 控制圖 • 信賴區間(針對分配參數) • 預測區間(針對將來的結果) 4. 界定變異的特殊原因。 在控制圖中,偵測流程變異特殊原因的一個準則 範例是:一個落在 3 個標準差控制界限外的資料 點。 偵測發生變異特殊原因的準則,是以統計理論及 經驗為基礎,並考量經濟上的可行性。當增列準 則時,雖可以更容易界定特殊原因,但出現假警 報的機會將增加。 5. 分析流程變異的特殊原因,以確認異常發生的原 因。 456 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 分析變異特殊原因之理由的技術,舉例如下: • 因果關係圖(例如,魚骨圖) • 實驗設計 • 控制圖(應用於子流程輸入或較低層次的子流程) • 分群法(例如,依對子流程實行的瞭解,將資料 分割至較小的群組,幫助區隔特殊原因) 一些異常可能僅是統計分配的極端值而不是問 題,實行流程的人通常是最具分析並瞭解變異特 殊原因能力的人。 6. 當界定變異的特殊原因之後,決定應採取什麼矯 正措施。 移除變異的流程特殊原因並不是要改變子流程, 而是說明子流程在某種程度上執行發生的錯誤或 狀況。 有關採取管理矯正措施至結案,請參考專案監控 流程領域,以獲得更多資訊。 7. 必要時針對所選定子流程的每一度量屬性,重新 計算其常態範圍。 以預示子流程已經改變的度量值為基礎(而此不是 非以預期或隨意的決策為基礎),重新計算(統計方 法估算)常態範圍。 量化專案管理 457 適用於服務的能力成熟度整合模式 1.2 版 常態範圍需要重新計算的時機,舉例如下: • 對子流程有累進的改善 • 子流程推展新的工具 • 推展新的子流程 • 所蒐集的度量資料指出,子流程的平均值已經 永久性改變,或子流程的變異已經永久性改變 SP 2.3 監控子流程的績效 監控所選定子流程的績效,以確認這些子流程滿足其 品質及流程績效目標的能力,並於適當時機界定矯正 措施。 本特定執行方法的目的是要: • 以統計的方式從子流程的預期,決定流程的行為 • 評量子流程達成其品質及流程績效目標的機率 • 以流程績效資料統計分析為基礎,界定要採取的 矯正措施。 矯正措施可包含:重新協商受影響的專案目標、界定 及實施替代的子流程,或界定並度量更低層級的子流 程,以瞭解績效資料更多的細節。 這些行動是要協助專案運用合格流程。有關「合格流 程」的定義,請參見附錄 C 詞彙。 所選定子流程的能力與其品質及流程績效目標相比較 的先決條件之一是:子流程的度量屬性顯示其績效具 穩定性及可預測性。 應針對已設定(衍生)目標的子流程及度量屬性,分析 其流程能力,並不是所有納入統計化管理的子流程或 度量屬性,都要分析其流程能力。 458 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 歷史資料可能不足以初步決定一流程是否合格,也有 可能子流程績效的常態範圍估計值,與品質及流程績 效目標逐漸產生差距。無論是上述何種情形,統計控 制隱含著監控其能力及穩定性。 典型的工作產品 1. 每一所選定子流程流程績效的常態範圍與其(衍生) 目標的比較 2. 每一子流程的流程能力 3. 每一子流程解決流程能力缺失的行動 細部執行方法 1. 比較品質及流程績效目標與度量屬性常態範圍的 差異。 本比較對子流程的每一度量屬性,評估其流程能 力。這些比較可以圖形的方式表示,藉由圖形可 顯示出常態範圍估計值與目標間的相對關係,或 作為流程能力指標,用來摘要目標與常態範圍間 的相對關係。 2. 監控品質及流程績效目標,以及選定之子流程流程 能力的變化。 3. 界定並記錄子流程的能力缺失。 4. 決定並記錄解決子流程能力缺失所必要的行動。 量化專案管理 459 適用於服務的能力成熟度整合模式 1.2 版 當所選定子流程的績效未能達成其目標時,可採 取的行動,舉例如下: • 重新推衍每一選定子流程的品質及流程績效目 標,使所選定子流程的績效可以符合目標 • 改善現行子流程的實施過程,以減小其常態的 變異性(在不必移動平均值的情形下,藉由減小 變異性,將常態範圍落入目標範圍內) • 採行有可能滿足目標及管理相關風險的新流程 元件、子流程及技術 • 針對每一子流程的流程能力缺失,界定這些缺 失的風險及風險降低策略 有關採取管理矯正措施至結案,請參考專案監控 流程領域,以獲得更多資訊。 SP 2.4 記錄統計管理資料 將統計的及品質管理資料記錄於組織度量儲存庫。 有關管理及儲存資料、調正度量定義與分析活動及提 供度量結果,請參考度量與分析流程領域,以獲得更 多資訊。 有關組織度量儲存庫,請參考組織流程定義流程領 域,以獲得更多資訊。 典型的工作產品 1. 記錄於組織度量儲存庫的統計及品質管理資料 460 量化專案管理 關於適用於服務的能力成熟度整合模式 1.2 版 需求管理 成熟度第二級的專案管理類流程領域 目的 簡介 需求管理 需求管理(Requirements Management, REQM)的目的, 在於管理專案產品及產品組件的需求,並界定這些需 求與專案計畫及工作產品間的差異。 「需求管理流程」管理專案所接收或產生的技術性、 非技術性需求,以及組織加在專案的需求。 尤其是顧客與服務提供者共同核可的需求,收錄於需 求管理流程領域。 整個流程領域中,我們使用「產品」與「產品組件」 的用語,其意思也包含了服務、服務的系統及其組 件。 書面協議能以服務水準協議(SLA)、績效工作說明書 (PWS)、目標說明書(SOO)、工作說明書(SOW)的形 式,或其他類的協議書呈現。書面協議可以是合約、 協議備忘錄、或已核可之需求文件的一部分。 在服務提供的同時應建立書面協議。需求管理的目的 是在服務期間重覆執行服務協議流程,以維持服務供 應商與客戶間的正向關係並符合雙方的需求。需求管 理流程應鼓勵開放式的溝通而非懲罰。 客戶可能來自於服務提供者組織內部或外部。 服務需求的來源包括任務績效目標(收錄於策略計畫 與人員績效計畫)、監督能力、目前績效水準與服務 461 適用於服務的能力成熟度整合模式 1.2 版 水準、在選擇設計方案期間所界定的限制、設計服務 系統時所衍生的需求(例如,可靠性、可維護性、可 用性、可支援性、安全性、任務執行、生命週期成 本、汰除管理)。 其他需考慮會影響服務需求可能源自於客戶與其他供 應商的協議(例如,客戶的外部供應商合約、維運水 準協議、協議備忘錄、分包契約)。 專案採取適當的步驟,確保議定的需求是受管理的, 以支援專案規劃和執行的需要。當專案從已核定的需 求提供者收受需求時,應與其一起審查,以便在需求 納入專案計畫前,先行解決有關議題並避免誤解。一 旦需求提供與接受的雙方達成契約,須再取得專案成 員對需求的承諾。當需求漸進發展時,專案須管理需 求的變更,並界定計畫、工作產品,以及需求間的差 異。 需求管理也記錄需求變更及其理由,並維護原始需求 與所有產品和產品組件需求之間的雙向追溯性。 (「雙向追溯性」的定義,請參見詞彙。) 專案皆有需求。就維護的活動而言,變更乃依據現有 的需求變更、設計變更或施工變更。來自顧客或使用 者的需求變更,或需求發展流程所產生的新需求皆需 加以記錄。不論來源與型式,需求變更所產生的維護 活動需加以管理。 相關流程領域 服務系統發展補充 有關發展與分析將關鍵人員需要轉換成客戶需求,以 及將需求配置於供應商交付項目,請參考採購需求服 務系統發展流程領域,以獲得更多資訊。 462 需求管理 關於適用於服務的能力成熟度整合模式 1.2 版 有關依據策略需求與策略計畫建立並維護標準化服 務,請參考策略服務管理流程領域,以獲得更多資 訊。 有關建立基準和追蹤管制需求文件的變更,請參考建 構管理流程領域,以獲得更多資訊。 有關依據計劃監督專案並管理矯正措施直到結案,請 參考專案監控流程領域,以獲得更多資訊。 有關建立並維護定義專案活動計畫,請參考專案規劃 流程領域,以獲得更多訊息。 有關與風險的界定與分析,請參考風險管理流程領 域,以獲得更多的資訊。 特定目標及執行方法摘要 SG 1 管理需求 SP 1.1 瞭解需求 SP 1.2 取得需求承諾 SP 1.3 管理需求變更 SP 1.4 維護需求的雙向追溯性 SP 1.5 界定專案工作與需求間的差異 各目標的特定執行方法 SG1 管理需求 管理需求,並界定需求與專案計畫及工作產品間之差異。 本執行方法藉由進行下列活動,使專案能全程維護一 組最新及已核定的需求: • 管理所有的需求變更 • 維護需求、專案計畫及工作產品間的關係 • 界定需求、專案計畫及工作產品間的差異 • 採取矯正措施 需求管理 463 適用於服務的能力成熟度整合模式 1.2 版 若已實施服務交付、策略服務管理,或事故解決方案 與預防流程領域,可使用需求管理流程來管理所產生 的關鍵人員需求。 有關管理矯正措施直到結案,請參考專案監控流程領 域,以獲得更多資訊。 SP1.1 瞭解需求 與需求提供者一起瞭解需求之意義。 在專案成長且需求衍生時,全部的專案活動或專業領 域將接收需求。要避免需求不知不覺的到來,須建立 準則,以指定需求接收的適當管道和正式來源。執行 需求接收活動時,須與提供者一起分析需求,以確保 對需求的意義能達成共識。這些分析和對話的結果是 一組被認可的需求。 典型的工作產品 1. 用以區別適當需求提供者的準則清單 2. 需求評估和接受準則 3. 依準則進行分析的結果 4. 被認可的需求 細部執行方法 1. 建立用以區分適當需求提供者的準則。 2. 建立客觀的需求評估及接受的準則。 服務系統發展補充 有關分析並確認需求,請參考服務系統發展流程 領域,以獲得更多資訊。 缺乏評估及接受準則常常導致需求確認不夠充 分、代價慘重的重做成本,或客戶退件。 464 需求管理 關於適用於服務的能力成熟度整合模式 1.2 版 需求評估及接受準則,舉例如下: • 清晰及適當地表達 • 完整 • 相互的一致性 • 可個別界定 • 可適當地實作 • 可驗證(即,可測試) • 可追溯 • 現行或預期的可達成能力 3. 分析需求,以確保其符合已建立之準則的要求。 4. 與需求提供者達成需求共識,使專案成員可對需 求承諾。 SP 1.2 取得對需求的承諾 取得專案成員對需求的承諾。 有關承諾的監督,請參考專案監控流程領域,以獲得 更多資訊。 上一個特定執行方法用於處理如何與需求提供者達成 需求的瞭解,本特定執行方法則處理如何取得專案成 員的同意和承諾,這些專案成員負責執行需求的必要 活動。在專案進行期間,需求將漸進發展。在需求逐 漸發展的情況下,本特定執行方法確保專案成員對最 新及已核可之需求,以及對專案計畫、活動及工作產 品所造成之變更的承諾。 典型的工作產品 1. 需求影響評量 2. 需求和需求變更的承諾紀錄 需求管理 465 適用於服務的能力成熟度整合模式 1.2 版 典型供應商交付項目 1. 供應商需求影響評估 細部執行方法 1. 評量需求對現有承諾的影響。 當需求變更或新需求產生時,應評估對專案參與 者的影響。 2. 協商並記錄承諾。 在專案成員承諾需求或需求變更之前,應先協商 對現有承諾的變更。 SP 1.3 管理需求變更 當需求於專案執行期間漸進發展時,管理需求的變 更。 有關追蹤和管制變更,請參考建構管理流程領域,以 獲得更多資訊。 需求變更的原因很多(例如,服務水準中斷)。當需要 變更或工作進行時,可能需要變更現有的需求。如何 有效管理這些新增需求或變更需求是很重要的。要有 效分析變更所造成的影響,必須知道每一需求項目的 來源,並記錄變更的原因是必要的。然而,專案或許 要追蹤需求變更程度的適當度量,以決定是否要實施 新的或修訂現有的控制方式。 若在供應商協議中所議訂的需求受到這些變更的影響 供應商協議也必須與這些變更的需求結合。 典型的工作產品 1. 需求現況 2. 需求資料庫 3. 需求決策資料庫 466 需求管理 典型供應商交付項目 1. 申請需求變更 2. 需求變更影響報告 關於適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 記錄所有的需求和需求變更,不論是專案本身產 生的或外界的要求。 2. 維護需求變更紀錄,包括每次變更的理由。 維護變更的紀錄,有助於追蹤需求變動性。 3. 從相關關鍵人員的觀點,評估需求變更的影響。 4. 使專案能取得需求和變更的資料。 SP 1.4 維護需求的雙向追溯性 維護需求與工作產品間的雙向追溯性。 本特定執行方法的目的,在於維護需求的雙向追溯性 (「雙向追溯性」的定義,參見詞彙)。當有效地管理 需求,就可建立從原始需求至其低階需求的追溯性, 並可建立由低階需求至原始需求的追溯性。這樣的雙 向追溯性可協助確定是否已徹底處理所有原始需求, 以及所有低階需求是否皆可追溯至有效的來源。 需求追溯性也可涵蓋與其他實體的關係,例如:中間 和最終產品、設計文件的變更,以及測試計畫。追溯 性可包括水準關係 (例如:跨介面),以及垂直關係。 在進行需求變更對專活動及工作產品的影響時,特別 需要追溯性。 在服務環境中,要能追蹤關鍵人員需求,或關鍵人員 需求所衍生的其他需求,到已交付的服務元件與支援 性服務系統。相反的,已交付的服務元件與支援性服 務系統應能回溯到須符合的關鍵人員需求。 需求管理 467 適用於服務的能力成熟度整合模式 1.2 版 雙向追朔並非全自動。可手動利用試算表、資料庫或 其他工具加以實現。 追溯需考慮的觀點舉例如下: • 追溯的範圍:需有追溯的界線 • 服務追溯的定義:服務元件間須有邏輯上的關 連 • 追溯的類型:水平或垂直追溯 • 整合的服務環境:主要聚焦於組織內的追溯範 圍,追溯的範圍為實體產品或產品元件所整合 的服務元件與服務。 典型的工作產品 1. 需求追溯表 2. 需求追蹤系統 細部執行方法 1. 維護需求追溯性,以確保已記錄低階(即,衍生的) 需求的來源。 從客戶到契約需求的追踪是由要求者維護。從契約 需求到衍生出來的或額外的需求是由供應商維護。 2. 維護需求追溯性,從需求到衍生需求,以及需求 所配置的功能、介面、物件、人員、流程及工作 產品等方向。 3. 製作需求追溯表。 追溯表一邊列出關鍵人員需求及衍生需求。另一 邊列出服務系統的所有組件,包含人員與耗材。 欄位的交叉處則指出特定的需求所需的服務系 統。 468 需求管理 SP 1.5 界定專案工作與需求間的差異 關於適用於服務的能力成熟度整合模式 1.2 版 界定需求與專案計畫及工作產品間的差異。 有關依據計劃監督專案,請參考專案監控流程領域, 以獲得更多資訊。 本特定執行方法用以找出需求與專案計畫及工作產品 間的差異,並啟動解決差異的矯正措施。 典型的工作產品 1. 需求與專案計畫及工作產品間的差異紀錄,包括 差異來源及條件 2. 矯正措施 細部執行方法 1. 就與需求的一致性,以及對它們的變更,審查專 案計畫、活動及工作產品。 2. 界定差異的來源。 3. 當需求基準變動時,界定有關計畫及工作產品所 需的變更。 4. 啟動矯正措施。 需求管理 469 適用於服務的能力成熟度整合模式 1.2 版 風險管理 成熟度第三級的專案管理類流程領域 目的 簡介 470 風險管理(Risk Management, RSKM)的目的,是在潛在 問題發生前便將之界定出來,以便在產品或專案的生 命週期中規劃風險處理活動,並於必要時啟動之,以 降低對達成目標的不利影響。 風險管理是一個持續的、前瞻的流程,為專案管理的 重要部分。風險管理應處理可能會危害到重要目標的 議題。持續的風險管理方法可以有效預測並降低對專 案有重大影響的風險。 有效的風險管理是透過相關關鍵人員的合作與參與, 及早且積極的界定風險,如同專案規劃流程領域所述 的「關鍵人員參與計畫」一樣。為建立自由公開之風 險提報與討論環境,橫跨所有相關關鍵人員的強勢領 導是不可或缺的。 風險管理須同時考慮有關成本、時程、績效及其他風 險的內部及外部來源。因為在專案初期進行變更或修 正的工作負荷,通常比在專案後期來得容易、花費較 低及較不具破壞性,所以,早期及積極的風險偵測是 重要的。 當在專案規劃中,專案界定和評估專案風險,以及整 個專案生命週期中管理風險,風險界定包括界定伴隨 採購流程的風險及採用一個供應商來執行專案工作。 剛開始,採購策略界定伴隨採購的風險。這個對採購 的方式是基於那些風險而規劃的。當專案進行到選擇 風險管理 風險管理 關於適用於服務的能力成熟度整合模式 1.2 版 供應商,特別對供應商的技術和管理方式的風險,對 採購的成功就變得重要。 這些與供應商能力是否符合合約需求的相關風險,包 括時程及成本目標。當專案選擇一個供應商及給供應 商協議,採購者持續管理專案風險,包括供應商符合 其契約協議相關的風險。典型地,採購者不管理已說 明或由供應商管理的風險。 領域的標準有助於決定如何預防或降低某領域的特定 風險。經由檢視業界的最佳執行方法與學習心得,可 積極的管理或降低已知的風險。 風險管理可以區分成三部分: • 定義風險管理策略; • 界定及分析風險 • 處理已界定的風險,包括必要時,執行風 險降低計畫。. 當整個專案進行其生命週期時,採購者與供應商都必 須瞭解專案風險及如何修正風險管理策略及計畫。管 理專案風險需要採購者與供應商間的緊密關係。雙方 必須分享合適的風險管理文件、瞭解風險及發展與執 行風險管理活動。 採購者與供應商關係的複雜性增加確認早期和積極的 風險的需要。例如,採購者的能力、供應商和採購者 工作的經驗、供應商的財務穩定度及所有影響專案風 險的已調和的爭論解決方案流程。 如同專案規劃流程領域和專案監控流程領域所示,剛 開始時,組織可能只專注於界定風險,以及當這些風 險發生時採取行動。風險管理流程領域描述這些特定 471 適用於服務的能力成熟度整合模式 1.2 版 執行方法之演進,以有系統的規劃、預測及降低風 險,使對專案的衝擊降至最低。 雖然風險管理流程領域主要強調的是專案,但這些觀 念亦可應用在管理組織的風險。 相關流程領域 有關界定專案風險及規劃相關利害關係人的參與,請 參考專案規劃流程領域,以獲得更多資訊。 有關建立並維護計畫,以確保在正常運作發生明顯的 中斷時服務的持續,請參考服務持續性流程領域,以 獲得更多資訊。 有關使用正式評估流程以分析可能的決策,依據已建 立的準則評估已界定的備選方案,請參考決策分析與 解決方案流程領域,以獲得更多資訊。 有關監控專案風險,請參考專案監控流程領域,以獲 得更多資訊。 有關使用正式的評估流程以評估界定專案風險的替代 方案選擇性,請參考決策分析與解決方案專案規劃流 程領域。 有關建立供應商協議與規劃利害關係人參與,請參考 招商與供應商協議發展流程領域以獲得更多資訊。 特定目標和執行方法摘要 SG 1 風險管理準備 SP 1.1 決定風險來源和類別 SP 1.2 定義風險參數 SP 1.3 建立風險管理策略 472 風險管理 SG 2 界定並分析風險 SP 2.1 界定風險 SP 2.2 評估、分類及排序風險 SG 3 降低風險 SP 3.1 發展風險降低計畫 SP 3.2 執行風險降低計畫 各目標的特定執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 SG 1 風險管理準備 執行風險管理之準備。 藉由建立並維護用來界定、分析及降低風險的策略, 來執行風險管理的準備工作。風險管理策略通常記錄 於風險管理計畫中,用以控制風險管理計畫的特定活 動和管理方法,包括界定風險來源、風險分類的計 畫,以及用來有效處理評估、限定和控制風險的參 數。 SP 1.1 決定風險來源和類別 決定風險來源和類別。 界定風險來源提供一種基礎,以系統化檢視隨時間而 改變的狀況,以發覺影響專案達成目標的情況。風險 來源來自專案的內、外部。隨著專案進展,其他的風 險來源可能隨之界定。建立風險類別提供一種機制以 蒐集和組織風險,並對嚴重影響專案目標的風險,保 持適當的警覺和注意。 採購者剛開始界定與分類風險來源及專案分類與不斷 地調整那些來源和分煩(例如,時程表、成本、來 源、契約管理、供應商執行、技術整備、人員安全、 風險相關的可信度及其他管理採購者之外的議題)。 供應商也是風險的來源之一(例如,供應商的財務穩 定度及其他組織的供應商採購的可能性)。 風險管理 473 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 風險來源清單(內部及外部) 2. 風險類別清單 細部執行方法 1. 決定風險來源。 風險來源是專案或組織內造成風險的基本因素, 專案有許多內部及外部的風險來源。風險來源界 定風險可能出現之處。 典型的內部及外部風險來源包括下列各項: • 不確定的需求 • 無前例的工作量(亦即,預估值無法獲得) • 不可行的設計 • 無法獲取的技術 • 不實際的時程估計值或配置 • 不充分的人員配置和技能 • 成本或資金議題 • 不確定或不充分的分包商能力 • 不確定或不充分的供應商能力 • 與潛在客戶、現有客戶或其代理人的溝通不足 • 連續營運的中斷 很多風險來源經常未做充分規劃就已被接受。越 早界定內部和外部的風險來源,即可儘早界定風 險,並在專案初期執行風險降低計畫,以排除風 險的發生,或降低發生時的嚴重性。 2. 決定風險類別。 474 風險管理 關於適用於服務的能力成熟度整合模式 1.2 版 風險類別為「貯存倉」的概念,用以蒐集和組織 風險。界定風險類別可協助未來整合風險降低計 畫的各項活動。 決定風險類別時,可考慮下列因素: • 專案生命週期模式的各階段 • 使用的流程類型 • 使用的產品類型 • 專案管理的風險(如:契約風險、預算風險、時 程風險、資源風險、績效風險、支援能力的風 險) 風險分類表可作為風險來源和類別的架構。 SP 1.2 定義風險參數 定義用來分析及分類風險,以及用以管制風險管理工 作量的參數。 用來評估、分類和排序風險的參數,包括下列各項: • 風險可能性(即風險發生的機率) • 風險結果(即風險發生的影響和嚴重性) • 驅動管理活動的門檻 風險參數提供共通且一致的準則,用以比較需要管理 的風險。沒有這些參數,則由風險引起的非預期變 更,將很難估計其嚴重程度;在風險降低計畫中,也 很難排定必要行動的優先順序。 風險管理 475 適用於服務的能力成熟度整合模式 1.2 版 因為情況隨時間而變化,專案應記錄用以分析與分類 風險的參數,以在專案執行期間提供參考。透過這些 參數的運用,掌變更發生時,風險能容易的被重新分 類及分析。 專案可使用失效模式與影響分析(FMEA)的技術,來 檢查服務系統內,或已選定的服務交付流程內的潛在 失效風險。這些技術可提供風險參數設定的參考。 典型的工作產品 1. 風險評估、分類及排定優先順序的準則 2. 風險管理需求(例:控制與核准層級、再評量的時 間間隔等) 細部執行方法 1. 定義一致性的準則,以評估及量化風險的可能性 及嚴重程度。 透過使用一致性的準則(例如:可能性或嚴重程度 的範圍)可共同瞭解不同風險之衝擊,使適度的檢 查,並保證獲得管理者注意。在管理不同的風險 方面(例如:人員安全相對於環境污染),保證最終 結果的一致性是重要的(例如:環境污染的高影響 風險和人員安全的高影響風險一樣重要)。風險的 量化可提供比較風險差異的基礎。 2. 定義每個風險類別的門檻 對每一風險類別,可建立門檻以決定風險的可接 受性或不可接受性、風險的優先順序,或啟動管 理作為。 476 風險管理 門檻的範例,舉例如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 專案門檻值可建立為:當產品成本超過目標成 本百分之 10,或當成本績效指標(CPI)降到 0.95 以下時,可與資深管理階層共同研商。 • 時程門檻值可建立為:當時程績效指標(SPI)降 到 0.95 以下時,可與資深管理階層共同研商。 • 績效門檻值可建立為:當關鍵項目(如處理器使 用率或平均反應時間)超過預期設計的百分之 125 以上,可與資深管理階層共同研商。 對每個已界定的風險建立監控點,以供採取更積 極的風險監控作為,或通知執行降低風險計畫。 這些監控點可依需要日後再調修。 3. 定義某風險類別門檻的範圍。 風險的評估並不特別限定需以定性或定量方式執 行。範圍的定義(或範圍的條件),可用來界定風險 管理投入程度,以避免資源過度消耗。範圍的訂 定,可排除某個類別的風險來源,亦可排除發生 低於某個頻率的情況。 SP 1.3 建立風險管理的策略 建立並維護風險管理的策略。 周詳風險管理策略說明的事項如下: 風險管理 • 風險管理投入的範圍 • 使用於風險之界定、分析、降低、監控及溝通 的方法及工具 • 專案特定的風險來源 • 如何組織、分類、比較及整合風險 • 用以對已界定風險採取行動的參數,包括可能 性、結果及門檻 477 適用於服務的能力成熟度整合模式 1.2 版 • 風險降低所使用的技術,例如:雛型製作、試 行、模擬、備選方案設計或漸進式發展 • 定義風險度量,以監控風險狀況 • 風險監控或再評量的時間間隔 風險管理策略應由共同的成功願景所導引,這願景從 交付產品、成本及對任務之適用性的觀點,來描述對 未來專案結果的期望。風險管理策略通常記錄於組織 或專案的風險管理計畫,並由相關的關鍵人員審查, 以增進承諾和瞭解。 風險管理策略應於專案早期就開始發展,以積極的界 定與管理相關風險。透過關鍵風險之早期界定與評 估,使得專案能研擬風險處理方法,調整專案定義, 並依據關鍵風險配置資源。 典型的工作產品 1. 專案風險管理策略 SG 2 界定與分析風險 界定並分析風險,以決定其相對的重要性。 風險的嚴重程度會影響用於處理已界定風險的資源, 以及何時需要適當之管理階層關切的時機。 風險分析對所界定的內、外部風險來源來界定風險, 再對每個已界定風險決定其可能性和影響程度。風險 分類提供處理風險所需的資訊,它是依據已建立的風 險類別,以及風險管理策略所發展的準則來進行評 估。為了能有效處理和充分應用風險管理資源,可把 相關風險組成不同的群組。 478 風險管理 SP 2.1 界定風險 界定並記錄風險。 關於適用於服務的能力成熟度整合模式 1.2 版 完整成功的風險管理之基礎,在界定可能會負面影響 工作投入或計畫的潛在問題、危險、威脅及弱點。風 險必須先用容易明瞭的方式來界定與描述後,才能適 當的被分析與處理。用簡潔的敘述記錄風險,包括風 險發生的內容、條件及結果。 風險界定應是有組織及透徹的方法,以找出影響目標 達成的可能或實際的風險。為了有效起見,風險界定 不應試圖說明每一可能事件,而無論其是否極不可能 發生。使用由風險管理策略發展出來的類別與參數, 以及已界定的風險來源,可提供適用於風險界定的規 範及效率。已界定的風險是啟動風險管理活動的基 準。風險應定期審查,以重新檢查可能的風險來源和 狀況變更,以揭露自風險管理策略前次更新以來,忽 略或不存在的風險與來源。 風險界定著重於界定風險,而非給予責難,管理者決 不可使用風險界定活動的結果來評估個人的績效。 界定風險的方法有很多,典型的界定方法如下: • 檢查專案分工結構圖的每個元件 • 使用風險分類表來評量風險 • 訪談相關領域的專家 • 由類似產品的比較來審查風險管理投入 • 檢查學習心得文件或資料庫 • 檢查設計規格和契約書需求 風險管理 479 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 已界定的風險清單,包括風險發生的內容、條件 及結果 典型的供應商交付項目 1. 界定風險的清單,包括風險發生的內容、情形及 結果。 細部執行方法 1. 界定與成本、時程及績效相關的風險 檢查成本、時程及績效風險對專案目標的衝擊程 度。可能發現有潛在風險不在專案目標的範圍 內,卻對客戶的利益非常重要。例如:發展成 本、產品取得成本、備品(或替代品)成本及產品處 理(汰除)成本等風險隱含在設計中。 客戶可能並未考慮到支援現場產品或交付服務的 所有成本。客戶雖然未必需要主動管理那些風 險,但應被告知風險。適當時,應該在專案和組 織層級,檢查並實施此種決策的機制,尤其是對 於影響專案執行驗證與確認產品能力的風險。 除了以上所界定的成本風險外,其他的成本風險 包含與贊助資金額、資金估計及預算分配有關的 議題。服務協議相關的風險,如依賴供應商的程 度、客戶流程以及不切實際的服務水準也應加以 考慮。 時程風險包括與規劃的活動、主要事件及里程碑 相關的風險。 480 風險管理 關於適用於服務的能力成熟度整合模式 1.2 版 績效風險包含與下列相關的風險: • 需求 • 服務中斷 • 符合服務水準 • 客戶流程的影響 • 分析與設計 • 新技術應用 • 實體規模大小 • 形狀 • 重量 • 生產與製造 • 功能績效及操作 • 驗證 • 確認 • 績效維護屬性 績效維護屬性是指某些特徵,這些特徵會讓使用 中的產品或服務提供所需的績效,例如:維持安 全和保密績效。 還有其他非屬成本、時程或績效上的風險類別。 風險管理 481 適用於服務的能力成熟度整合模式 1.2 版 以下是其他風險的範例: • 罷工 • 依賴客戶提供的資源(例如,器材、設備) • 營運彈性 • 依賴供應商 • 供應來源縮減 • 科技循環時間 • 競爭 • 過度信任主要人員 2. 審查可能影響專案的環境因素。 專案經常疏忽的風險,包含那些被認為在專案範 圍外的風險(即專案無法控制他們是否發生,但可 降低其衝擊),包含天氣、自然災害、政治變化及 電信故障等風險。 3. 審查分工結構圖所有元件,作為風險界定的一部 分,以協助確保所有的工作投入均已考慮 4. 審查專案計畫的所有元件,做為風險界定的一部 分,以確保專案在各方面均已考慮 有關界定專案風險,請參考專案規劃流程領域, 以獲得更多資訊 5. 記錄每個風險之內容、條件及可能的結果 風險說明通常以標準的格式記錄,包含風險內 容、條件及發生的結果。風險內容提供關於風險 的額外資訊,例如風險出現的相對時間順序、納 入考量的風險週遭環境或條件,以及任何疑慮或 不確定性 482 風險管理 6. 界定每一風險相關的關鍵人員 關於適用於服務的能力成熟度整合模式 1.2 版 SP 2.2 評估、分類及排序風險 利用定義的風險種類及參數,評估及分類每個已界定 的風險,並決定其相對的優先處理順序 風險評估在指定每個已界定風險之相對重要性是需要 的,並用以決定管理階層在何時需給予適當的注意。 依據風險間相互關係將風險匯集起來,並於某匯集層 級上發展方案,通常是有用的。當一個風險由較低層 級風險向上彙集而形成時,必須小心謹慎,以確保未 忽略重要之較低層級的風險。 總體來說,風險評估、分類及排序的活動,有時被稱 為”風險評量”或”風險分析”。 典型的工作產品 1. 風險清單及風險被指定的優先順序 細部執行方法 1. 利用已定義的風險參數,評估已界定的風險 根據定義的風險參數,評估每個風險並指定數 值,數值可包括可能性、結果(即,嚴重性或衝擊 度)及門檻。可整合這些指定的風險參數值以產生 額外的度量,例如:風險曝光程度可用來排列風 險的優先順序,以便處理。 通常具有 3 到 5 個數值的量尺,可用來評估可能 性和結果。 可能性可分類為微乎其微、不太可能、可能、非常 可能,或近乎確定。 風險管理 483 適用於服務的能力成熟度整合模式 1.2 版 結果分類的範例,舉例如下: •低 •中 •高 • 可忽略 • 微小 • 重要 • 嚴重 • 災難 機率值經常用來量化可能性。結果通常和成本、 時程、環境衝擊或人員度量值相關(例:人力時間 損失的嚴重程度)。 風險評估經常是困難且費時的工作,可能需要特 定的專門知識或群組技術,以評量風險和獲得對 排定優先順序的信心。此外,優先順序隨著時間 進展可能需要重新評估。量化的風險結果可提供 已界定風險作為比較的基礎。 2. 依照定義的風險類別,將風險分類並分組 將風險歸類到已定義的風險類別,可提供一個根 據風險的來源、分類表或專案組件,審查風險的 方法。相關或相同的風險可歸成一類,以便有效 處理,並記錄相關風險之間的因果關係。 3. 排列降低風險的優先順序 依據指定的風險參數,決定每個風險相對的優先 順序,應使用清楚的準則來決定風險的優先順 序。風險優先順序可協助確定降低風險的資源能 484 風險管理 關於適用於服務的能力成熟度整合模式 1.2 版 用在最有效的範圍,使其對專案有最大的正面影 響。 SG3 降低風險 適當地處理及降低風險,以減少對目標達成的不利衝擊。 處理風險的步驟,包括研訂風險處理方案、監控風 險,以及超過所定義的門檻時,執行風險處理活動。 對於選定的風險,應研訂和執行風險降低計畫,以主 動減少風險發生的潛在衝擊。風險降低的規劃也可包 括緊急應變計畫,以對所選定的風險,儘管在嘗試降 低其風險後,仍能處理其可能發生的衝擊。在風險管 理策略中,定義啟動風險處理活動的風險參數。 SP 3.1 研訂風險降低計畫 依風險管理策略所定義之對專案影響最大的風險,研 訂風險降低計畫。 風險降低規劃很重要的一部份是針對每個關鍵性的風 險,研訂可能的行動方案、替代方案、返回點,並對 每個風險皆有建議的行動方案。特定風險的風險降低 計畫包括規避、降低及控制風險發生可能性的技術和 方法,或風險發生時遭受的損失程度(有時稱作「緊 急應變計畫」),或上述兩者。風險需被監控,且當 其超過門檻值時應展開風險降低計畫,以使受衝擊的 部分回歸到可接受的風險等級。如果風險無法降低, 則可採取緊急應變計畫。只有風險結果評定為高或無 法接受時,才對該風險研訂風險降低計畫和緊急應變 計畫,其他的風險可能僅是接受,並簡單地監控。 風險管理 485 適用於服務的能力成熟度整合模式 1.2 版 風險處理方案,通常包括下列各種備選方案: • 風險規避:改變或降低需求,但仍符合使用者 需要 • 風險控制:採取主動的步驟,以降低風險 • 風險移轉:重新配置設計需求,以降低風險 • 風險監控:就指定之風險參數的變化,觀察並 定期重新評估風險 • 風險接受:對風險有認知,但不採取任何動作 通常,特別針對「高影響」的風險,應產生多種風險 處理方法。 在中斷營運持續力的案例中,風險管理的處理方 法舉例如下: • 保留資源以因應中斷事件 • 可用的備援設備清單 • 關鍵人員的備援人員 • 測試緊急應變系統的計畫及結果 • 公佈的緊急應變程序 • 緊急事件中,主要聯絡人及資訊資源的傳播清 單 在很多情況中,風險會被接受或被觀察。若風險被判 定太低而不需正式的風險降低計畫,或似乎沒有降低 風險的可行方法,則通常接受該風險。一旦風險被接 收,就必須記錄決定的理由。當績效、時間或風險曝 光程度(亦即,可能性和結果的組合)的門檻能被客觀 定義、驗證及記錄之後,風險才可觀察,並於必要時 啟動風險降低計畫,或緊急應變計畫。 486 風險管理 風險管理 關於適用於服務的能力成熟度整合模式 1.2 版 影響專案(例如,時程、品質或由於供應商風險所曝 露的風險)的供應商風險門檻在供應商協議中配合逐 步擴大的程序特別說明,如果門檻超過的話。 有關評估替代方案與選擇方案,請參考決策分析與解 決方案流程領域,以獲得更多資訊。 應儘早且充分地考慮技術的展示、模型、模擬、試行 及雛型,做為風險降低計畫的一部分。 典型的工作產品 1. 對每個已界定風險的處理選項之紀錄 2. 風險降低計畫 3. 緊急應變計畫 4. 追踪與說明每一個風險的負責人員清單 細部執行方法 1. 決定風險的等級及門檻,以定義風險何時變成無法 接受,並啟動風險降低計畫或緊急應變計畫。 風險等級(利用風險模式而獲得)是一種度量,由達 成目標的不確定性和無法達成目標的結果所組 成。 為提供方法來瞭解風險,必須清楚瞭解並定義風 險程度和門檻,因風險程度和門檻會限定規劃的 或可接受的績效範圍。為了確保適當的排序(根據 嚴重性)和相關管理回應,正確的風險分類是必要 的。可設定多重門檻,以啟動不同等級的管理回 應。通常風險降低計畫的執行門檻,會設定在緊 急應變計畫執行門檻之前。 2. 界定負責處理每個風險的個人或團隊 3. 決定實施每個風險之風險降低計畫的成本與效 益。 487 適用於服務的能力成熟度整合模式 1.2 版 應檢驗風險降低活動產生的效益相對於將耗用的 資源。就如同其他的設計活動,可能需要發展替 代計畫,並評量每個替代計畫的成本與效益,而 後選擇最佳的計畫來實行。 4. 發展專案整體的風險降低計畫,以協調個別的風 險降低計畫和緊急應變計畫。 完整的風險降低計畫可能無法負擔。所以,應作 取捨分析,以對風險降低計畫之發展排定優先順 序。 5. 針對選取的關鍵風險,研訂當其發生時的緊急應 變計畫。 依需要研訂和實施風險降低計畫,以在風險變成 問題前主動降低風險。儘管有最佳的努力,有些 風險可能無法避免且成為衝擊專案的問題。對關 鍵的風險研訂緊急應變計畫,以描述專案在衝擊 發生時,可能採取的行動。其目的是定義風險處 理的積極計畫,或為降低風險(風險降低計 畫),或為回應風險(緊急應變計畫),但無論 那一種,都是管理風險。 有些風險管理文獻可能把緊急應變計畫當作風險 降低計畫的同義詞或一部分,這些計畫也可能與 風險處理計畫或風險行動計畫一起說明。 SP 3.2 執行風險降低計畫 定期監控每一風險的狀況,並適當地執行風險降低計 畫。 為了在工作期間有效控制和管理風險,需遵守事先安 排的計畫,定期監控風險及其狀況,以及風險處理活 動的結果。風險管理策略定義風險狀況應再評量的間 隔。這個活動可能導致發現新風險,或可能需要重新 規劃或重新評量新的風險處理方案。在任一情況,風 488 風險管理 風險管理 關於適用於服務的能力成熟度整合模式 1.2 版 險可接受的門檻應與風險狀況做比較,以決定是否需 要執行風險降低計畫。 採購者與供應商分享擇定的風險。追踪與解決或管控 伴隨採購流程的風險直到它降低。這個監控包括可能 由供應商逐漸擴大的風險。 典型的工作產品 1. 更新後的風險狀況清單 2. 更新後的風險可能性、結果及門檻的評量 3. 更新後的風險處理方案清單 4. 更新後的風險處理行動清單 5. 風險降低計畫或風險處理方案清單 6. 更新後的風險處理行動方案清單 7. 風險降低計畫 細部執行方法 1. 監控風險狀況 風險降低計畫啟動後,仍然要監控風險。評量門 檻以檢查是否要執行緊急應變計畫。 應使用監測的機制。 2. 提供方法,以追蹤未完成的風險處理行動項目直 到結案。 有關管理矯正措施直到結案,請參考專案監控流 程領域,以獲得更多資訊。 3. 當監控的風險超過定義的門檻時,引用選定的風 險處理方案。 風險處理經常只針對判斷為「高等」或「中等」 的風險。對於已知風險之風險處理策略可能包括 489 適用於服務的能力成熟度整合模式 1.2 版 避免、降低及控制風險可能性的技術和方法,或 控制風險(預期的事件或情況)發生時,遭受損失程 度的技術和方法,或上述兩者。因此,風險處理 包括風險降低計畫和緊急應變計畫。 發展風險處理的技術,以避免、降低及控制不利 專案目標的衝擊,並根據可能的衝擊,提出可接 受的結果。處理風險的活動,需要適當的資源並 規劃於計畫與基準時程表之中。此類重新規劃的 工作需要密切考慮前後相接或有相依性之先期工 作或活動的影響。 有關修改專案計畫,請參考專案監控及管理流程 領域。 4. 針對每個風險處理活動,建立時程或某段期間的 績效,包括起始日期和預計的完成日期。 5. 對每個計畫提供持續性的資源承諾,以使風險處 理活動成功的執行。 6. 蒐集風險處理活動的績效度量。 490 風險管理 供應商協議管理 成熟度第二級的專案管理流程領域 關於適用於服務的能力成熟度整合模式 1.2 版 目的 供應商協議管理(Supplier Agreement Management, SAM)的目的,在管理取得供應商的產品和服務。 簡介 T 這個流程領域的範圍說明取得交付給專案客戶或包 含在服務系統裏的產品、服務和產品及服務組件。這 個流程領域的執行方式可能被使用在其他有益於專案 的目的上(例如,購買消耗品)。 整個流程領域,在使用“專案"及“產品組件"術語 時,它們要表達的包括服務、服務系統及其組件。 供應商協議管理流程領域,包含下列各項活動: • 決定取得的型式 • 選擇供應商 • 建立並維護供應商協議 • 執行供應商協議 • 監督選商流程 • 評估選商工作產品 • 接受交付的取得產品 • 確保取得的產品成功的移轉到專案 供應商協議管理 491 適用於服務的能力成熟度整合模式 1.2 版 專案所取得的有形的與無形的產品,成為交付給 客戶的一部分服務或成為服務系統的一部分的例 子如下: • 與外部供應商藉由服務層級協議維護特定的設 備,當做設施維護服務的一部分。 • 為服務訓練使用者,當訓練藉由內部供應商執 行時,當做操作層級協議(OLA)的一部 分。 • 經由委外協議供應醫院的醫護服務。 • 經由餐飲合約供應會議的餐點。 • 在收到訂單,由購買代理商購買和交付溝通的 設備。 • 在加油站販賣石油 • 當訂購時,由交付服務方交付車輛 • 銀行的ATM提款機 • 網站搜尋引擎的組件 • 航空公司的飛機 • 租車中心的車輛 通常專案取得的產品,決定於服務系統發展和規劃的 早期階段。 本流程領域不直接適用於供應商整合到專案團隊的約 定,以及使用者與產品發展者(例:整合團隊)相同 的管理流程和報告。這些情形通常是由其他流程或功 能(可能是專案的外部功能)來處理。不過,本流程領 域的一些特定執行方法可用於管理這類供應商的正式 協議。 492 供應商協議管理 關於適用於服務的能力成熟度整合模式 1.2 版 此流程領域一般不是用來說明供應商也是專案客戶的 情形。這些情況通常由與客戶非正式的協議或專案與 客戶簽訂的整體服務協議中,客戶所提供的項目的規 格來處理。在後者情形,此流程領域的某些特定執行 方式可用來管理服務協議,雖然其他可能不行,由於 客戶與一般供應商的關係其實是不同且相對的。 依經營的需要,供應商可能有多種型態,包括內部的 供應商(亦即是組織內部,專案之外的供應商)、製造 與研發的供應商,以及商業化的供應商等。有關「供 應商」的定義,請參見詞彙。 建立正式協議以管理組織與供應商的關係。正式協議 是指一個組織(代表專案)與供應商間的任何法律協 議,它可能是一份合約書、授權/許可、服務水準協 議,或者是協議備忘錄。根據本正式協議(意即是供 應商協議),供應商交付產品給專案。 相關流程領域 服務系統發展補充 有關發展與分析關鍵人員需求和發展服務系統,參考 服務系統發展流程領域,以獲得更多資訊。 有關監控專案是否符合計畫及管理矯正措施直到結 案,請參考專案監控流程領域,以獲得更多資訊。 有關維護雙向的需求追溯,請參考需求管理流程領 域,以獲得更多資訊。 供應商協議管理 493 適用於服務的能力成熟度整合模式 1.2 版 特定目標及執行方法摘要 SG 1 建立供應商協議 SP 1.1 決定取得方式 SP 1.2 選擇供應商 SP 1.3 建立供應商協議 SG 2 滿足供應商協議 SP 2.1 執行供應商協議 SP 2.2 監督選定之供應商流程 SP 2.3 評估選定之供應商工作產品 SP 2.4 接受取得的產品 SP 2.5 確認產品的移轉 各目標的特定執行方法 SG 1 建立供應商協議 建立並維護與供應商的協議。 SP 1.1 決定取得方式 決定欲取得之每一產品或產品組件的取得方式。 有關界定取得產品及產品元件管理需求,包括從供應 商取得之產品的需求追溯,請參考需求管理流程領 域,以獲得更多資訊。 有許多取得方式可供專案使用,以取得產品和產品組 件。 494 供應商協議管理 SP 1.2 取得方式,舉例如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 採購產品 • 經由供應商協議得到產品 • 由內部供應商處得到產品 • 從企業的其他部分得到服務 • 由客戶處得到產品 • 上述各種方式的組合,例如:經由合約修改現 成品或經由外部供應商與企業內其他部門共同 發展產品 需要現成品時,須關切產品的評估及選擇,對專案來 說,供應商可能也是關鍵。選擇決策的思考要件,包 含專利權議題及產品的可供應性。 典型的工作產品 1. 產品和產品組件的取得方式清單 選擇供應商 評估供應商滿足專案指定需求與已建立準則之能力, 選擇供應商。 服務系統發展補充 有關發展與分析關鍵人員需求,參考服務系統發展流 程領域,以獲得更多資訊。 有關使用對照已建立的準則來評估已界定的替代方案 的正式評估流程來分析可能的決策,請參考決策分析 與解決方案流程領域,以獲得更多資訊。 供應商協議管理 495 適用於服務的能力成熟度整合模式 1.2 版 應建立準則,以反映專案成敗的重要因素。 重要因素,舉例如下: • 供應商的所在地 • 供應商類似工作經驗及執行紀錄 • 工程能力 • 可執行工作的成員和設施 • 相似情形的先前經驗 • 由供應商交付的類似產品的客戶滿意度 典型的工作產品 1. 市場研究 2. 備選的供應商名冊 3. 優先選擇的供應商名冊 4. 趨勢研究或評估準則的其他紀錄、備選供應商的優 缺點分析,以及選商的理由 5. 招商文件和需求 細部執行方法 1. 建立並記錄評估潛在供應商的評估準則。 2. 界定潛在的供應商,並分發招商文件和需求。 執行此活動的一個積極態度是執行市場研究以確 認將取得的候選產品的潛在來源,包括客製化產 品供應商或現成產品販賣商的候選人。 參考組織創新與推展流程領域的流程來源的例子 與技術改善,如何推行及評估這類的改善。 3. 依據評估準則,評估廠商建議書。 496 供應商協議管理 關於適用於服務的能力成熟度整合模式 1.2 版 4. 評估各備選供應商的相關風險。 有關評估專案風險,請參考風險管理流程領域, 以獲得更多資訊。 5. 評估備選供應商執行工作的能力。 評估備選供應商執行工作之能力的方法,舉例如 下: • 評估類似應用的經驗 • 評估類似產品的顧客滿意度 • 評估類似工作的執行狀況 • 評估管理能力 • 能力評估 • 評估可執行工作的成員 • 評估可用設施和資源 • 評估專案與備選供應商共同工作的能力 • 評估在專案計畫及承諾中,備選現成品的衝擊 當評估現成品時,應考慮下列事項: • 現成品的成本 • 將現成品併入專案的成本及工作量 • 安全性需求 • 未來產品發行的利益及衝突 未來現成產品的發行可能提供附加功能,以支援 專案已規劃或已期望的加強功能,但也有可能的 結果是供應商無法持續支援目前版本。 6. 選擇供應商。 供應商協議管理 497 適用於服務的能力成熟度整合模式 1.2 版 SP 1.3 建立供應商協議 建立並維護與供應商間的正式協議。 供應商協議是指一個組織(代表專案)與其供應商間的 白紙黑字協議。它可能是一份合約書、執照、服務層 級協議或協議備忘錄。 如果審查、監督、評估、驗收測試活動的執行,對於 取得或已取得的產品來說是適當的話,協議內容就應 該指定。 一個需要的服務可能是直接交付給服務供應商的客戶 或最終使用者。對這類所需服務的服務協議的內容應 該特別說明驗收流程是否在服務交付的前、中、後呈 現。如果供應商將持續或重複地交付服務給客戶,內 容應也要特別說明驗收流程何時及多久會被呈現(例 如,每一次服務交付,在特定的或循環的時間交付服 務的細部子集) 在法律單位間的供應商協議通常由法律或簽約顧問在 核可前予以檢視。 供應商協議應該適當地說明服務的預計結束點、服務 的最早結束點及服務移轉點。 典型的工作產品 1. 工作說明 2. 合約 3. 協議備忘錄 4. 授權協議 細部執行方法 1. 必要時,修訂供應商須履行的需求(例:產品需求、 服務水平需求),以反映供應商與專案的協商結果。 498 供應商協議管理 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 有關發展與分析關鍵人員需求,參考服務系統發 展流程領域,以獲得更多資訊。 有關需求的管理,請參考需求管理流程領域,以 獲得更多的資訊。 2. 記錄專案將提供給供應商的內容。 包含: • 專案供給的設施 • 文件 • 服務 3. 記錄供應商協議。 供應商協議應包含:工作說明書、規格、協議條 款及條件、交付清單、時程表、預算及已定義的 驗收流程。 供應商協議管理 499 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法通常包含: • 建立工作說明書、規格、協議條款及條件、交 付清單、時程表、預算及驗收流程 • 界定專案與供應商中,被授權負責變更供應商 協議的人員 • 界定需求如何變更,與如何決定、溝通及描述 供應商協議的變更 • 界定須遵循的標準和程序 • 界定專案和供應商間的關鍵依存關係 • 界定專案監督供應商的深度,包括選擇監督的 流程和將評估的工作產品(以及相對應使用的 程序和評估準則) • 界定供應商審查的方式 • 界定供應商對取得產品之持續維護與支援的責 任 • 界定取得產品的保證、所有權及使用權 • 界定驗收準則 • 界定特定的需求、範圍、服務層級及供應商提 供的溝通流程。 • 將子合約服務層級協議與承包商服務層級協議 結合。 • 確認風險處理責任適當地下放到供應商。 • 若需要確認符合性和可實施性,則審查供應商 協議的法律層面 在某些選擇現成品的案例中,除了產品授權,還 可要求供應商協議。 500 供應商協議管理 關於適用於服務的能力成熟度整合模式 1.2 版 與現成品供應商的協議,包含的範圍舉例如下: • 大量採購的折扣 • 在許可協議下,相關關鍵人員的範圍,包括專 案供應商、團隊成員,以及專案客戶 • 未來的加強計畫 • 現場支援,例如詢問及問題報告的回應 • 目前不在產品上的附加功能 • 維護支援,包括產品喪失一般可用性的支援 4. 週期性審查供應商協議,以確保正確反映與供應商 及目前風險的專案關係,以及市場條件。 5. 在履行協議或任何變更前,確保與協議有關的各 方人士都已瞭解並同意所有需求。 6. 必要時,修訂供應商協議,以反映供應商流程或工 作產品的變更。 7. 必要時,修訂專案計畫和承諾事項,包括專案流程 或工作產品的變更,以反映供應商協議內容。 有關監督承諾,請參考專案監控流程領域,以獲 得更多資訊。 SG 2 滿足供應商協議 與供應商的協議需滿足專案與供應商雙方。 SP 2.1 執行供應商協議 與供應商共同執行供應商協議所指定的各項活動。 有關監控專案及採取矯正措施,請參考專案監控流程 領域,以獲得更多資訊。 典型的工作產品 1. 供應商進度報告和績效度量資料 供應商協議管理 501 適用於服務的能力成熟度整合模式 1.2 版 2. 供應商審查文件和報告 3. 追蹤行動項目直到結案 4. 產品和文件的交付 細部執行方法 1. 據供應商協議所定義的事項,監督其進度和工作 情況,包括時程、工作量、成本及技術的績 效。 2. 供應商協議所指定的事項,進行供應商審查。 有關執行審查,請參考專案監控流程領域,以獲 得更多資訊。 審查有正式與非正式審查兩種,包含下列步驟: • 審查準備 • 確保相關的關鍵人員參加 • 執行審查 • 界定、記錄及追蹤所有行動項目直到結案 • 準備審查摘要報告,並分發給相關的關鍵人員 3. 供應商協議所指定的事項,進行供應商技術審 查。 502 供應商協議管理 技術審查通常包含: 關於適用於服務的能力成熟度整合模式 1.2 版 • 適當提供清楚的專案客戶和最終使用者之期望 和需要給供應商 • 審查供應商的技術活動,並驗證供應商對需求 的詮釋和實作是否符合專案的詮釋 • 確保已滿足技術的承諾,且技術的問題均及時 溝通和解決 • 取得供應商產品的技術資訊 • 提供適當技術資訊和支援給供應商 • 評估供應商對照服務協議目標的交付服務(例 如,服務層級協議、操作層級協議) 4. 供應商協議所指定的事項,與供應商進行管理審 查。 管理審查通常包含: • 審查關鍵性的依存關係 • 審查與供應商有關的專案風險 • 審查時程表及預算 • 審查供應商符合法律與規定的需求 供應商協議管理 技術及管理審查可以一起進行。 5. 由審查結果,改進供應商的績效,以建立和培養可 長期合作的優良供應商。 為改善的可能資源到供應商績效或組織-供應商 關係可以來自分析技術和管理審查的結果,同時 廣泛的審查可以確保業務需求和承包義務的結 合。對供應商協議廣泛的審查是定期舉辦的,以 確保業務需求和承包義務的結合。在審查時界定 的改善可以加以記錄,並包含在改善計畫中。 503 適用於服務的能力成熟度整合模式 1.2 版 6. 監督與供應商有關的風險,必要時採取矯正措 施。 有關界定與分析風險,請參考風險管理流程領 域,以獲得更多資訊。 欲監督的風險資源,舉例如下: • 供應商繼續有效交付服務的能力 • 供應商的生存能力 • 保密協議涵括的項目 • 合約條款和條件 • 替代供應商的可利用度 SP 2.2 監督選定之供應商流程 選擇、監督及分析供應商所使用的流程。 供應商流程對專案成功的重要性(例如複雜性的因 素、重要性的因素)應被監督。監督流程的選擇必須 考慮供應商流程在專案中的影響。 在較大的專案,希望有顯著的子合約及監督重要流 程。對較小的、較不重要的組件,流程的選擇可以決 定監督是否適當。在這些極端之間,應考量欲監督的 擇定流程的整體風險。 如未謹慎的執行監督,可能會出現二種極端狀況,一 種是具侵略性且繁重,另一種是沒有助益且無效。所 以,應有充分的監督,以儘早發現可能會影響供應商 履約能力的議題。 監督執行時若沒有足夠的關心,極端表現是侵略性及 煩人的,另一種極端表現是無法獲得資訊及無效率 的。盡可能早一點有足夠監督能力,來發覺議題,這 會影響供應商的能力,是否滿足供應商協議的需求。 504 供應商協議管理 關於適用於服務的能力成熟度整合模式 1.2 版 一旦資料從監督擇定的供應流程中獲得,進行分析以 決定是否有嚴重的議題。 將專案與供應商間的角色和關係記錄下來,以協助確 認對供應商的有效監督和管理能被完成。 典型的工作產品 1. 已選定要被監督的流程或不選擇的理由清單 2. 活動報告 3. 績效報告 4. 績效曲線 5. 差異報告 細部執行方法 1. 界定對專案的成功具關鍵性的供應商流程 2. 監督已選擇的供應商流程,以符合協議的需求 3. 分析已選定之供應商流程的監督結果,以儘早發現 可能會影響供應商履約能力的議題。 趨勢分析可使用內部和外部資料。 4. 決定與記錄解決偵測到的議題的措施。 有關管理矯正措施到結案,請參考專案監控流程 領域,以獲得更多資訊。 SP 2.3 評估所選定之供應商工作產品 從供應商選擇及評估工作產品 本執行方法的使用範圍,限定於提供專案的供應商, 特別是因其複雜度或關鍵性,而有風險的專案。本特 定執行方法的目的,在於評估供應商所生產的工作產 品,以儘早發現會影響供應商履約能力的議題。經選 定用以進行評估的工作產品,應包括可儘早洞察品質 供應商協議管理 505 適用於服務的能力成熟度整合模式 1.2 版 議題的關鍵性產品、產品組件及工作產品。在低風險 的情況下,它不需要選擇任何工作產品來評估。 典型的工作產品 1. 選定用以評估的工作產品清單或不選定理由清單 2. 活動報告 3. 差異報告 細部執行方法 1. 界定對專案的成功具關鍵性的工作產品,以儘早發 現議題。 對專案成功具關鍵性的供應商工作產品,舉例如 下: • 需求 • 分析 • 架構 • 文件 • 服務員工計畫 • 服務程序 2. 評估已選擇工作產品 評估工作產品,確保以下事項: • 衍生需求是可追溯至較更高階的需求 • 架構是可行性的,並滿足產品未來的成長及再 使用的需要 • 產品的操作和支援文件是足夠的 • 工作產品之間是一致的 506 供應商協議管理 關於適用於服務的能力成熟度整合模式 1.2 版 • 產品及產品組件(例,客製的及現成的及客戶 提供的產品)可以被整合 • 服務員工計畫是可行的。 • 服務程序是完整的。 3. 針對評估所界定的缺點,決定行動方案,並記錄 之。 有關管理矯正措施到結案,請參考專案監控流程 領域,以獲得更多資訊。 SP 2.4 接受取得的產品 在接受取得的產品前,確保其已滿足供應商協議。 驗收流程包括適當的活動,例如驗收審查、測試及建 構稽核,應該在供應商協議中定義的產品驗收前完 成。 當取得的服務是將直接交付給服務供應商的客戶或最 終使用者,這個執行方式可能在服務交付給客戶或最 終使用者的前、中、後導入。你可以潛在地不只一次 導入特定的執行方式。 典型的工作產品 1. 驗收測試程序 2. 驗收測試報告 3. 差異報告或矯正計畫 細部執行方法 1. 定義驗收程序。 2. 驗收審查或測試前,先與相關的關鍵人員審查驗 收程序,並取得他們的同意。 3. 驗證所取得的產品,滿足其需求。 供應商協議管理 507 適用於服務的能力成熟度整合模式 1.2 版 驗證所取得服務是否滿足其需求,舉例如下: • 率先執行服務,並比較對照服務層級協議或操 作層級協議的結果。 • 檢驗供應商服務系統以驗證其符合需求 • 監督供應商交付給客戶的服務是否符合供應商 協議中的需求。 服務系統補充 有關驗證與確認服務系統,參考服務系統發展流 程領域,以獲得更多資訊。 4. 確認所取得的產品,滿足其非技術性的承諾。 可能包含確認適當的授權/許可、保證書、所有 權、使用權,以及支援或維護協議,均已妥當安 排,且所有支援物資均已收到。 5. 記錄驗收審查或測試的結果。 記錄服務驗收審查的結果,舉例如下: • 先導服務的評估結果報告。 • 檢驗供應商服務系統的評估結果報告。 • 根據供應商交付給客戶的服務結果的一份完整 清單。 6. 針對未通過驗收審查或測試的工作產品,建立行 動方案,並取得供應商的同意。 7. 界定、記錄及追蹤所有行動項目直到結案。 有關追蹤行動項目,請參考專案監控流程領域, 以獲得更多資訊。 508 供應商協議管理 SP 2.5 確保移交產品 關於適用於服務的能力成熟度整合模式 1.2 版 移交從供應商取得的產品予專案。 在取得的產品移交到專案、客戶或最終使用者前,須 執行適當的規劃和評估,以確保能順利移交。在這個 特定執行方式中使用“適當地",是指一個產品無法 移轉到那些取得的產品也就是服務的事實,係因為它 們不能被儲存。因此,在服務內容中,這個執行方式 只適用到不是服務的產品。 服務系統補充 有關整合服務系統組件,參考服務系統發展流程領 域,以獲得更多資訊。 典型的工作產品 1. 移交計畫 2. 訓練報告 3. 支援和維護計畫 4. 對如何持續服務義務的描述,例如擔保和授權, 需被滿足。 細部執行方法 1. 保有設施以適當地接收、儲存、整合及維護所取 得的產品。 2. 確保與接收、儲存、整合及維護所取得產品有關 的人員皆獲得適當訓練。 3. 確保在執行所取得產品的儲存、配送及使用時, 皆依據供應商協議或授權/許可所指定之條款及限 制的規定。 供應商協議管理 509 適用於服務的能力成熟度整合模式 1.2 版 服務持續性 在成熟度第 3 級的專案管理流程領域 目的 簡介 510 服務持續性(SCON)的目的是建立與維護計畫,以確 保在正常運作發生明顯的中斷時服務的持續。 服務持續性是服務交付發生顯著的中斷,準備減輕的 流程。雖然也許會降低等級,但使交付可以持續或重 新開始。這些執行方法描述如何準備服務系統及資 源,此資源為如果已可預見一個顯著的危機,賴以協 助確保最低重要的服務等級能夠持續。部份的服務持 續界定哪些服務不能被中斷與哪些服務可能被中斷及 中斷時間的長短。 服務持續性流程領域建立在風險管理流程領域的執行 方法上。風險管理流程領域描述一般系統化的方法以 界定及減輕所有的風險,以主動地減低它們對專案的 衝擊。服務持續性的執行方法是風險管理的特例,著 重在處理正常運作的明顯中斷。如果風險管理已經實 施,一些完成的能力可能用來提供更有效率的服務持 續性。然而,一般的風險管理並不確保服務持續性能 完成。因此,服務持續性流程領域的特定執行方法是 風險管理流程領域的附加要求。 服務持續性可以應用在組織層級及專案層級。因此, 在此流程領域中使用「組織」一詞,視情形可以應用 在「專案」或「組織」。 通常,服務中斷的情形是一個事件(或一連串事 件),使服務提供者幾乎不可能如常執行業務。 服務持續性 服務持續性 這類事件舉例可能如下例: 關於適用於服務的能力成熟度整合模式 1.2 版 • 基礎建設的中斷,例如明顯的設備故障及建築 物毀壞 • 自然災害,例如颶風、龍捲風及地震 • 人為事件,例如罷工及恐怖事件 服務提供者可能只有一小段時間修復及重新開始提供 服務。 服務持續性流程領域包括發展、測試及維護服務持續 性計畫。首先,必須界定下列事項: • 組織已同意交付用來支援服務的重要功能 • 交付服務所必須的資源 • 可能對資源造成的損害或威脅 • 服務提供者對損害或威脅影響的敏感度 • 對服務持續性威脅的潛在衝擊 用來發展服務持續性計畫的資訊在中斷的事件時,促 使組織重新開始服務交付。發展服務持續性計畫在收 集完上列的資訊後,通常涉及執行下列 3 個活動。所 有的活動包括收集資訊,定期地重複執行,以保持計 畫最新: • 依據先前收集的資訊,將服務持續性計畫文件化 • 將驗證服務持續性計畫的測試文件化 • 將為執行服務持續性計畫的訓練教材及訓練交付 方法文件化 最後,服務持續計畫必須被驗證。因為等到緊急事件 發生後才第一次執行服務持續計畫是不明智的,要執 行服務持續計畫程序的人員必須被訓練如何執行這些 程序。此外,必須執行定期的測試,以決定服務持續 計畫在實際緊急事件或顯著的中斷發生時是否有效, 511 適用於服務的能力成熟度整合模式 1.2 版 以及對計畫所需的變更,以使組織能持續有信賴地交 付服務。 相關的流程領域 有關交付服務,請參考服務交付流程領域,以獲得更 多的資訊。 有關評估替代方案,請參考決策分析與解決方案流程 領域,以獲得更多的資訊。 有關交付訓練,請參考組織訓練流程領域,以獲得更 多的資訊。 有關發展專案計畫,請參考專案規劃流程領域,以獲 得更多的資訊。 有關界定與分析風險,參考風險管理流程領域,以獲 得更多的資訊。 特定目標與執行方法摘要 SG1 界定重要的服務相依性 SP 1.1 界定與優先順序重要的功能 SP 1.2 界定與優先順序重要的資源 SG 2 準備服務持續性 SP 2.1 建立服務持續性計畫 SP 2.2 建立服務持續性訓練 SP 2.3 提供與評估服務持續性訓練 SG 3 驗證與確認服務持續性計畫 SP 3.1 準備驗證與確認服務持續性計畫 SP 3.2 驗證與確認服務持續性計畫 512 服務持續性 SP 3.3 分析驗證與確認的結果 依照目標的特定執行方法 關於適用於服務的能力成熟度整合模式 1.2 版 SG 1 界定重要的服務相依性 界定與記錄服務相依的重要功能與資源。 服務持續計畫的第一步是界定及優先順序重要的服 務,以使計畫即可以發展,並使這些服務在有緊急時 仍能提供。 第二步是界定與記錄這些服務相依的功能與資源。重 要的功能可能包括人工流程、自動流程、最終使用者 活動及服務交付活動本身是否事先訂定時程或是一個 勿忙中服務請求管理的結果。 已界定的與優先順序的服務、功能及資源,對服務持 續性的需求會較有效率的,而且能被如此管理。 有關管理需求,請參考需求管理流程領域,以獲得更 多的資訊。 SP1.1 界定與優先順序重要的功能 界定與優先順序必須執行以確保服務持續性的重要功 能。 為界定重要的功能,需要對所有服務系統運作有密切 瞭解。雖然很多重要的功能,但在緊急事件或服務明 顯中斷時,不是每個執行的活動都是必須維持的重要 功能。 服務持續性 513 適用於服務的能力成熟度整合模式 1.2 版 重要功能的優先順序應該反應可能中斷的服務及中斷 時間長度。(也就是,長時間與短時間的中斷)。瞭 解何項服務是重要的驅動,提供關鍵服務必要的重要 功能。 建立正確的優先順序,需要大範圍的關鍵人員參與。 有關與關鍵人員協調與合作,請參考整合專案管理流 程領域,以獲得更多的資訊。 SP 1.2 典型的工作產品 1. 經營影響分析 細部執行方法 1. 界定與優先順序組織的重要服務。 2. 界定服務相依的重要功能。 3. 分析提供功能的重要性及如果那些重要的功能不 能執行對服務的衝擊。 有關依已建立的準則,使用正式的評估流程評估 已界定的替代方案,分析可能的決策,請參考決 策分析與解決方案流程領域,以獲得更多的資 訊。 4. 優先順序即使是一個重大中斷,必須提供的重要 功能表。 界定與優先順序重要的資源 界定與優先順序確保服務持續性必要的重要資源。 重要的資源是在緊急事件中或緊急事件後,繼續其功 能或重建服務時所需的資源。這些資源一般來說,是 獨特的且難以取代的。重要的資源因此包括重要的人 員,以及重要的資產、資料與系統。重要的資源可能 514 服務持續性 服務持續性 關於適用於服務的能力成熟度整合模式 1.2 版 需要保護。適當的替代可能需要事先準備。至於資 料、備份與檔案可能需要建立。 許多組織在組織內部界定系統、人員與基礎架構時犯 了錯,忽略組織外的資源,服務持續性也需倚賴組織 外的資源。通常被忽略的資源包括可消耗品及重要的 紀錄(例如,描述法律或財務義務的文件)。 重要的資源可以經由下列的分析界定: • 服務的交付 • 對服務持續性的重要功能 • 服務協議、供應商協議及標準服務定義 • 在服務系統組件、相關的關鍵人員及交付環境中 的相依性 一般資源相依性包括來自組織內部與外部的資訊與資 料來源,以及決定關於服務交付的主要人員或執行服 務交付任務顯著貢獻的主要人員。 有關與關鍵人員協調與合作,請參考整合專案管理流 程領域,以獲得更多的資訊。 重要的資源通常落在下列類別中: • 為重新開始中斷的服務所需的緊急運作資源(例 如,主要關鍵人員,設施,消耗品) • 為保護直接受緊急事件影響的組織及個人的權利 與利益重要的法律與財務資源(例如,合約文 件)。 有關資料管理活動,請參考專案規劃流程領域的規劃 資料管理特定執行方法,以獲得更多的資訊。 典型的工作產品 1. 服務持續的優先順序 515 適用於服務的能力成熟度整合模式 1.2 版 2. 授權的代表 3. 合約重要人員的聯絡資訊 4. 援界定的重要服務功能所需的資料與系統 5. 服務協議與合約的紀錄 6. 法律條文紀錄(例如,公司條文,當地或州立或 全國政府機關的授權) 7. 人員福利、薪資及保險紀錄 8. 內部與外部需求資源清單 9. 資源相依性與相互依賴性的清單 SG 2 516 細部執行方法 1. 界定與記錄內部與外部相依性。 2. 界定與記錄服務交付相關重要人員及其角色。 3. 界定與記錄組織與相關的關鍵人員責任。 4. 界定與記錄為確保持續性所需重要功能的資源。 5. 依照資源的損失或不足的衝擊評估,優先順序資 源。 6. 對在交付環境內內部與外部人員及組織支援功 能,確保提供安全。 7. 確保在緊急事件時紀錄與資料庫被保護、可登入及 可使用。 準備服務持續性 準備服務持續性。 準備服務持續性,包括建立計畫、執行訓練以執行計 畫,以及將資源就定位,例如備援站或系統。 服務持續性 關於適用於服務的能力成熟度整合模式 1.2 版 並不是所有的服務都必須在中斷之後立即重新開始。 服務持續性計畫界定那些服務必須重新開始,以及那 些服務復原的優先順序。 此外,必須發展執行服務持續性計畫的訓練,並交付 給必須實施計畫的人員。 有關整合計畫,請參考整合專案管理流程領域,以獲 得更多的資訊。 有關發展專案計畫,請參考專案規劃流程領域,以獲 得更多的資訊。 SP 2.1 建立服務持續性計畫 建立與維護服務持續性計畫,以使組織可以重新開始 執行重要功能。 服務持續性計畫在正常運作發生顯著的中斷事件時, 提供組織明確的指引。一個組織可能維護許多不同的 計畫包含不同型態的中斷或不同型態的服務。相反 地,可能只需要一個服務持續性計畫。 典型的工作產品 1. 誰有權啟動及執行服務持續性計畫的正式說明 2. 啟動執行服務持續性計畫所需的溝通機制的清單 3. 可能妨礙組織交付服務能力的威脅與弱點的清單 4. 支援組織重要功能的替代資源與位置的清單 5. 復原順序的文件 6. 重要人員角色與責任的清單 7. 關鍵人員與用來溝通關鍵人員方法的清單 8. 如適當,處理安全相關資料的文件化方法 服務持續性 517 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 界定與記錄持續進行的服務交付的威脅與弱點。 威脅與弱點的資訊通常在其它流程與活動發展, 而被當做服務持續性計畫的輸入資料。在服務持 續性計畫中,最有可能導致計畫啟動的事件、威 脅及弱點均被紀錄下來。不同的行動可以規劃為 不同的事件類別。有關個人服務所收集的風險資 訊,可能也是計畫一部份的輸入資料。 有關界定、分析及減輕風險,請參考風險管理流 程領域,以獲得更多的資訊。 2. 記錄服務持續性計畫。 3. 與相關的關鍵人員審查服務持續性計畫。 服務系統發展補充 有關執行同仁審查,請參考服務系統發展流程領 域,以獲得更多的資訊。 4. 對服務持續性計畫與執行計畫所需的重要資訊與 功能,確保有安全的儲存與存取方式。 5. 確保足夠地保護重要的資料與系統。 解決重要資料與系統的保護,可能包括發展額外 的服務系統組件。 服務系統發展補充 有關發展服務系統,請參考服務系統發展流程領 域,以獲得更多的資訊。 518 服務持續性 關於適用於服務的能力成熟度整合模式 1.2 版 6. 記錄客戶可接受的服務等級,以在正常交付環境及 復原環境轉換時使用。(例如,中斷影響的網 點、替代的網點) 記錄不同的中斷供應情境(例如,網點、城市或 國家)的可接受的服務等級。 7. 規劃回復正常工作情形。 8. 發展實施服務持續性計畫的程序。 9. 視需要,修改服務持續性計畫。 當服務持續性計畫可能需要修改時的例子,包括 下列: • 已交付的服務有重大的變更 • 重要的功能或基礎架構變更 • 重要相依的內部與外部資源變更 • 訓練委任變更的回饋 • 準備驗證與確認服務持續性計畫界定所需的變 更 • 驗證與確認的委任結果變動 • 交付環境的變更 • 新的顯著的威脅或弱點已被界定 SP 2.2 建立服務持續性訓練 建立與維護服務持續性訓練。 訓練參加執行服務持續性計畫的人員以增加當計畫必 須執行事件時成功的可能性。它可能適合將客戶及最 終使用者包含到服務持續性訓練中。 服務持續性 519 適用於服務的能力成熟度整合模式 1.2 版 當客戶及最終使用者應該被考慮時的例子如下: • 客戶與最終使用者及服務提供者共處於同一地 點的情形,可能被同一事件影響,造成服務提 供者啟動它的服務持續性計畫。 • 執行服務持續性計畫而需要變更,可能影響客 戶或最終使用者經營執行方式的情形。 被訓練的人員型態的例子包括下列: • 回應服務請求的人員 • 提供基礎建設支援的人員(例如資訊技術、公 用建設) • 最終使用者 • 供應商 • 被選定的專案與組織經理及人員 服務持續性訓練方式的例子如下: • 角色扮演 • 以情境為基礎的訓練 • 教室指示 • 小組討論 典型的工作產品 1. 服務持續性訓練教材 細部執行計畫 1. 發展執行服務持續性訓練的策略。 520 服務持續性 關於適用於服務的能力成熟度整合模式 1.2 版 2. 發展及記錄針對服務交付的每一個類別的威脅與 弱點的服務持續性訓練。 3. 與相關的關鍵人員審查服務持續性訓練教材。 服務系統發展補充 有關執行同仁審查,請參考服務系統發展流程領 域,以獲得更多的資訊。 4. 視需要,修改訓練教材以反應在服務持續性計畫 的變更及對於訓練效率的回饋。 SP 2.3 提供與評估服務持續性訓練 提供與評估在執行服務持續性計畫時的訓練。 訓練提供指示予當顯著的中斷發生,可能需要參與執 行服務持續性計畫的人員。此外,訓練提供一個機 制,收集對於服務持續性計畫是否應該更新或澄清的 回饋。 有關提供需要的訓練,請參考組織訓練流程領域,以 獲得更多的資訊。 服務持續性 典型的工作產品 1. 訓練紀錄 2. 學生與訓練專家訓練效率的評估 3. 對服務持續性計畫建議的改善 細部執行計畫 1. 交付包括執行服務持續性計畫的訓練予適當的人 員。 2. 維護已成功完成服務持續性訓練的人的紀錄。 521 適用於服務的能力成熟度整合模式 1.2 版 3. 將執行服務持續性計畫者收集執行完備的服務持 續性訓練的回饋。 4. 分析訓練回饋,並記錄服務持續性計畫及服務持續 性訓練的改善建議。 SG 3 驗證與確認服務持續性計畫 驗證與確認服務持續性計畫。 驗證與確認服務持續性計畫有助於確保在顯著的中斷 發生前,即對不同的威脅與弱點已做好準備。這個執 行方法促成在相關的有利環境執行審查、測試及展 示。 完成驗證與確認包括選擇適合的方法、執行驗證與確 認及分析結果。 驗證方法的例子如下: • 檢查 • 同仁審查 • 稽核 • 逐步審查 • 分析 • 模擬 • 測試 • 展示 522 服務持續性 確認的方法的例子如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 與最終使用者討論,或許是正式審查的內容 • 原型展示 • 功能展示(例如,測試備份檔案系統,對協調 服務交付執行替代溝通網路,轉到手動流程) • 訓練教材先導作業 • 最終使用者及其他相關的關鍵人員測試服務系 統及其組件 服務系統發展補充 服務系統發展流程領域包含著重在驗證與確認服務系 統組件及服務的執行方法。這個指引發現當實施驗證 與確認服務持續性計畫時可能有用。 服務系統發展補充 有關驗證選定的服務系統組件與其特定的需求相比, 請參考服務系統發展流程領域,以獲得更多的資訊。 SP 3.1 準備驗證與確認服務持續性計畫 準備驗證與確認服務持續性計畫。 應定期的及以事件為導向的基礎上,執行驗證與確 認。一般來說,定期的(如,每年)執行驗證與確認 服務持續性計畫。然而,當服務系統或交付環境有重 要變更時,應審查或測試服務持續性計畫以確認服務 持續性計畫仍是正確及符合現況的。 服務持續性 523 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 確保服務持續性的驗證與確認計畫 2. 驗證與確認的評估方法 3. 執行驗證與確認所需環境的描述 4. 驗證與確認程序 5. 建立成功的驗證與確認的準則 細部執行方法 1. 發展執行驗證與確認服務持續性的計畫。 執行驗證與確認服務持續性的策略記錄驗證與確 認的需求及說明有效的驗證與確認服務持續性計 畫所需的主要原則、活動、資源及環境。 驗證與確認不是一次性的事件。其策略應該說明 驗證與確認應執行的頻率。 執行驗證與確認服務持續性計畫的計畫通常包含 下列: • 執行驗證與確認的策略 • 評估威脅與弱點的類別 • 每一類別驗證與確認的重要功能與資源 • 評估準備足夠性的方法 • 支援驗證與確認所需的環境 • 執行驗證與確認活動的時程 • 指派資源 2. 與相關的關鍵人員審查驗證與確認計畫,包括評估 方法,以及環境與所需的其他資源。 524 服務持續性 SP 3.2 關於適用於服務的能力成熟度整合模式 1.2 版 關鍵人員必須瞭解及同意驗證與確認的策略、方 法、活動、環境及資源。 3. 決定驗證與確認服務持續性計畫的程序與準則 用來確保服務持續性計畫元素的程序與準則是正 確的、有效的及與現行的威脅與弱點的類別相 關。 4. 從準備驗證與確認,界定服務持續性計畫的變更。 驗證與確認服務持續性計畫 驗證與確認服務持續性計畫。 依據已定義的計畫、方法及程序執行驗證與確認,以 確認服務持續性計畫是完整的、合理的及有效的。 典型的工作產品 1. 參與驗證與確認服務持續性計畫的人員及關鍵人 員的名冊 2. 驗證與確認服務持續性計畫的結果 細部執行方法 1. 準備執行驗證與確認的環境。 2. 執行驗證與確認服務持續性計畫。 3. 記錄驗證與確認活動的結果 SP 3.3 分析驗證與確認活動的結果 分析驗證與確認活動的結果。 服務持續性 525 適用於服務的能力成熟度整合模式 1.2 版 依照驗證與確認準則,分析驗證與確認服務持續性計 畫的結果。分析報告界定改善服務持續性計畫的元素 及界定驗證與確認方法、環境、程序及準則的問題。 典型的工作產品 1. 驗證與確認分析報告 2. 服務持續性計畫的改善建議 3. 驗證與確認的改善建議 細部執行方法 1. 比較驗證與確認服務持續性計畫的實際與期望結 果。 2. 評估是否已復原到接受的服務等級或是否達到其 他規畫的狀態。 3. 記錄改善服務持續性計畫的建議。 4. 記錄驗證與確認服務持續性計畫的建議改善。 5. 如適當,依據分析的結果,收集對服務或服務系 統組件的改善建議。 6. 提供如何解決缺失的資訊(包括驗證方法、準則及 驗證環境)及啟動矯正行動。 有關管理矯正行動至結案,請參考專案監控流程 領域,以獲得更多的資訊。 526 服務持續性 服務交付 成熟度第 2 級的服務建立與交付流程領域 關於適用於服務的能力成熟度整合模式 1.2 版 目的 簡介 服務交付的目的是根據服務協議交付服務。 服務交付流程領域主要著重下列事項: • 建立與維護服務協議 • 準備與維護服務交付方式 • 準備服務交付 • 交付服務 • 接收與處理服務請求 • 維護服務系統 服務交付涵括與客戶建立與維護文件化的協議。「服 務協議」描述要交付給客戶的服務、服務等級目標, 以及服務提供者、客戶與最終使用者的責任。 一個服務協議可能涵括多個服務或多個客戶。它的格 式可以是服務等級協議(SLA) 、績效工作說明 (PWS) 、目標說明(SOO) 、工作說明(SOW)或其他型 態的協議。服務協議可能是合約、協議備忘錄、經核 定的需求文件或其他文件的一部份。對一些簡單的案 例,它可能只是一份服務與價格的清單。 服務交付 當面對三方的需求時,服務交付流程領域支援服務提 供者與它的客戶及最終使用者一個正面的關係。服務 527 適用於服務的能力成熟度整合模式 1.2 版 交付流程應該鼓勵開放的溝通而沒有針對性的責怪。 首要的焦點是滿足最終使用者的文件化需要。 「客戶」(也就是個人、專案或組織)是負責驗收服 務或授權付款的一方。客戶界定他們對服務的需要、 購買服務,以及定義與同意服務等級目標。客戶對服 務提供者組織而言,可以是指內部或外部的,也可以 與最終使用者相同或不同,最終使用者就是服務交付 最終的受益者。 除了建立服務協議,服務交付流程領域包括準備服務 交付的執行方法,以及運作、監督與維護服務系統。 與客戶或最終使用者溝通,以界定所需交付的服務, 並經由服務系統的運作,完成服務交付以回應服務請 求。這些請求會被載明在驗收服務協議內容中。 有 2 種服務請求的型態: • 那些以持續的或安排好時程的基礎規定,即是服 務協議所決定的 • 那些由客戶或最終使用者不斷的界定為他們的需 要,以特別的基礎發展 特別的要求的例子包括下列: • 在資料庫要求一個客製的詢問,視為系統管理 服務的一部份 • 要求一個套裝當作套裝交付服務的一部份 • 界定一個維護系統的毁壞的組件當作維護服務 的一部份 • 要求一個健康檢查當作健康計畫的一部份 不論特定服務請求的本質為何,它應該藉由某一請求 管理系統的型態記錄、追踪與解決。這個方式幫助確 保所有的服務請求被滿足以符合服務協議。對服務請 528 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 求的回應也包含執行任何需要的低階規劃為較寬廣的 專案規劃活動的細部延伸。 相關的流程領域 服務系統發展補充 有關分析、設計、發展、整合、驗證與確認服務系 統,包括服務系統組件,以滿足現行或預期的服務協 議,請參考服務系統發展流程領域,以獲得更多的資 訊。 有關推展新的或顯著的變更服務系統組件,同時管理 其進行的服務交付的影響,請參考服務系統移轉流程 領域,以獲得更多的資訊。 有關建立基準與追踪及控制變更,請參考建構管理流 程領域,以獲得更多的資訊。 有關依計畫監督專案,請參考專案監控流程領域,以 獲得更多的資訊。 特定目標與執行方法摘要 SG1 建立服務協議 SP 1.1 分析現行的協議與服務資料 SP 1.2 建立服務協議 SG 2 準備服務交付 SP 2.1 建立服務交付方式 SP 2.2 準備服務系統運作 SP 2.3 建立請求管理系統 服務交付 529 適用於服務的能力成熟度整合模式 1.2 版 SG 3 交付服務 SP 3.1 接收與處理服務請求 SP 3.2 運作服務系統 SP 3.3 維護服務系統 依照目標的特定執行方法 SG 1 建立服務協議 建立與維護服務協議。 建立與維護服務提供者與客戶間的服務協議。對本流 程領域中描述的活動以持續的合作方式,鼓勵支援服 務品質改善的文化,與著重在抱怨與爭議協議中的小 細節的文化形成對比。 服務協議應在服務交付開始前建立。經常地,服務協 議會根據服務交付結果修改(例如,反應服務交付、 服務等級目標,或服務提供或客戶者的責任等所需的 變更)。 為成功維護服務提供者與客戶間的合作,定義雙方的 責任是很重要的。為服務等級設定實際可行的期望也 是重要的,需定義可度量的、可達成的服務等級。 當標準服務定義與基準服務交付資料可在組織層級中 取得,服務提供者應該使用此資料做為建立與調適協 議的基礎。 服務系統發展補充 有關發展與分析關鍵人員需求,請參考服務系統發展 流程領域,以獲得更多的資訊。 有關考量策略需要與計畫而建立與維護標準服務,請 參考策略服務管理流程領域,以獲得更多的資訊。 530 服務交付 SP 1.1 關於適用於服務的能力成熟度整合模式 1.2 版 有關監督承諾,請參考專案監控流程領域,以獲得更 多的資訊。 分析現行的協議與服務資料 分析現行的協議與服務資料,以準備期望的新協議。 這個執行方法考量已建立需求的完整內容。客戶目 標、供應商限制、服務提供者考量及現行的服務交付 資料與定義(例如,績效資料、服務等級、基準、資 源使用、監督能力、服務型錄、標準服務線)包括在 此分析中。 現行的協議與服務資料的分析,是一項服務協議生命 期間重複執行的活動。服務協議不是一個靜態的產 品。它是動態的、必須調整的,因為對服務資料與協 議持續的分析可能不斷地界定變更。 典型的工作產品 1. 對計畫、目標與服務需要的客戶描述 2. 客戶與最終使用者滿意度調查與問卷的結果 3. 提供者能力是否符合客戶需要的評量結果 細部執行方法 1. 審查可用的客戶與最終使用者需要的資料。 在建立服務協議之前,取得瞭解客戶與最終使用 者的想法是重要的。 這些想法可以包括不直接表達為服務需求的客戶 目標。 服務交付 531 適用於服務的能力成熟度整合模式 1.2 版 客戶與最終使用者需要的資料來源的例子如下: • 面對面或電話面談 • 客戶提供的計畫與目標,說明他們期望的服務 使用 • 工作的說明與相關的徵求資料 • 客戶與最終使用者的調查結果 有關蒐集與分析相關資料,請參考策略服務管理 流程領域,以獲得更多的資訊。 2. 審查服務交付與支援人員的想法。 在建立服務協議之前,獲得對服務交付與客戶及 最終使用者共事的支援人員觀點的瞭解是重要 的。這些人員最終要負責確認服務交付符合需 求。他們也對於新協議的潛在衝擊有獨特的運作 上的重要看法。這些資料可透過面對面或電話會 談,或其他方式徵求雇員的回饋(例如員工會 議、電子郵件、調查)。 3. 審查現行的服務協議與供應商協議。 審查現行的協議包括下列: • 考量客戶供應商協議對達成要求的服務的衝擊 • 依標準的服務定義(若有),審查要求的服務 需求 • 審查現行的服務等級協議與供應商協議(例如 運作等級協議、基礎合約),以符合界定的服 務需求 4. 審查可用的現行服務資料與服務系統設計。 532 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 審查現行的服務資料(例如績效資料、服務等級、 基準、事故歴史、從容量與可用度管理所提出的 資料)及能力(例如,監督能力)。使用可用的產業 指標或其他已公布的資料,特別不是由提供者先 前提出的服務需求的案例上。 有關監督與分析能力與可用度,請參考容量與可 用度管理流程領域,以獲得更多的資訊。 有關界定、控制與解決事故,請參考事故解決方 案與預防流程領域,以獲得更多的資訊。 服務系統發展補充 有關發展服務系統設計,請參考服務系統發展流 程領域,以獲得更多的資訊。 5. 分析提供請求服務的能力。 考量如何達成請求的服務交付的整體方式。 服務交付的方式包含下列製作-購買-重複使用的方 式: • 藉由使用現行服務系統的資源 • 藉由修改或建立一個服務系統以符合新的需求 • 藉由委外一些服務或服務系統組件給外部供應 商 有關確保有效率的服務系統績效與確保有效率地 提供與使用資源以支援服務需求,請參考容量與 可用度管理流程領域,以獲得更多的資訊。 服務交付 533 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 有關發展服務系統,請參考服務系統發展流程領 域,以獲得更多的資訊。 有關管理自供應商採購產品與服務,請參考供應 商協議管理流程領域,以獲得更多的資訊。 SP 1.2 建立服務協議 建立與維護服務協議。 依照服務型態、市場與服務提供者經營模式的本質, 可由客戶或服務提供者決定服務協議的啟始格式。協 議內容型態可能不同,但必須由一方建立或由另一方 建立,或必須共同協調完成。 服務協議應該包含所有的條款、情形與對持續成功的 服務交付所需的承諾,包括當適合的話,客戶與最終 使用者需負責的承諾。 534 服務交付 服務協議的條款例子如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 服務型態、等級與度量值 • 服務可用度 • 服務的驗收與品質準則 • 對客戶與最終使用者活動的可接受的衝擊 • 風險與危機的界定 • 智慧財產權的考量 • 客戶與最終使用者的角色與責任 • 客戶提供的資源 • 期望的成本、付款與資金時程 • 保全與安全的考量 有關建立標準服務與服務等級特性,請參考策略服務 管理流程領域,以獲得更多的資訊。 典型的的工作產品 1. 服務協議 細部執行方法 1. 定義服務協議的架構與格式。 定義一個符合客戶與服務提供者的服務協議架構 是重要的。服務協議架構補足或反應標準服務定 義(如有的話)的重要屬性、類別,以及架構或層 級。 服務交付 535 適用於服務的能力成熟度整合模式 1.2 版 考慮的架構的例子如下: • 以服務為基礎:服務協議是圍繞著一個服務而 安排的(例如,提供公司電子郵件)及可以涵 括幾個不同的客戶。 • 以客戶為基礎:服務協議是圍繞著一個客戶而 安排的及可以涵括對客戶的幾個服務。 SG 2 536 在一些服務的內容(例如,政府合約),客戶對 服務協議的架構與格式的期望,提出相當的細 節。在那些情形,這個細部執行方法就是深入瞭 解客戶的期望及協議架構與格式允許的調適範 圍。 2. 對草擬的服務協議,定義、協調與獲得同意。 3. 若適當,公布服務協議並提供給服務提供者、客 戶與最終使用者。 4. 若適當,以定期及事件導向為基礎,審查與修改服 務協議。 準備服務交付 執行準備服務交付。 準備服務交付包括發展一個詳細的方式,以接收與處 理服務請求,以及交付在服務協議中規定的服務。這 個方式包括界定與整合請求的服務交付活動,確保服 務系統在一個適當的服務交付環境已準備好服務交 付,以及確保已準備好所要求的消耗品。 SP 2.1 建立服務交付方式 建立與維護用來服務交付與服務系統運作的方式。 服務交付方式界定與描述對重複成功的服務交付很重 要的資源、流程與介面。 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 服務交付方式說明下列活動應如何被實踐: • 依照已建立的時程交付服務 • 準備與更新日常運作的時程 • 為執行服務交付運作而製作與轉換工作的指派 • 溝通適當的訊息給操作的人員、經理、客戶及 最終使用者 • 使用方法與工具來執行服務交付運作 • 指派與轉換責任以解決請求 • 指派與轉換責任以監督請求的狀態,以及追踪 與請求相關的行動進度 • 促使客戶與最終使用者提出請求 • 分類請求 • 針對請求管理使用方法及工具 • 蒐集、分送與分析績效資料 一個成熟的專案或組織將這些項目視為已定義的服務 系統的組件,並在一組嚴格的服務系統發展執行方法 中發展之。 有關確保有效的服務系統績效與確保有效地提供及使 用資源以支援服務需求,請參考容量與可用度管理流 程領域,以獲得更多的資訊。 服務系統發展補充 有關分析、設計、發展、整合、驗證與確認服務系 統,包括服務系統組件,以滿足現行或預期的服務協 議,請參考服務系統發展流程領域,以獲得更多的資 訊。 服務交付 537 適用於服務的能力成熟度整合模式 1.2 版 有關發展專案計畫,請參考專案規劃流程領域,以獲 得更多的資訊。 典型的工作產品 1. 服務交付方式(也就是請求管理與服務系統運作 的方式) 2. 聯絡與人員名冊清單 3. 服務請求準則 4. 內部狀態報告樣板(例如,公佈欄) 5. 外部狀態報告樣板(例如,服務請求完成通知) 細部執行方法 1. 定義決定服務請求的準則。 為能界定有效的服務請求,必須定義準則以使得 服務提供者能決定什麼是與什麼不是服務請求。 此外,一般會有準則用來區別服務請求的優先順 序與其伴隨的衝擊。 2. 定義服務請求類別與服務請求分類的準則。 完成服務請求可藉由已有的一套類別而加速完 成。這些事先決定的類別有助於適當與有效率的 資源指浱。 538 服務交付 服務交付 服務請求類別的例子如下: 關於適用於服務的能力成熟度整合模式 1.2 版 • 行政服務請求(例如,設定新的使用者,變更 密碼,重置備份檔案) • 軟體請求(例如,安裝套裝軟體,升級套裝軟 體) • 實驗室請求(例如,放射性分析,血液分析) • 超大套裝交付 • 費用查詢 3. 描述如何指派與轉轉處理服務請的責任。 這描述可能包含下列: • 誰負責解決請求 • 誰負責監督與追踪請求的狀態 • 誰負責追踪有關請求行動的進度 • 如何指派與轉換這些活動的責任 4. 界定一個或多個客戶與最終使用者可用來提出服 務請求的機制。 這個機制必須考慮群組與個人能提出請求,例如 經由電話支援,紙本格式(郵寄或親自交付), 以及經由網頁提出電子格式。 5. 界定在服務協議中為完成服務請求所定義的時數 需求。 通常,在服務交付開始之前,同意用來完成服務請 求所需的最少與最多時數,記錄在服務協議中。 6. 如需要,決定服務交付的資源需求。 539 適用於服務的能力成熟度整合模式 1.2 版 資源需求自服務協議中產生、自回應預期的服務事 故與請求的需要中產生,以及自維護服務系統以使 服務交付可以不斷地持續的需要中產生。這些資源 可能包括人員、消耗品,以及其他必須控制以確保 服務依照服務協議交付的資源。 有關確保有效的服務系統績效與確保有效地提供及 使用資源以支援服務需求,請參考容量與可用度管 理流程領域,以獲得更多的資訊。 7. 視需要,審查、調整或加強關鍵人員的溝通機制 (例如通知、狀態報告、公佈欄)。 與客戶、最終使用者、服務提供者人員及其他相關 的關鍵人員溝通的方法與工具,在服務交付的過程 中是完整的服務系統的組件。這些方法與工具(例 如,聯絡清單)可能在服務系統發展時建立,但應 定期地審查、調適,以及儘可能地補充,以符合不 斷的服務交付的需要。 服務系統發展補充 有關發展服務系統,請參考服務系統發展流程領 域,以獲得更多的資訊。 8. 記錄服務交付方式。 9. 視需要,修改交付服務的方式。 與相關關鍵人員審查並取得同意交付每一個個別界 定的服務的方式。呈現給關鍵人員的資訊應以他們 能瞭解的術語。審查應允許他們界定此方式的顧 慮。 10. 視需要修改服務交付的方式。 540 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 SP 2.2 準備服務系統運作 確認服務系統已準備好使能夠服務交付。 對服務系統運作,確保適當的服務系統組件(例如工 具、消耗品、人員、流程、程序)已準備就緒。服務 系統可能需要消耗品,以使服務交付持續。確認現行 為服務交付做的準備不是一次性的實行。這些活動應 在需要時藉由整體的服務交付手段重複地執行,甚至 當服務系統不變更時。 有關當管理進行中服務交付的效應,推展新的或重大 變更的服務系統組件,請參考服務系統移轉流程領 域,以獲得更多的資訊。 典型的工作產品 1. 監督工具門檻確認報告 2. 運作程序確認報告 3. 消耗品(例如紙張、磁鐵)確認報告 4. 購買與使用消耗品紀錄 5. 服務交付紀錄與收據 6. 展示服務系統運作的結果 細部執行方法 1. 確認適當的服務系統組件與工具可運作的。 服務交付 541 適用於服務的能力成熟度整合模式 1.2 版 服務系統工具的例子如下: • 監督工具 • 系統管理工具 • 追踪系統 • 簡報工具 • 紀錄檔案 • 分析工具 • 線上知識管理工具 • 病毒掃描工具 • 資料庫管理工具 2. 評估確認服務系統組件準備就緒的結果,並決定是 否需要矯正行動。 依照情形,任何未涵括的缺失或議題應視為服務 事故。 有關界定、控制與解泱事故,請參考事故解決方 案與預防流程領域,以獲得更多的資訊。 3. 審查服務協議中的服務等級需求,並確保在服務 系統監督工具中設計適當的門檻。 4. 發展、審查或調整服務交付程序。 細部流程、標準運作程序或工作指示可以在服務 系統發展時建立,但必須定期審查、調適,並儘 可能地補充,以符合現行的服務交付的需要。 542 服務交付 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 有關發展服務系統,請參考服務系統發展流程領 域,以獲得更多的資訊。 5. 確認必須的資源可用以執行服務交付活動與工作。 服務交付活動與工作可能包含下列:運作、監督 與修復服務系統組件;支援服務系統的使用者; 以及採購與替換服務系統組件。 6. 準備與更新細部的工作執行及依照需要監督服務 交付的時程。 7. 對新進的服務交付提供簡介,並在現行服務交付運 作的人員變更時,支援人力。 當在服務交付時有人員變更時(例如員工輪 調),針對新進人員簡介運作的現況,以確保現 行的服務交付不中斷。 8. 確保為服務交付任何必須的消耗品可用的。 補充消耗品與替換或升級的基礎架構組件程序被 文件化。視需要,根據文件化的程序採購與檢驗 服務系統消耗品。 SP 2.3 建立請求管理系統 建立與維護請求管理系統以處理與追踪請求資訊。 請求管理系統包括登入請求管理系統的儲存媒介、程 序與工具。這些儲存媒介、程序與工具可以是自動化 的,但不是必須的。例如,儲存媒介可能是檔案系統 以儲存文件。程序可能記錄在紙本,而工具可能是手 動工具或執行工作無自動化協助的器材。 服務請求通常經由服務櫃台或詢問台的功能提出。 服務交付 543 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 請求管理系統具有控制的工作產品 2. 請求管理系統的登入控制程序 細部執行方法 1. 確保請求管理系統允許在群組中的請求重新指派 與轉換。 請求可能會在不同的群組中轉換,因為進入請求 的群組可能不是最適合採取行動解決請求。 2. 確保請求管理系統允許儲存、更新與取得請求管理 資訊。 請求管理系統的例子包括: • 服務台 • 標籤追踪 • 服務紀錄書 • 工作狀態公布欄 3. 確保請求管理系統能夠有助於完成請求的資料報 告。 4. 維護請求管理系統與其內容的整合。 544 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 維護請求管理系統整合的例子如下: • 備份與儲存要求紀錄 • 將要求紀錄製成檔案 • 維護安全避免未經授權的登錄 5. 視需要,維護請求管理系統。 SG 3 交付服務 依照服務協議交付服務。 持續地交付服務及根據服務協議中的服務請求予以回 應。交付是經由服務系統運作達成,而服務系統必須 保持運作,或即時服務事故發生,也能視需要回復運 作。服務系統視不同需要而維護。 有關界定、控制與解決事故,請參考事故解決方案與 預防流程領域,以獲得更多的資訊。 SP 3.1 接收與處理服務請求 根據服務協議接收與處理服務請求。 服務請求可能經由不同的機制提出(例如,網頁格 式、電話)。一些請求也會在服務協議中界定,特別 是那些持續的或重複的安排好的服務。接收與處理服 務請求,應該經由已建立的請求管理系統協調。 典型的工作產品 1. 請求管理紀錄 2. 行動建議 3. 客戶滿意資料 4. 最終使用者收到確認請求完成。 服務交付 545 適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 接收服務請求,並確保每一個請求均是在服務協議 的範圍內。 收到服務請求的例子如下: • 客戶或最終使用者使用網頁格式提出服務請求 • 客戶或最終使用者藉由打電話到諮詢台或服務 台提出服務請求 在組織中使用諮詢台的功能,服務請求通常會提 出到這個功能。 2. 記錄有關服務請求的資訊。 當記錄服務請求資訊時,包括足夠的資訊能適當 地支援服務請求的分析與解決方案。 記錄服務請求資訊的例子如下: • 提出服務請求的人員的姓名與聯絡資料 • 服務請求的說明 • 服務請求所屬的類別 • 服務請求提出的日期與時間 • 請求中的建構項目 • 結案編碼與資訊 3. 分類與分析服務請求。 使用在服務交付方式已建立的類別,在請求管理 系統中,將服務請求指派到相關類別中。對某些 服務請求,請求的分析可能只是指選擇服務請求 的型態。對其他的服務請求(例如,升級運作系 統軟體)可能需要組成一組特別的人員以分析請 求。 546 服務交付 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 何時執行請求的分析的例子如下: • 當請求對組織或客戶的衝擊很大時 • 當解決服務請求需要花費相當大的時間或精力 時 4. 決定需要哪項資源解決服務請求。 哪個個人、群組及其他資源最適合,決定於服務 請求的型態、相關的地點及對組織或客戶的衝 擊。 5. 決定為滿足服務請求需採取的行動。 使用在服務交付方式已建立的類別,決定執行的 適當行動。在某些案例中,類別本身可能有預先 決定的行動伴隨著。 這些行動的例子包括: • 回答客戶的詢問 • 修復項目(維修服務的一部份) • 訓練最終使用者 • 提供新的消耗品或工具 6. 適當地進一步規劃行動。 執行額外的時程及其他需要的規劃,以指引已選 定的行動。當分析標準服務請求時,為解決標準 服務請求的行動可能需記錄在標準行動計畫中。 7. 適當地監督服務請求的狀態直到實現如服務協議中 所描述的內容為止。 經由服務請求的生命歷程,請求的狀態必須記 錄、追踪、視需要移轉,以及結案。 547 適用於服務的能力成熟度整合模式 1.2 版 有關監督專案是否符合計畫,請參考專案監控流 程領域,以獲得更多的資訊。 8. 審查服務請求狀態與解決方案,並與相關的關鍵人 員確認結果。 當提供服務時,溝通是重要的要素。與請求服務 的人及其他可能受影響的關鍵人員溝通,應該在 請求管理系統中服務請求的生命週期均予以考 量。通常,應該與提出服務請求的人審查已採取 行動的結果,以驗證行動實現服務請求,並獲得 提出者滿足。 在組織中使用服務台功能,服務要求的狀態經由 服務台與相關的關鍵人員溝通。 9. 結束服務請求並記錄已採取的行動與結果。 為實現服務請求執行的行動與執行行動的結果記 錄在請求管理系統中,以支援滿足未來可能有的 類似服務請求。 SP 3.2 運作服務系統 運作服務系統以依據服務協議交付服務。 這個執行方法包含執行運作服務系統所需的活動,以 依照同意的服務交付方式交付服務。運作意指服務系 統的整合績效,以及使用其流程與服務提供者人員的 其他資源,交付服務給最終使用者。 典型的工作產品 1. 已交付服務的清單 2. 服務紀錄 3. 績效報告與公布 4. 矯正行動的紀錄 548 服務交付 服務交付 5. 客戶滿意資料 關於適用於服務的能力成熟度整合模式 1.2 版 6. 請求管理資料庫紀錄 細部執行方法 1. 依據服務系統程序,操作服務系統組件。 如適當,操作服務系統組件可能包括開始或結束 它們、提供輸入資料給它們、控制它們,或處理 它們所輸出的資料。 2. 執行操作的支援活動(例如修改門檻)。 3. 依照操作程序,管理重要的相依性與服務交付時 程的行動計畫。 某些服務交付活動的管理可能足夠包含在專案管 理及度量與分析活動中,特別是在服務協議中直 接界定的服務請求。 4. 管理與控制服務交付的安全。 安全可以包括監督對安全的侵害,確保弱點被修 正,以及控制進入服務。 當交付服務時,服務系統應該確保只有在服務協 議中規定的被核定的服務會交付給被授權的人。 5. 適當的,使用監督與資料收集工具,執行低階的 服務系統組件的監督。 某些服務系統運作的監督可能適當地被包含在專 案層級的監控或度量與分析中。然而,某些服務 可能需要在個人服務請求層級的監督與資料收 集,或持續地在單一服務請求的範圍中。如此低 階的監督可能需要它自己的工具來處理資料適當 地收集、分析與報告。這些工具通常是自動化 的。 549 適用於服務的能力成熟度整合模式 1.2 版 SP 3.3 6. 若適當,根據服務協議執行實現服務請求或解決 服務事故所需要的活動。 貫穿服務請求或服務事故生命週期,其狀態必須 被記錄、追踪、視需要逐步升級,然後結案。適 當的事故解決方案可能是一個簡單的操作程序 (例如,重新開始一個失效的服務系統組件)或 它可能包含某種程度的服務系統維修。 有關界定、控制與解決事故,請參考事故解決方 案與預防流程領域,以獲得更多的資訊。 有關監督專案是否符合計畫,請參考專案監控流 程領域,以獲得更多的資訊。 7. 溝通服務請求的狀態直到結案。 8. 在服務交付或服務請求實現後,立即收集客戶滿 意資訊。 維護服務系統 維護服務系統以確保服務交付的持續。 必須維護操作的服務系統,以確保持續的能力,不斷 地依據服務協議交付服務。這個執行方法可能包含各 種型態的維護,包括如下: • 矯正性的維護(也就是修正與修復服務系統運 作能力降級的組件) • 預防性的維護(也就是經由預先規劃的活動中 預防服務事故與缺點發生) • 適應性的維護(也就是使服務系統適應一個變 更或不同的服務交付環境) • 完美化的維護(也就是發展或採媾額外的或改 善的服務系統操作能力) 550 服務交付 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 矯正性的維護可能用來執行解決服務事故或解決他們 潛在原因。 依照服務系統維護實例的型態與範圍,其他流程領域 可能貢獻與完成此工作有關的執行方法,特別是具有 下列特色的維護: • 呈現一個服務系統的需求或設計的變更(例 如,完美化維修護) • 承擔顯著的風險以實施維護活動所需的變更。 維護可以執行在服務系統的任何一部份,包括消耗 品、流程與人員。人員的維修護如同服務系統組件通 常經由訓練達成,雖然其他方法可能也適合(例如, 轉換人員到較符合其技能的角色) 服務系統發展補充 有關發展與分析關鍵人員需求,請參考服務系統發展 流程領域,以獲得更多的資訊。 有關準備服務系統移轉,請參考服務系統移轉流程領 域,以獲得更多的資訊。 有關追踪與控制變更,請參考建構管理流程領域,以 獲得更多的資訊。 典型的工作產品 1. 矯正或預防維護變更要求。 2. 維護通知 3. 預防性維護時程 細部執行方法 1. 依照當建立服務交付方式時所界定的準則,審查 維護需求並優先後順序請求。 551 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 顯著的維護活動-對服務系統的需求或設計造成 變更的活動-也從服務系統發展執行方法獲益。 2. 分析對服務系統與服務交付的衝擊。 3. 發展計畫以實施維護作業。 非固定的維護要求應該排入被同意的維護時程 中,以確保服務的可用度不會被傷害。 4. 發出維護的通知給相關的關鍵人員。 5. 適當地更新服務系統文件。 6. 依照計畫與操作程序實施與測試矯正或預防性維 護。 當適當,應在服務交付環境外執行測試。對服務 系統顯著的維護變更也應使用服務系統移轉執行 方法 7. 提出維護文件與建構變更到建構管理儲存庫。 552 服務交付 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 服務系統發展 成熟度第 3 級的服務建立及交付流程領域 目的 簡介 服務系統發展(SSD)的目的在分析、設計、發展、 整合、驗證與確認服務系統,包括服務系統組件, 以滿足現行的或預期的服務協議。 服務系統發展流程領域應用到服務系統的各個觀 點。它應用新的服務系統,也應用現行服務系統的 變更。 「服務系統」是一個整合的且相互依存的服務系統 組件的組合,用來滿足關鍵人員的需求。 「服務系統組件」是一個交付價值的流程、工作產 品、人員、消耗品或客戶或其他服務系統所需資 源。服務系統組件可能包含客戶或第三者擁有的組 件。 「服務系統消耗品」是服務提供者任何可使用的東 西,當在服務交付時停止可用或由使用變得永遠地 改變。 被認為是服務系統組件的人是那些執行服務系統任 務的人,包括提供者員工與最終使用者,使系統運 作並交付服務。 參考詞彙中「服務系統」、 「服務系統組件」、 「服務系統消耗品」及「工作產品」的定義。 組織希望改善與評鑑產品發展流程,應依靠完整的 服務系統發展 553 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 CMMI-DEV 模式,特別著重發展為有興趣的領 域。 服務提供者組織可以選擇使用 CMMI-DEV 做為改 善與評鑑服務系統發展流程的基礎。使用 CMMIDEV 模式較適合已有 CMMI-DEV 經驗及必須發展 大規模、複雜的服務系統的組織。 然而,服務系統發展流程領域提供藉由涵括在單一 流程領域的需求發展及服務系統的發展、整合、驗 證與確認而達成類似結果的替代方式。新接觸CM MI的服務供應商組織可能偏好使用服務系統發 展,特別是那些以少量的組件和介面發展簡單的服 務的組織。即使組織將 CMMI-DEV 模式用在服務 系統發展可能希望參考服務系統發展流程領域以在 服務系統組件如人員、流程及消耗品中,採用發展 執行方法時獲得有助益的指引。 特別重要記得某些服務系統組件可能只限於他們執 行的人與流程。在服務系統中那些與類似的內容是 相當簡單的,當解釋這流程領域的特定執行方法多 加以注意,以便實作能提供業務價值給服務提供者 組織。 服務系統發展流程是由服務與服務系統需求所驅 動。服務與服務系統需求是從不同來源收集而來 的,例如服務協議以及在服務交付及事故解決方案 與預防流程中界定的缺失及問題。 服務系統發展流程領域著重在下列活動: • 為服務系統收集、協調、分析、確認及配置 關鍵人員需求 554 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 • 自替代的服務系統方案評估及選擇 • 設計與建立或組合(若需要)、整合及文件 化符合需求的服務系統 • 驗證與確認服務系統以確定它們滿足預期的 需求,也在實際服務交付期間滿足客戶及最 終使用者的期望 相關的流程領域 有關維護服務系統,請參考服務交付流程領域,以 獲得更多的資訊。 有關推展服務系統,請參考服務系統移轉流程領 域,以獲得更多的資訊。 有關建立標準服務,請參考策略服務管理流程領 域,以獲得更多的資訊。 有關使用一個正式的評估流程評估已界定的替代方 案,對照已建立的準則,分析可能決策,請參考決 策分析與解決方案流程領域,以獲得更多的資訊。 有關選擇與推展漸增與創新的改善,請參考組織創 新與推展流程領域,以獲得更多的資訊。 有關管理需求,請參考需求管理流程領域,以獲得 更多的資訊。 特定目標與執行方法摘要 SG 1 發展與分析關鍵人員需求 • SP 1.1 發展關鍵人員需求 • SP 1.2 發展服務系統需求 • SP 1.3 分析與確認需求 服務系統發展 555 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 SG 2 發展服務系統 • SP 2.1 選擇服務系統解決方案 • SP 2.2 發展設計 • SP 2.3 確保介面相容性 • SP 2.4 實作服務系統設計 • SP 2.5 整合服務系統組件 SG 3 驗證與確認服務系統 • SP 3.1 準備驗證與確認 • SP 3.2 執行同仁審查 • SP 3.3 驗證選擇的服務系統組件 • SP 3.4 確認服務系統 依照目標的特定執行方法 SG 1 發展與分析關鍵人員需求 收集、分析關鍵人員需要、期望、限制與介面,並轉換成確 認的服務系統需求。 這個目標包含將收集到的關鍵人員的需要、期望與 限制轉換成需求,以用來發展可以達成服務交付的 服務系統。 需要的收集來源可能包含服務協議;標準的已定義 服務;組織的政策;與最終使用者、客戶及其他相 關關鍵人員的溝通。 這些服務需要可以定義關鍵人員期望交付的內容、 556 服務系統發展 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 說明服務的特別等級,或界定將如何、何時及對何 人交付服務的限制。 這些需要、期望及限制反之可能需要分析及詳述, 以界定已交付的服務沒有被原始來源考量所需的細 節。這個結果是一套關鍵人員的需求,以服務系統 發展人員的語言描述之,而不是以提出需求的人的 語言描述。 服務系統發展 例如,一個客戶可能要建立一個需求「維護在工單 第 25 個表格清單所列的設備」與其他可用度的比 例、平均修復時間及其他的服務等級。然而,這個 需求可能也需要不同的特別的子服務,例如診斷、 環境支援及預防性維護等,每一個它們自身隱含的 子服務需求。這些調整原本的關鍵人員可能不感興 趣或甚至不可見,但他們完整的規格是需要的,以 界定服務系統必須做以符合服務交付需求的的每件 事。 當服務需求已分析與詳述,他們最終會產出衍生的 服務系統需求,該需求定義與限制服務系統必須完 成的內容以確保交付所需的服務。例如,如果服務 有回應時間的需求,服務系統必須有衍生的需求促 使支援回應時間。 發展與分析需求的流程可以包含許多的重複,包括 所有相關的關鍵人員溝通的需求及其分歧,為了如 此每個人同意一套一致的、已定義的服務系統需 求。變更可能來自關鍵人員需求的變更,或在接續 的服務系統發展活動、服務系統移轉或服務交付時 發現的新需要。因為整個專案生命、需求發展與分 析中,需要時常變更,就不該認為只是一次性的流 程。 557 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 就像所有的需求,採取適當的步驟以確保有效地管 理經同意的一套服務與服務系統需求,以支援服務 與服務系統的發展。 有關管理需求變更,請參考需求管理流程領域,以 獲得更多的資訊。 SP 1.1 發展關鍵人員需求 收集與轉換關鍵人員的需要、期望、限制與介面成 為關鍵人員需求。 相關關鍵人員(例如:客戶、最終使用者、供應 商、建構者、測試者、製造者、運籌支援人員、服 務交付人員)是決定關鍵人員需求的基礎。分析、 調和、調整與詳述關鍵人員需要、期望、限制、介 面、操作概念與服務概念,以轉換成一套關鍵人員 需求。 從將交付服務的客戶與最終使用者收集的需求,記 錄在服務協議中。這些需求用來衍生服務系統的需 求。這些衍生需求與為服務系統收集的其他需求組 合成整套的關鍵人員需求。 有關分析現行協議與服務資料,請參考服務交付流 程領域,以獲得更多的資訊。 這些關鍵人員的需求應以關鍵人員瞭解的語言敘 述,並且夠精確地符合那些發展服務或服務系統的 需求。 關鍵人員需求的例子包括下列: • 運作需求 • 客戶交付需求 • 監督需求 558 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 • 儀器設備需求 • 文件需求 • 操作等級協議需求 • 來自與其他關鍵人員協議的需求 典型的工作產品 1. 客戶需求 2. 最終使用者需求 3. 對執行驗證與確認,客戶與最終使用者的限制 4. 員工層級的限制 細部執行方法 1. 加入相關的關鍵人員並使用方法引導出需要、期 望、限制及外部介面。 2. 引導不只是收集需求,而是主動地界定額外的需 求。此額外的需求不是由調查、分析客戶滿意 度資料、雛型、模擬等,明確地提供。 轉換關鍵人員需要、期望、限制與介面成為關 鍵人員需求。 從相關關鍵人員得到的不同資訊必須整併,遺 失的資訊必須獲得,矛盾必須解決,並記錄在 已認可的一套關鍵人員需求中。 3. 定義驗證與確認的限制。 服務系統發展 559 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 SP 1.2 發展服務系統需求 調整並詳述關鍵人員需求以發展服務系統需求。 分析關鍵人員需求並與操作概念的發展連結,以衍 生更詳細及更準確的一套需求,稱作「衍生需 求」。這些需求說明服務系統關聯服務交付的所有 觀點,包括工作產品、服務、流程、消耗品及客戶 與其他資源。 參見詞彙中「“操作概念」的定義。 衍生需求的產生從限制中,從隱含的議題考慮但並 不明確地敘述在關鍵人員需求的基準中,以及從選 定的服務系統架構、設計、發展者獨特的業務考量 及策略優先性包括產業市場趨勢所介紹的因素中。 衍生需求的廣度與深度依所需符合的關鍵人員需求 的服務系統複雜程度而有所不同。 有關建立標準服務,請參考策略服務管理流程領 域,以獲得更多的資訊。 在某些服務內容中,衍生需求可能只是像界定與量 化所需資源一樣簡單。而對某些有很多型態的組件 與介面的複雜服務系統而言,剛開始的需求會被重 複檢查,經由反覆的調整到較低層級的一組較詳細 的需求,當較滿意的解決方案被調整時,這較詳細 的需求與功能架構平行。 典型的工作產品 1. 具備關係與優先順序的衍生需求 2. 服務需求 3. 服務系統需求 4. 需求配置 560 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 5. 設計限制 6. 介面需求 7. 技術層級需求 細部執行方法 1. 發展需求並以服務及服務系統設計所需的術 語,表達需求。 2. 從解決方案選擇與設計決策的結果,衍生需 求。 3. 建立與維護變更管理與需求配置考慮的需求間 的關係。 需求間的關係可以協助設計與評估變更的衝 擊。 4. 配置對服務系統組件的需求。 關係包含相依關係,其中的需求變更可能影響 另一個需求。 5. 界定服務系統外部與內部介面。 6. 發展已界定介面的需求。 SP 1.3 分析與確認需求 分析與確認需求,並定義所需的服務系統功能。 執行需求分析以決定預計的服務交付環境的衝擊將 能夠滿足關鍵人員的需要、期望、限制與介面。依 照服務交付內容,必須考慮的因素如可行性、任務 需要、成本限制、最終使用者的異質性、潛在的市 場規模及採購策略等。也建立所需功能的定義。考 服務系統發展 561 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 量所有特定的服務交付方法,以及為功能的時間順 序產生時程的分析。 分析的目的是決定服務系統概念的備選需求,服務 系統概念會滿足關鍵人員的需要、期望及限制,然 後將這些概念轉換成廣泛的服務系統需求。與這些 活動平行的,用來評估服務交付效率的參數,依客 戶與最終使用者的輸入資料及最初的服務交付概念 決定。 需求將由與關鍵人員合作而確認。以增加最終服務 系統將如預期在交付環境中交付服務的可能性。 典型的工作產品 1. 操作概念、使用案例、活動圖表及時間表劇本 2. 服務系統及服務系統組件裝置、訓練、操作、 維護、支援及處置的概念 3. 新的需求 4. 功能架構 5. 需求缺失報告及解決的建議變更 6. 風險相關需求的評估 7. 分析方法及結果的紀錄 細部執行方法 1. 發展操作概念與劇本,包括功能、績效、維 護、支援和配置(如適當)。 562 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 建議的服務系統期望能運作,界定與發展劇本 並與關鍵人員的需要、期望與限制的詳細程度 一致。 操作概念與劇本的發展是反覆的流程。應該定 期審查操作概念與劇本,以確認他們同意需 求。這個審查可能可以逐步審查方式進行。 2. 發展一個詳細操作概念,定義服務系統、最終 使用者及環境間的互動,以及滿足操作、維 護、支援與處理的需要。 3. 建立與維護所需要功能的定義。 功能的定義,也可參考「功能性的分析」,是 服務系統設計的用途的描述。功能的定義可以 包含行動、順序、輸入資料、輸出資料或其他 資訊傳達服務系統運作的方式。 4. 分析需求以確保它們是必須的、足夠的,並平衡 關鍵人員的需要與限制。 當需求被定義,他們與更高層需求的關係及更 高層定義的功能必須被瞭解。其他的行動之一 是決定何項需求將用來追踪進度。 5. 確認需求以確保最終的服務系統將在使用者環 境如預期的執行。 SG 2 發展服務系統 選擇、設計、實作與整合服務系統組件。 一個服務系統可以包括工作產品、流程、人員、消 耗品及客戶與其他資源。 服務系統發展 563 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 一個重要且經常被忽略的服務系統組件是人的觀 點。人們執行工作如同服務系統的一部份,促使系 統運作,並且提供者員工和最終使用者也會參加這 個角色。例如,服務系統處理針對服務打進來的電 話,必須訓練可用的員工可以接收電話並使用服務 系統其他的組件適當地處理它們。另一個例子,保 險服務的最終使用者可能需要遵照先擬好的索賠流 程,以從服務系統收到服務的益處。 一個消耗品可以是由服務提供者使用的任何東西, 因為其在服務交付期間使用,而停止供應或變成永 久地變更。 例如交通服務系統使用汽油以汽油動力的交通工 具。甚至服務系統主要是由人和手動流程組成,通 常使用的消耗品如辦公室用品。消耗品在服務系統 中的角色應時時被考慮。 這目標著重在下列活動: • 評估與選擇解決方案,灒在地滿足一組適當 的需求 • 對選定的解決方案發展詳細的設計(詳細到 足以實作設計就像一個服務系統) • 視需要實作服務系統組件的設計 • 整合服務系統以便其功能可被驗證與確認 一般而言,這些活動和另一個部份重疊、一再發生 與支援。某此層級的設計相當詳細可能需要用來選 擇解決方案。雛型、先導計畫及獨立功能測試可以 用做獲得足夠知識的一種方式,以發展一組完整的 需求或從可用的替代方案中選擇。 從人們的觀點,設計可能是技術層級的規格和員工 564 服務系統發展 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 計畫,而雛型或先導專案可能試驗不同的員工計畫 以決定哪一項工作適用在某一特定的情形。從消耗 品的觀點,設計可能是必要消耗品的特色與數量的 規格說明。某些消耗品可能甚至需要實作。例如, 特定的紙本格式可能需要設計與列印以測試它們能 成為服務系統的一部份。 發展流程在服務系統中視需要重複地實作以回應需 求上的變更,或回應在驗證、確認、轉移或交付期 間未發現的問題。例如,有些在驗證和確認期間發 生的問題,可能被需求發展流程解決。這些流程的 循環和重覆,使得專案能確保,在開始交付服務給 最終使用者前,所有服務系統組件的品質。 SP 2.1 選擇服務系統解決方案 從替代解決方案選擇服務系統解決方案。 在選擇解決方案前應考慮替代解決方案及其相關的 價值。建立重要的需求、設計的議題及限制,以用 在替代解決方案的分析。考慮架構的特性能提供服 務系統改善與演進的基礎。 有關使用一個正式的評估流程評估已界定的替代方 案,對照已建立的準則,分析可能決策,請參考決 策分析與解決方案流程領域,以獲得更多的資訊。 實作這個執行方法的一個潛在的效率不佳的方式是 基於過去已經交付的服務的方式去產生解決方案。 考慮必要功能不同的配置與執行方式的替代方案是 重要的。(例如,手動與自動流程,最終使用者與 服務交付人員的責任,事前時程表與勿忙中服務請 求管理) 服務系統的組件,包括服務交付與支援功能,可能 配置給外部供應商。結果,預期供應商協議會被調 服務系統發展 565 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 查。使用外部供應的組件被認為是與成本、時程、 績效和風險有關。 外部供應的替代方案可能有或沒有修改。有時有些 項目可能需要修改觀點,例如介面或客製化某些特 性,以較能符合服務或服務系統的需求。 管理自供應商採購產品和服務,請參考供應商協議 管理流程,以獲得更多有關的資訊。 典型的工作產品 1. 替代方案篩選的準則 2. 選擇的準則 3. 服務系統組件選擇決策與理由 4. 文件化的需求與服務系統組件間的關係 5. 文件化的解決方案、評估方式和理由 細部執行方法 1. 建立已定義的選擇準則。 2. 發展替代的解決方案。 3. 選擇最能滿足已建立準則的服務系統解決方 案。 選擇最能滿足已建立準則的服務系統解決方 案,是根據服務系統不同的觀點為配置需求的 基礎。較低層的需求是由選定的替代方案產 生,並用來發展服務系統組件的設計。描述 (主要是功能性地)服務系統組件間的介面需 求。 SP 2.2 發展設計 566 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 發展服務系統與服務系統組件的設計。 「設計」一 詞在這執行方法中是參照服務系統組件 的定義及它們預期的關係;這些組件將以預期的方 式集合式地互動以達成實際的服務交付。 服務系統設計必須提供適當的內容不只為了實作, 也為服務系統生命週期的其他觀點,例如修改、轉 換、產出、維護、維持及服務交付。設計文件對相 關的關鍵人員相互瞭解設計的內容提供一項參考, 並支援未來在發展階段與接續的生命週期的階段, 對設計的變更。 一個完整的設計描述是記錄「設計套裝」文件中。 設計套件包括完整的特性與參數,包括功能、介 面、操作門檻、製造與服務流程特性(例如自動化 的功能與手動地執行),以及其他參數。已建立的 設計標準(例如,檢查表、範本、流程架構)形成 了達到一個設計文件的定義的高程度與完整性的基 礎。 其他服務相關工作產品的例子如下: • 交付服務所需人員的角色、責任、授權、 可信度及技能的描述。 • 功能性的使用個案說明服務參與者的角色 與活動。 • 最終使用者、操作者及行政人員的手動、 紙本格式、訓練教材及指引的設計或範 本。 服務系統發展 「設計人員」在此內容中是指特別說明完成要求的 567 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 任務所需的技能與技能層級,可能也包含適當的員 工層級及訓練的需要(如果為達成所需的技能層級 所需的訓練)。 「設計的消耗品」在此內容中是指特別說明需要用 來支援服務交付與服務系統運作預計使用的資源的 消耗品的資材和特色。 典型的工作產品 1. 服務系統架構 2. 服務系統組件及消耗品設計 3. 技能的描述與員工解決方案細節(例如,可利 用員工的配置,雇用永久或臨時的員工) 4. 介面設計規格與控制文件 5. 設計與服務系統組件再使用之準則 6. 製造或採購的分析結果 細部執行方法 1. 發展一個服務系統的設計。 2. 確保設計遵循配置的需求。 3. 記錄設計。 4. 使用已建立的準則,設計服務系統組件的介 面。 介面的準則時常反應重要的參數,必須定義此 參數,或至少調查以確定其可應用性。這些參 數通常是特別針對某種型態的服務系統,而且 通常伴隨安全、保全、耐久性與任務重要性的 568 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 特色。小心地決定哪些流程應該要自動化或部 份自動化,以及哪些流程要手工執行。 5. 依據已建立的準則,評估服務系統的組件是否 應發展、購買或重複使用。 SP 2.3 確保介面的相容性 管理服務系統內部與外部的介面定義、設計及變 更。 許多整合的問題是從內部及外部的介面中未知或未 管控的觀點產生的。有效的管理介面需求、規格及 設計有助於確保已實作介面的完整與相容。 在服務系統的內容中,介面可能廣泛地特徵為四個 主要的群組之一: • 人對人介面是那些代表 2 個或更多人之間的直 接或間接的溝通,他們之中任何一人可能是服 務提供者或最終使用者。例如,一個電話紙 條,定義詢問台的操作人員應該與最終使用者 的互動,定義一個直接的人與人介面。紀錄簿 與指示牌是間接的人與人介面的例子。 • 人對組件介面是那些包含人與一個或多個服務 系統組件之間的互動。這些介面包括自動化 組件的圖形使用者介面(例如,軟體應 用),以及自動化、部份自動化或非自動化 組件的操作者控制機制(例如,設備、交通 工具)。 • 組件對組件介面是那些不包括直接的人們互 動。許多互動的介面在自動化組件屬於該群 組,但有其他的可能性,例如規格限制 2 個 組件的實體搭配(例如運送的貨車,裝載區) 服務系統發展 569 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 • 複合介面是指從其他 3 個群組中的 1 個以上的 群組一起合併或分層的介面。例如,一個線 上的協助系統具有線上聊天支援可能有一個 複合介面建構在整合的人對人、人對組件, 以及組件對組件的介面組合上。 介面可能也被特微為外部或內部的介面。外部介面 是服務系統與服務系統以外的個體,包括人員、組 織和系統,的組件間的互動。內部的介面包括員 工、組別及服務提供者組織的功能間的互動。內部 介面也可以包括員工或最終使用者與服務系統組件 間的互動。 使用者介面工作產品的例子包括: • 客戶互動的手寫紀錄 • 報告的型態與頻率 • 應用程式介面 典型的工作產品 1. 依照類別列出介面類別清單 2. 服務系統組件與外部環境間的介面關係表格或 對照表 3. 當應用時服務系統組件配對的已同意定義的介 面清單 4. 介面控制工作組會議的報告 5. 更新介面的行動項目 6. 更新介面的描述或協議 570 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 審查介面對涵蓋面和完整性的描述。 應該與關鍵人員一起審查介面的描述,以避免 誤解、減少延誤及避免發展的介面不正確的運 作。 2. 管理服務系統組件的內部與外部介面定義、設 計及變更。 SP 2.4 實作服務系統設計 實作服務系統設計。 「實作」一詞在這執行方法中參考服務系統中被設 計的組件的實際產生,能不斷地整合、驗證與確 認。「實作」不是指將服務系統置入交付的環境 中。在服務系統移轉後才進行實作的流程。 在某些案例中,消耗品與人員(例如,提供者員工) 可能會「被實作」。例如,特別的紙本格式可能需 要列印出來。人的「實作」可能包含雇用新員工或 執行一個新的組織或團隊結構以處理新的責任。這 類的新結構應該在服務轉換開始之前整合、驗證與 確認。 有關推展服務系統,請參考服務系統移轉流程領 域,以獲得更多的資訊。 服務系統組件是自先前建立設計與介面中實作。實 作可以包含服務系統組件的獨立測試,且通常包含 員工與最終使用者必要的訓練教材的發展。 當實作時的活動例子如下: • 確認介面相容性 • 軟體編碼 服務系統發展 571 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 • 發展訓練教材 • 製造電子與機械零件 • 紀錄實作流程的設計程序 • 建構設備 • 建立供應商協議 • 雇用或轉移員工 • 建立組織及團隊組合 • 製造慣用的消耗品(例如,拋棄式的包裝 材料) 典型的工作產品 1. 實作的服務系統組件 2. 訓練教材 3. 使用者、操作者及維護手冊 4. 程序描述 5. 新的員工雇用與移轉的紀錄 6. 組織變更溝通的紀錄 細部執行方法 1. 使用有效率的方法以實作服務系統設計。 2. 遵循應用標準與準則。 3. 對選定的服務系統組件執行同仁審查。 4. 若適當,執行服務系統組件的獨立測試。 572 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 5. 若需要,修改服務系統。 SP 2.5 整合服務系統組件 組合與整合已實作的服務系統組件到可驗證的服務 系統。 服務系統整合應依照規劃的整合順序及可用的程序 進行。在整合前,每一個服務系統組件應已驗證符 合其介面需求。服務系統組件的手動流程應,當適 當使用必要的服務系統組件驗證符合需求時,執 行。 在整合期間,下層的組件被組合到一個較大、較複 雜的服務系統組合中,且執行較完整的服務交付功 能。這些合併的服務系統組合需檢查以有正確的交 互運作。這流程會持續到服務系統整合完成。在這 流程中,如果有界定的問題,紀錄這些問題並啟動 矯正行動。 有些服務系統可能需要與客戶或最終使用者的資源 組合以完成全部的整合。當這些資源在服務協議的 條件下可提供時,他們應該適當地併入整合活動 中。當這類資源無法自客戶及最終使用者取得時, 替代的相當資源可以暫時地置入,以能完成整體的 服務系統整合。 典型的的工作產品 1. 服務系統整合順序及其理由 2. 服務系統整合的紀錄與驗證環境 3. 服務系統整合的程序與準則 4. 例外的報告 服務系統發展 573 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 5. 組合的服務系統組件 6. 介面評估報告 7. 服務系統整合摘要報告 8. 員工計畫以說明何處與何時提供員工的順序 細部執行方法 1. 確認整合環境已準備就緒。 2. 確認已適當地界定整合所需的每一項服務系統 組件、功能根據其描述、以及所有的介面符合 其介面的描述。 3. 評估已組合完成的服務系統的介面相容性、功 能性與績效。 SG 3 驗證與確認服務系統 驗證與確認選定的服務系統組件與服務,以確保正確的服務 交付。 有些服務提供者認為所有的驗證與確認當作「測 試」。然而,在 CMMI,「測試」被認為是驗證或 確認使用的特定方法。驗證與確認在流程領域中分 別描述,以確保兩個觀點都適當地處理。 驗證方法的例子包括如下: • 檢查 • 同仁審查 • 稽核 • 逐步審查 • 分析 • 模擬 574 服務系統發展 服務系統發展補充 • 測試 • 展示 關於適用於服務的能力成熟度整合模式 1.2 版 確認方法的例子如下: • 與使用者討論,可能在一個正式的審查內 容中 • 雛型展示 • 功能呈現(例如,服務交付瀏覽、最終使 用者介面展示) • 訓練教材之試行 • 由最終使用者及相關的關鍵人員測試服務 及服務系統組件 驗證執行方法包括驗證準備、驗證執行及矯正行動 之界定。驗證包括測試服務系統與選定的服務系統 組件對照所有選定的需求,包括現行的服務協議、 服務需求及服務系統需求。 可能驗證與確認的服務系統組件的例子,如 下: • 人員 • 流程 • 設備 • 軟體 • 消耗品 服務系統發展 確認展示已發展的服務系統將如預期的交付服務。 驗證說明服務系統是否適當地反應特定的需求。換 575 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 句話說,「驗證」確保 「你做對了」。 「確認」 則確保「你做了對的事」 。 確認活動使用的方法與驗證類似(例如,測試、分 析、檢查、展示與模擬)。這些活動著重於確保在 預期的交付環境中交付預期的服務。最終使用者與 其他相關的關鍵人員通常都參與確認活動。驗證與 確認活動通常同步進行,而且可以使用相同環境的 部份。驗證與確認活動在服務系統發展流程的不同 階段中會重複地發生。 SP 3.1 準備驗證與確認 建立與維護驗證與確認的方式及環境。 準備是需要的,以確保驗證的條件被置入於服務及 服務系統需求、設計、發展計畫及時程中。驗證包 含選擇、檢查、測試、分析及展示所有的服務系統 組件,包括工作產品、流程及消耗品資源。 為使確認的工作成功且有意義,類似的準備活動是 必須的。這些活動包括選擇服務與服務系統組件及 建立與維護確認的環境、程序及準則。最終使用者 及前線的服務交付人員參與確認活動是特別重要 的。因為他們對成功的服務交付的觀點可能與服務 系統發展者非常不同。 典型的工作產品 1. 為驗證與確認選定的服務系統組件清單 2. 每一個選定的組件的驗證與確認方法 3. 驗證與確認環境 4. 驗證與確認程序 5. 驗證與確認準則 576 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 細部執行方法 1. 選擇驗證與確認的組件及其使用的驗證與確認 方法。 服務系統組件的選擇係依照其對符合專案目標 與需求,及解決專案風險的貢獻。 2. 建立與維護需要支援驗證與確認的環境。 3. 為選定的服務系統組件,建立與維護驗證與確 認程序與準則。 SP 3.2 執行同仁審查 在選定的服務系統組件中執行同仁審查。 同仁審查涵括在由製造商同仁進行的服務系統組件 的有條理的檢驗中,以界定移除的缺失及建議的變 更。 同仁審查是重要且有效率的驗證方法。經由檢查、 結構化逐步審查或許多其他的學院審查方法實施。 典型的工作產品 1. 同仁審查時程 2. 同仁審查清單 3. 服務系統組件與工作產品的進入與輸出準則 4. 要求另一個同仁審查的準則 5. 同仁審查訓練教材 6. 為同仁審查選擇服務系統組件 服務系統發展 577 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 7. 同仁審查結果,包括議題與行動項目 8. 同仁審查資料 細部執行方法 1. 決定執行何種型態的同仁審查。 同仁審查型態的例子如下: • 檢驗 • 結構化逐步審查 • 主動的審查 2. 為選定的服務系統組件與工作產品建立與維護 同仁審查程序與準則。 3. 定義同仁審查的需求。 同仁審查應說明下列指引: • 準備必須充分 • 執行必須管理與控制 • 記錄一致的且充分的資料 • 必須記錄行動項目 同仁審查需求的例子,如下: • 資料收集 • 允入與允出準則 • 要求另一個同仁審查的準則 578 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展 4. 建立與維護檢查清單,以確保服務系統組件及 工作產品一致性地審查。 檢查清單解決項目的例子如下: • 建構規則 • 設計的指引 • 完整性 • 正確性 • 維護性 • 共同缺失型態 檢查清單視需要修改以陳述特別的工作產品型 態及同仁審查。檢查清單發展者的同仁及潛在 的使用者審查檢查清單。 5. 發展一個詳細的同仁審查時程,包括同仁審查 的訓練日期,以及何時同仁審查的資料將可提 供。 6. 準備同仁審查。 同仁審查的準備活動通常包含下列: • 界定參加每一個服務系統組件或工作產品 同仁審查活動的員工 • 界定必須參加同仁審查的主要審查者 • 準備與更新在同仁審查使用的材料,例如 檢查清單及審查準則 7. 確保服務系統組件或工作產品滿足同仁審查允 579 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 入準則,工作產品的組件足夠早可供參與者審 查,以使參加人員能適當地準備同仁審查。 8. 適當地指派同仁審查的角色。 角色的例子如下: • 領導者 • 閱讀者 • 記錄者 • 作者 9. 對選定的服務系統組件及工作產品,執行同仁審 查及界定同仁審查產生的議題。 執行同仁審查的一個目的是及早發現與移除缺 失。同仁審查在服務系統組件及工作產品發展 後,遞增地執行。 同仁審查可能執行在主要的工作產品規格、設 計、測試及實作活動及特定規劃的工作產品。 同仁審查可能執行在員工計畫、能力說明、組 織結構及服務系統中其他以人為導向的觀點。 然而,它們應該小心用來審查個人的績效與能 力,而且應該只使用到與組織中其他已有的個 人評估方式協調。 當在同仁審查中產生議題時,為修正他們應該 與主要的發展者或服務系統組件或工作產品的 經理溝通。 10. 若已定義的準則指出需要,則執行額外的同仁 審查。 11.確保同仁審查滿足允出準則。 580 服務系統發展 服務系統發展補充 關於適用於服務的能力成熟度整合模式 1.2 版 12. 記錄與儲存同仁審查準備、執行與結果的相關 資料。 一般資料是服務系統組件或工作產品名稱、同 仁審查團隊的人員組成、同仁審查的型態、每 一個審查者的準備時間、審查會議的長度、發 現的缺失數量、缺失的型態與來源等。應收集 已經同仁審查的服務系統組件或工作產品的額 外資料。 保護資料確保同仁審查資料不會被不適當地使 用。同仁審查的目的是驗證合適的發展與界定 缺失,以保證較好的品質,而不是為守紀律的 員工或經公評的績效提供理由。無法適當地保 護資料,最終可能由主導參與者與同仁審查的 效率妥協,而使得他們的評估不夠公平。 13. 分析同仁審查的資料 分析同仁審查資料的例子如下: • 實際的準備時間或比例與預期的時間或比 例的比較 • 實際的缺失數量與預期的缺失數量的比較 • 偵測缺失的型態 • 缺失的原因 • 缺失解決方案的衝擊 SP 3.3 服務系統發展 驗證選定的服務系統組件 驗證選定的服務系統組件對照它們特定的需求。 驗證的方法、程序、準則與環境是用來驗證選定的 581 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 服務系統及其相伴的維護、訓練與支援流程。驗證 活動應在整個服務系統生命週期中執行。 典型的工作產品 1. 驗證的結果與紀錄 2. 驗證報告 3. 分析報告(例如,績效統計、不符合原因分析、 實際服務系統與模式、趨勢之間的行為比較) 4. 故障報告 5. 為驗證方法、準則與環境的變更要求 細部執行方法 1. 執行選定的服務系統組件與工作產品的驗證對 照它們需求。 2. 記錄驗證活動的結果。 3. 界定由服務系統組件與工作產品的驗證結果產 生的行動項目。 4. 記錄準確執行的驗證方法,以及在其執行時所 發現的與已有的方法與流程中產生的誤差。 5. 分析與紀錄所有驗證活動的結果。 SP 3.4 確認服務系統 確認服務系統以確保它適合使用在預期交付環境並 符合關鍵人員的期望。 確認的方法、程序與準則用來確認選定的服務、服 務系統組件及其相伴隨的維護、訓練及支援流程使 用在合適的確認環境中。確認活動應在整個服務系 統生命週期中執行。最終使用者及前線的服務交付 582 服務系統發展 關於適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 人員參與確認活動是特別重要的。因為他們對成功 的服務交付的觀點可能與服務系統發展者非常不 同。 確認必須在一個與交付環境夠類似的環境中進行, 以確保確認工作實際地發生。交付環境是一套根據 服務協議實際交付服務的情況與條件。有時確認可 能有效地執行在模擬環境中,但在其他內容,它可 能只執行在部份交付環境中。在那些最近的案例 中,需要注意的是確保確認活動不會干擾進行中的 服務活動,而造成已同意的服務交付有失敗的風 險。 參考詞彙中「交付環境」的定義。 典型的工作產品 1. 確認的報告與結果 2. 確認的交叉參考矩陣圖 3. 確認的缺失報告及其他議題 4. 確認的方法、準則與環境的變更需求 5. 服務交付確認的使用者驗收(也就是簽認) 6. 焦點群組的報告 細部執行方法 1. 在選定的服務系統組件中執行功能性與非功能性 的確認,確保它們適合在預計的交付環境中使 用。 確認的方法、程序、準則與環境用來確認選定 的服務系統組件及其伴隨的維護、訓練與支援 服務。 服務系統發展 583 適用於服務的能力成熟度整合模式 1.2 版 服務系統發展補充 2. 分析確認活動的結果 分析由確認測試、檢查、展示或評估產生的資 料對照已定義的確認準則。分析報告指出是否 符合需要。若有缺失,這些報告記錄成功或失 敗的程度,並將可能的失敗原因分類。收集的 測試、檢查或審查結果會與已建立的準則做比 較,以決定是否要進行或解決需求或設計的議 題。 584 服務系統發展 服務系統移轉 成熟度第 3 級的服務建立與交付流程領域 關於適用於服務的能力成熟度整合模式 1.2 版 目的 服務系統移轉(SST)的目的是推展新的或明顯變更 的服務系統組件,同時管理服務系統組件對進行中的 服務交付的影響。 簡介 服務系統移轉流程領域說明規劃、溝通、管理、推展 與確認服務系統組件有效地轉換到交付環境的所有觀 點。這個流程領域的範圍包括新的組件與明顯變更的 現行組件。 服務系統移轉 「明顯」定義為一個變更,它說明了一個不被接受的 風險,就是服務系統不會符合目標。雖然這些執行方 法集中在服務系統組件的轉換,但整個服務系統的轉 換(也就是說,一個相互依賴的與整合的組件集合) 也能使用這些執行方法來管理。 在這個流程領域,「轉換」一詞涵括廣泛的流程,包 括準備、執行及當維護一個服務交付時,確認一個服 務系統組件推展到完全運作的狀態。「推展」特別是 指移動服務系統組件到交付環境的活動。在某些領 域,推展也稱為「展開(roll-out)」。 推展通常落在三個類別之一: • 新的裝置 • 替代 585 適用於服務的能力成熟度整合模式 1.2 版 • 淘汰 轉換規畫確保相關的關鍵人員被適當地通知未來的變 更。準備轉換也包含當受限於現行的服務協議及持續 進行的服務交付活動時,對未來服務系統在現行的交 付環境中相容性的評估。對服務系統的衝擊將會被取 代或藉由考慮中的新系統逐步淘汰。對服務系統中, 新的系統分享的介面與資源所造成的衝擊也會被考 慮,同樣地,對服務持續的衝擊也會被考慮。 服務系統移轉的重要觀點包括下列: • 服務系統組件的建構管理 • 內部與外部介面的管理 • 服務系統組件推展到交付環境 • 新的或修改過的服務系統組件的關鍵人員接 受度 • 轉換衝擊的管理 服務系統的緊急變更可依照建立好的政策,由指定的 受權同意後進行。 一般、期望的服務系統移轉流程可能被提醒要配合緊 急狀況的獨特需耍,但一旦情形恢復正常後所有相關 的流程最終應被完成。 這個方式允許任何不預期的衝擊所伴隨的緊急變更, 被界定及解決。 相關的流程領域 有關界定、管理和解決事故,請參考事故解決方案與 預防流程領域,以獲得更多的資訊。 有關建立與維護計畫以確保在發生明顯中斷正常運作 之後持續服務,請參考服務持續性流程領域,以獲得 更多的資訊。 586 服務系統移轉 關於適用於服務的能力成熟度整合模式 1.2 版 有關運作服務系統,請參考服務交付流程領域,以獲 得更多的資訊。 服務系統發展補充 有關分析、設計、發展、整合、驗證與確認服務系 統,包括服務系統組件,以滿足現行或預期的服務協 議,請參考服務系統發展流程領域,以獲得更多的資 訊。 有關界定缺失與問題的原因及採取行動避免未來再發 生,請參考原因分析與解決方案流程領域,以獲得更 多的資訊。 有關追踪與管制變更,請參考建構管理流程領域,以 獲得更多有關追踪與管制變更的資訊。 特定目標與執行方法摘要 SG 1 準備服務系統移轉 SP 1.1 分析服務系統移轉需要 SP 1.2 發展服務系統移轉計畫 SP 1.3 為變更準備關鍵人員 SG 2 推展服務系統 SP 2.1 推展服務系統組件 SP 2.2 評量與管制轉換的衝擊 服務系統移轉 587 適用於服務的能力成熟度整合模式 1.2 版 依目標的特定執行方法 SG 1 準備服務系統移轉 執行準備服務系統移轉。 詳細的規劃可使服務系統組件順利轉換到交付環境。 相容性分析對準備工作是很重要的,也在這個目標內 說明。此外,伴隨注意事項與訓練策略的主動、縝密 思考的轉換計畫可以清楚說明轉換,而獲得關鍵人員 接受。 作為服務系統移轉準備的部份,為服務系統審查運作 概念和腳本及視需要客製化,以協助確保規劃夠縝 密。也要審查服務系統驗收準則,以確保服務系統符 合那些準則。 這個執行方法說明這個目標應該在新的或修改的服務 系統組件仍在開發時即開始。藉著這麼做,組件發展 階段應考慮轉換的需要和限制。 SP 1.1 分析服務系統移轉需要 分析現行的和未來的服務系統的功能和相容性,以減 少對服務交付的衝擊。 這個執行方法的目的是界定與減輕伴隨轉換產生的議 題。界定與減輕的完成應藉由分析現行服務系統受轉 換後的服務系統所預期的變更的影響。 新的或修改的服務系統組件的轉換影響服務交付環 境。有些影響可能在服務系統發展時即已預期。 同樣地,如果沒考慮其加入的限制,進行中的服務交 付活動、專屬的服務請求及環境的氣氛可能導致推展 失敗。實際推展新的或修改的服務交付能量,由於這 些限制可能需要分階段進行。服務系統設計可能需要 調整以使轉換可行。接下來,這個執行方法應與服務 588 服務系統移轉 關於適用於服務的能力成熟度整合模式 1.2 版 系統發展執行方法平行進行,並且應持續整個轉換到 正式運作的狀態。 有關準備服務系統運作,請參考服務交付流程領域, 以獲得更多的資訊。 服務系統發展補充 有關發展服務系統,包括確保介面相容性,請參考服 務系統發展流程領域,以獲得更多的資訊。 典型的工作產品 1. 現行及轉換後的服務系統的相容性分析 2. 伴隨轉換將解決的議題與減輕的風險 細部執行方法 1. 若先前未建立基準,建立現行服務系統的基準。 有關建立基準,請參考建構管理流程領域,以獲得 更多的資訊。 2. 當它在現行交付環境運作時,分析現行服務系統。 有一些案例,文件和運作概念可能存在現行服務系 統。這些文件和運作概念可以用來更瞭解現行的運 作。如果現行服務系統未加以文件化或文件不存 在,則儘量從關鍵人員處找出有關現行運作的輸入 資料。 3. 分析建議轉換的服務系統組件(例如,轉換後服務 系統或未來服務系統),以瞭解潛在的相容性、功 能性或介面議題。 服務系統移轉 589 適用於服務的能力成熟度整合模式 1.2 版 這個分析應為建議的服務系統組件使用發展文 件。這個文件可能包含操作概念、腳本、設計文 件及工作流程圖。 若需要,定義程序以在實際推展前確保服務系統 的相容性。這些程序可以再使用服務系統發展時 導入的驗證與確認方法,但它們應該考慮一旦服 務系統移轉開始,額外的實際的限制是存在的。 視服務系統的複雜程度及伴隨著轉換的風險而 定, 這些程序的範圍可能從一個簡單的分析、潛 在相容性議題的解決方案到正式的測試和評估的 體系。 4. 界定與減輕潛在議題。 有關減輕風險,請參考風險管理流程領域,以獲 得更多的資訊。 SP 1.2 發展服務系統移轉計畫 建立與維護特定的服務系統移轉計畫。 對每一個特定的服務系統移轉,建立一個計畫包含所 有的活動從驗收服務系統組件到使用者及交付環境衝 擊的解決方案。一個轉換計畫應該界定所有特定轉換 所需的活動和資源。 若適當,下列事項應包含在轉換計畫中: • 界定為轉換準備好的服務系統組件 • 推展型態(例如,新增、替代、陶汰) • 採購方式 • 在交付環境中裝置與整合服務系統組件 • 推展階段需滿足在服務系統組件間的操作相 依性 • 推展驗收準則 590 服務系統移轉 服務系統移轉 • 資源限制與禁止 關於適用於服務的能力成熟度整合模式 1.2 版 • 開始準備消耗品 • 將程序回復到「未進行」轉換和重新儲存交 付環境到它先前穩定的運作狀態。 • 服務交付和支援人力的訓練 • 就轉換狀態和服務變更對關鍵人員溝通 轉換計畫的深度應該適用於轉換型態和轉換中組件的 重要性。例如,新的業務組件的轉換可能需要細部計 畫和時程、風險評量、推展取消的程序及由關鍵人員 正式審查計畫資料。較不顯著的轉換,例如,一項過 時服務的淘汰,可能較不需要嚴格的規劃。 如果類似的轉換在之前執行,其推展後的審查結果應 在轉換規劃時加以考量。這個資訊可以加速規劃流程 並協助界定可能需要監督的議題。 有關發展專案計畫,請參考專案規劃流程領域,以獲 得更多的資訊。 典型的工作產品 1. 服務系統移轉的計畫 細部執行方法 1. 為每一個特定的服務系統移轉定義推展的方式。 當定義一個方式時考量推展的型態(例如,新 增、裝置、替換、淘汰),考慮轉換可能包括一 些推展型態的組合。考量相關關鍵人員的優先順 序和限制。 當推展不成功和服務系統必須重新回復到先前狀 態時,也定義一個回復或取消的策略。包括建立 成功的推展與退回變更時的準則。 591 適用於服務的能力成熟度整合模式 1.2 版 如果服務系統將淘汰,解決的主題如使用者通 知、錯誤處理、檔案方式、毀壞及回收。 2. 決定服務系統移轉到新的或變更的操作狀態所需 的成本、資源及時程。 進行中的時程轉換活動平衡工作與可用資源和客 戶及最終使用者的需要,包括有時間準備及執行 轉換的需要。若適當,對類似的轉換使用實際的 資料來預測成本、資源和時程。 3. 為轉換活動界定關鍵人員。 當界定轉換的關鍵人員及定義其角色和責任,確 認考量了委外的關鍵人員。 4. 發展服務系統移轉計畫。 基於推展的方式,預測轉換,並為轉換建立一份 計畫文件。 5. 獲得關鍵人員對計畫的承諾。 確保服務系統移轉計畫由關鍵人員審查過以獲得 同意。並對審查的建議予以回應。 6. 為轉換計畫建立基準。 7. 若新的或明顯變更的重要功能是轉換的一部份, 確保更新服務持續計畫以涵括新的功能。 有關建立服務持續計畫,請參考服務持續性流程 領域,以獲得更多的資訊。 有關與關鍵人員的整合計畫與協調與合作,請參 考整合專案管理流程領域,以獲得更多的資訊。 592 服務系統移轉 SP1.3 為變更準備關鍵人員 關於適用於服務的能力成熟度整合模式 1.2 版 為服務及服務系統的變更準備關鍵人員。 這個執行方法是確保服務系統移轉不會因為所有說明 新的或修改的服務系統組件產生的變更所準備的關鍵 人員失敗而有損傷。相關的關鍵人員應該包括客戶、 最終使用者、供應商員工、管理高層、外部供應商及 其他任何需要知道預計的變更的人。 典型的工作產品 1. 轉換通知策略 2. 轉換訓練策略 細部執行方法 1. 建立及維護一個轉換通知策略。 2. 執行通知策略以通知關鍵人員關於服務排定的變更 及轉換期間的服務可用度。 若適當,確保通知策略說明了如何溝通返回或取 消。 3.建立與維護轉換訓練策略。 轉換訓練策略可以包括範圍廣泛口頭說明和訓練 活動,若適當,包括客戶、最終使用者、服務交 付與支援人員、經理、資深領導者。轉換訓練策 略也可以包括確保訓練有效執行活動,例如測 試、試行或調查。 服務系統移轉 593 適用於服務的能力成熟度整合模式 1.2 版 口頭說明和訓練應包含的資訊例子如下: • 新的或修改的服務,及如何請求它們 • 要求客戶和最終使用者回饋的程序與工具 • 為維修、調整及最終使用者支援的程序與工具 • 服務交付所使用的擇定工具 • 服務系統的設計 • 預計運作的開始日 • 服務系統時程排定、監督及資源管理的程序與 工具 • 轉換期間處理發生服務事故的程序 SG 2 594 4. 實施訓練策略。 有關建立組織訓練戰略計畫,請參考組織訓練流 程領域,以獲得更多的資訊。 推展服務系統 服務系統推展到交付環境。 這目標著重在獲得服務系統組件(適當時自建構管制 授權)及裝置及整合它們到交付環境。這個流程根據 服務系統移轉戰略計畫執行。 推展可能對服務系統運作造成計畫中或非計畫中的影 響。界定、評量及管制這些影響是達成成功的推展的 重要部份。 SP 2.1 推展服務系統組件 基於轉換規劃,系統化地推展服務系統組件到交付環 境中。 服務系統移轉 服務系統移轉 關於適用於服務的能力成熟度整合模式 1.2 版 為轉換做的準備,包括服務系統移轉的戰略計畫,使 用在引導推展。 一般工作產品 1. 裝置紀錄 2. 推展評量成果 細部執行方法 1. 確認被推展的服務系統組件適當的納入建構管制 中。 有關建立基準,請參考建構管理流程領域,以獲 得更多的資訊。 2. 將服務系統裝置到交付環境。 這個細部執行方法包含包裝、分送、整合及裝置 服務系統組件到交付環境。裝置與整合的細節應 該涵括在服務系統移轉的戰略計畫中。 3. 確認交付環境中的服務系統組件。 確保推展的組件如預期的運作。運作的腳本及程 序能被用來評估新的或修改的服務系統。推展驗 收準則,定義為轉換的戰略計畫中的一部份,可 能需要修改為評估的一部份。 有關準備服務系統運作,請參考服務交付流程領 域,以獲得更多的資訊。 服務系統發展補充 有關驗證與確認資訊系統,請參考服務系統發展 流程領域,以獲得更多的資訊。 4. 在服務系統組件淘汰的案例中,將服務系統組件適 當地歸檔,並自交付環境中移除。 確保足夠地處理汰換的服務系統組件的介面。 595 適用於服務的能力成熟度整合模式 1.2 版 SP 2.2 評量與管制轉換的衝擊 評量轉換對關鍵人員與服務交付的衝擊,並採取適當 的矯正行動。 轉換活動延伸了在交付環境中新的服務系統組件的裝 置。服務提供者必須確認服務運作不會反過來被最近 的變更影響。 通常評量時期可以延伸到數個新功能的重複執行,以 協助確保非預期的影響不會發生。例如,在醫療領 域,一個小兒科診科可能執行特定的服務以支援父母 特別的需要。服務可能包含一個促進父母群組、集中 式的治療課程、及教育指引。評量新的服務系統變更 的影響,可能需要收集不同年齡與不同症狀的孩童的 家庭的意見。它會需要一點時間來收集資料,並確保 新的服務對關鍵人員的影響是正面的。 此外,這執行方法確保推展不會降低服務系統或服務 交付的其他觀點。非預期的影響會及時的、並詳細的 描述在轉換的戰略計畫中。可以依照系統的不利衝擊 的需要而實施取消計畫。 有關界定、管制及解決事故到結案,請參考事故解決 方案與預防流程領域,以獲得更多的資訊。 典型的工作產品 1. 推展後審查 2. 推展的評量成果 細部執行方法 1. 使用資料收集方法以自關鍵人員獲得有關推展的 輸入資料。 596 服務系統移轉 方法的例子包含如下: • 調查 • 意見箱 • 網路版的輸入資料格式 關於適用於服務的能力成熟度整合模式 1.2 版 2. 關於推展衝擊的主動溝通資料。 由服務系統移轉戰略計畫所決定的溝通應被處 理,並且應該,最少,包括與關鍵人員確定轉換 已成功完成。 可以使用多種的溝通載具以確保相關的關鍵人員 得知推展的議題: • 電子郵件通知 • 嵌入式系統通知 • 問答集文件 • 在交付環境中的顯著告示牌 • 會議 服務系統移轉 3. 對於顯著的衝擊,參考戰略計畫的細節中有關於 如何及何時應執行推展的退出或回復。 4. 持續評量與管制衝擊直到推展議題解決。 潛在或實際干擾服務交付的衝擊是服務事故,應 該經由專案事故管理系統處理。 5. 執行推展後審查。 這個審查自推展中界定、收集與記錄學習心得。 這個資訊對現今的服務系統運作及未來的轉換都 597 適用於服務的能力成熟度整合模式 1.2 版 是有用的。相關的關鍵人員應該包括解決下列的 問題: • 新的功能有效率地運作嗎? • 服務系統的其他層面已經降級了嗎? • 關鍵人員已經被負面地影響嗎? • 服務系統新的功能是否已藉由充分的使用而加 以評估了嗎? 598 服務系統移轉 策略服務管理 成熟度第 3 級的服務建立與交付流程領域 關於適用於服務的能力成熟度整合模式 1.2 版 目的 簡介 策略服務管理(STSM)的目的是建立與維護標準服務以 與策略需要及計畫一致。 策略服務管理流程領域包括下列活動: • 對適用不同客戶與協議的服務,分析能力與需要 • 建立與維護標準服務、服務等級及反應這些能力與 需要的說明 策略服務管理流程改善服務提供者組織所提供的一組 服務與策略經營目標之間的連結。如果是小型組織或 焦點目標較小,標準服務可以包含一個單一服務或一 個小的服務群組。較大的組織可能有較複雜的標準服 務套組。 客戶與競爭者資料、市場趨勢與機會及組織特性(例 如組織用來建立標準服務的能力與優勢領域資料)的 分析。標準服務是跨組織的一致服務績效的促成者。 這個流程領域的目標不是管理個別的服務,而是獲得 需要達成有效策略決定的資訊。這個決定是有關一組 由組織維護的標準服務。 標準服務提供一個為達成符合服務提供者組織之經營 目標的最大能力的基礎。 策略服務管理 599 適用於服務的能力成熟度整合模式 1.2 版 標準服務可能也改善服務品質、經營記錄及客戶與最 終使用者對發展與交付服務時減少成本、錯誤及時間 的滿意程度。標準服務等級是標準服務的關鍵組件。 服務等級使期望與責任在服務組織與客戶間清楚、特 定且可度量。 在這個流程領域,當客戶需要被提到時,最終使用者 需要也隱含其中。客戶與最終使用者的需要可能不 同。兩者對於收集與分析資料以發展標準服務和瞭解 策略需要及計畫而言,都很重要。 標準服務一般都在用來說明客戶需要資訊的服務型錄 中描述。此外,也應維護指導服務提供者組織的人員 需要的標準服務說明。 對現今服務滿意度的注意與使用將使得組織調整或修 正一些服務,並會導致對未來服務的規劃。組織也可 以界定新的服務系統的需求或修改現行系統。這些系 統可以支援單一或多個客戶。 這個流程領域的特定執行方法補充在組織流程定義、 組織流程專注及組織流程績效。在組織流程定義 (OPD)、組織流程專注(OPF)及組織流程績效(OPP) 中,組織定義、改善及量化瞭解其標準流程。相對 的,策略服務管理(STSM)更廣泛的專注在服務,而不 是只在可能進行的服務系統組件。 相關流程領域 有關監督事故狀態,請參考事故解決方案與預防流程 領域,以獲得更多的資訊。 有關交付服務,請參考服務交付流程領域,以獲得更 多的資訊。 600 策略服務管理 服務系統發展補充資料 關於適用於服務的能力成熟度整合模式 1.2 版 有關發展與分析關鍵人員需求,請參考服務系統發展 流程領域,以獲得更多的資訊。 有關建立標準流程,請參考組織流程定義流程領域, 以獲得更多的資訊。 有關監督專案對照計畫,請參考專案監控流程領域, 以獲得更多的資訊。 有關在需求的意義與需求提供者建立共識,請參考需 求管理流程領域,以獲得更多的資訊。 特定目標與執行方法摘要 SG1 為標準服務建立策略需要與計畫 • SP 1.1 收集與分析相關資料 • SP 1.2 建立標準服務計畫 SG 2 建立標準服務 • SP 2.1 建立標準服務與服務等級的特性 • SP 2.2 建立標準服務說明 策略服務管理 601 適用於服務的能力成熟度整合模式 1.2 版 依照目標的特定執行方法 SG1 為標準服務建立策略需要與計畫 建立與維護標準服務的策略需耍與計畫。 「策略需要」是組織中的條件或目標,通常由環境中 的因素所主導。一個組織可能需要增加收入、利潤或 市場佔有率。客戶可能需要不同的或新的一組服務, 或期望組織基於競爭者所提供的或基於他們自己本身 的目標變更而改變提供的服務。組織考量需要的範 圍,按照它的能力,決定要追求何種目標,以及反應 他們的需要與目標在標準服務計畫中。 在很多組織,策略規劃資訊可能是專有的、敏感的、 不可洩漏的或有其他的控制。任何參加標準服務發展 計畫的人應該小心配合控制,以保護敏感的策略資 訊。 SP 1.1 收集與分析相關資料 收集與分析有關策略需耍要與組織能力的資料。 組織收集與分析可以協助規劃組織建立與維護標準服 務的資料。合適的資料可能對不同的服務、市場區隔 與組織特性,例如規模大小,而有不同。這資料將對 組織的能力與其客戶與最終使用者市場需求,提供重 要資訊。 602 策略服務管理 關於適用於服務的能力成熟度整合模式 1.2 版 收集與分析相關資料的來源與技巧舉例如下: • 經營計畫 • 市場研究 • 調查 • 經營情報 • 自服務審查與客戶管理獲得的資料 • 服務使用的趨勢與型態 • 客戶抱怨與讚美 • 服務事故與請求型態 • 服務等級的損壞 • 競爭者資料 • 同業調查 • 計畫 • 策略規劃技術例如優勢、弱點、機會與威脅 (SWOT) • 核心競爭力分析 • 劇本規劃 典型的工作產品 1. 組織能力的分析資料 2. 策略需要的分析資料 3. 組織能力的說明 4. 策略需要的說明 策略服務管理 603 適用於服務的能力成熟度整合模式 1.2 版 SP 1.2 細部執行方法 1. 收集與分析組織能力的資料。 2. 收集與分析組織策略需耍的資料。 3. 描述組織的能力與策略需要。 4. 與關鍵人員溝通相關的說明。 建立標準服務計畫 建立與維護標準服務計畫。 標準服務規畫轉換組織的能力與策略需要成為標準服 務相關決策的資訊。標準服務的計畫反應用來平衡組 織能力所需的行動;策略需要包括客戶與最終使用者 的需要;及競爭市場的條件。 典型的工作產品 1. 策略經營目標的說明 2. 預期服務的說明 3. 服務系統需要的分析 4. 擇定服務的決策或同意文件 5. 標準服務計畫 細部執行方法 1. 確認策略經營目標。 服務組織的策略經營目標可能是明確的且可提供 的。若不是,規劃者執行此活動,記錄他們不明 確目標的瞭解為他們規畫的一部份。這份瞭解應 被資深管理審查與核可。 2. 基於策略經營運目標、組織能力及策略需要,建議 標準服務的需求。 604 策略服務管理 SG 2 3. 界定標準服務所需的行動。 關於適用於服務的能力成熟度整合模式 1.2 版 所需的行動可能包括發展一個新的標準服務、修改 或改善現有的標準服務、或淘汰標準服務。一個在 管理服務已知的失敗模式為疏忽管理廢棄的服務。 不再符合客戶需要或組織能力的標準服務應被淘汰 或修改成適用的樣子。組織應該適當的建立優先順 序及決定行動的階段。 有關選擇改善,請參考組織創新及推展流程領域, 以獲得更多的資訊。 有關管理矯正行動到結案,請參考專案監控流程領 域,以獲得更多的資訊。 新的或變更的標準服務可能需要新的或變更的服務 系統。這些服務系統可以支援單一或多個客戶以及 單一或多個服務系統。 4. 關鍵人員就將建立與維護的標準服務加以審查並 取得同意。 建立標準服務 建立與維護一組標準服務 SP 2.1 建立標準服務與服務等級的特性 建立與維護一套組織的標準服務與服務等級。 可能需要不同的標準服務與服務等級解決不同的客 戶、組織單位、市場或應用領域的需要。此外,建立 標準服務,可以將服務組成服務線,以便組織可能因 為規模大小或複雜程度不同而有不同的服務委託。組 織會發展標準流程以交付標準服務。 有關建立標準流程,請參考組織流程定義流程領域, 以獲得更多的資訊。 策略服務管理 605 適用於服務的能力成熟度整合模式 1.2 版 典型的工作產品 1. 標準服務的重要屬性 2. 組織的一組標準服務等級 3. 服務等級協議樣本 4. 調適準則 5. 標準服務共同與可變的部份 6. 服務組成服務線 細部執行方法 1. 選擇標準服務。 擇定標準服務必須遵循組織政策、標準與模式。 2. 特別說明每一個服務的重要屬性。 重要屬性的例子如下: • 特性與優點 • 可提供的服務等級與類別 • 成本 • 現在使用者 • 預期使用者 • 服務組件 • 服務交付系統 • 相關的服務 3. 決定標準服務共同與可變的部份。 606 策略服務管理 關於適用於服務的能力成熟度整合模式 1.2 版 標準服務的可變部份可能被指派類別與參數。標 準服務等級可以代表標準服務中可變的程度。 可允許的變異的例子: • 價格 • 子服務提供者 • 使用客戶組件的準則 4. 視需要將服務組成服務線。 將服務組成服務線可以包括確保將服務適當的整 合。 5. 定義服務等級。 已定義的服務等級使提供的服務等級特定且可度 量。服務等級可以協助平衡服務的成本與需求, 以及使服務提供者與使用者之間的角色與責任清 楚。 決定服務等級要包括下列服務需求: • 失去的服務的最大可驗收連續時間 • 降級服務的最大可驗收連續時間 • 在服務回復期間可驗收的降級服務等級 • 多餘的需求 標準服務等級可以反應在標準服務等級協議或其 範本。 策略服務管理 607 適用於服務的能力成熟度整合模式 1.2 版 服務等級資訊包括如下: • 提供者與使用者的責任 • 服務的可供應度 • 經同意的服務時數與例外情況 • 預期的服務量 • 對服務事故及請求的回應時間 • 績效或品質目標 • 監督的主要度量值 • 報告與逐步擴大的程序 • 未達成服務等級的結果 • 可用的變異(例如「黃金」服務) 6. 適當地建立調適準則。 組織使用客戶需要可變性的知識來發展調適的選 擇。當維護跨組織的一致性時,此選擇限制了風 險並改善客戶滿意度及上市的時間。 調適準則及指引描述如下: • 組織的一套標準服務如何用來引導發展個別服 務 • 強制的需求就是必須滿足廣義的已定義服務 • 選項就是可以運作而且準則為在選項中擇定 • 在執行與記錄調適時,必須遵守的程序 608 策略服務管理 關於適用於服務的能力成熟度整合模式 1.2 版 調適準則與程序的例子包含如下: • 從已由組織同意的標準服務中,選擇標準服務 的準則 • 從組織的一套標準服務中,選擇服務組件的準 則 • 適應特定的需耍,調適選擇服務與服務組件的 程序 調適行動的例子如下: • 修改服務等級 • 組合不同服務的組件 • 修改服務組件 • 取代服務組件 • 重新排序服務組件 調適的原因例子如下: • 為新客戶需要或工作環境採用服務 • 為特定的使用或類似使用的類別客製化服務 SP 2.2 建立標準服務的說明 建立與維護組織已調適的標準服務的說明。 建立標準服務的特性不充分。這些特性也必須包裝成 一個特定的說明。除了服務提供者所使用的一組說 明,一般需要有一個給客戶使用的分開的版本。使用 策略服務管理 609 適用於服務的能力成熟度整合模式 1.2 版 610 標準服務的一個共通失敗的情形是,他們被定義或描 述符合供應商組織中的某些人員,但不是以給所有標 準服務的預期使用者的有效及適當的方式說明。為了 成功的使用,標準服務必須適當地描述本說明預期使 用者的整個範圍。 典型的工作產品 1. 服務的說明 2. 服務型錄或手冊 3. 附件資料例如交付員工的指示、銷售人員的指示、 建議及價格資訊及合約資訊。 細部執行方法 1. 為所有相關的使用者發展標準服務的說明。 有關標準服務的額外資料若不存在的話,也可發 展。這些資料可包含發展特定服務、服務交付員 工或銷售或其他業務員工的資訊。 2. 與相關關鍵人員就說明內容執行同仁審查。 客戶與最終使用者的代表可以包含在這些同仁審 查中,以確保說明內容符合他們的資訊需求。 3. 視需要修改說明。 4. 所有預期的使用者均可進入儲存說明的位置與媒 體。 為有效率,標準服務說明必須在一致的位置可供 利用與進入,以鼓勵整個範圍的預期使用者使 用。這個位置可能是一個大的、複雜的線上位址 或是一張紙,端視服務與組織的特性。 然而服務的型錄或手冊通常是電子化格式,很多 組織也會有紙本。附件資料要與說明存在一起, 例如對交付員工、銷售人員、建議書作者、合約 策略服務管理 關於適用於服務的能力成熟度整合模式 1.2 版 專員的調適指引與指示。對服務提供者組織而 言,客戶與員工所需要的服務型錄或手冊可能有 所不同。 標準服務儲存位置的例子如下: • 建構管理資料庫 • 網頁 • 文件檔案或資料館 • 流程資產館 策略服務管理 611 適用於服務的能力成熟度整合模式 1.2 版 第三單元:附錄 612 附錄 關於適用於服務的能力成熟度整合模式 1.2 版 附錄 A:參考書目 Ahern 2005 Bernard 2005 Crosby 1979 Curtis 2001 Deming 1986 Dodson 2006 EIA 2002 EIA 2003 EIA 2002 參考書目 Ahern, Dennis M.; Armstrong, Jim; Clouse, Aaron; Ferguson, Jack R.; Hayes, Will; and Nidiffer, Kenneth E. CMMI SCAMPI Distilled: Appraisals for Process Improvement. Boston, MA: Addison-Wesley, 2005. Bernard, Tom; Gallapher, Brian; Bate, Roger; & Wilson, Hal. CMMI Acquisition Module, Version 1.1. (CMU/SEI-2005-TR001, ADA441245). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University®, May 2005. www.sei.cmu.edu/publication/documents/05.reports/05tr011. html Crosby, Philip B. Quality Is Free The Art of Making Quality Certain. New York: McGraw-Hill, 1979. Curtis, Bill; Hefley, William E.; and Miller, Sally A. The People Capability Maturity Model Guidelines for Improving the Workforce. Boston, MA: Addison-Wesley, 2001. Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Press, 1986. Dodson, Kathryn M.; Hofmann, Hubert F.; Ramani, Gowri S.; & Yedlin, Deborah K. Adapting CMMI for Acquisition Organizations: A Preliminary Report (CMU/SEI-2006-SR005, ADA453524). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, June 2006. www.sei.cmu.edu/publications/documents/06.reports/06sr00 5.html. Electronic Industries Alliance. Systems Engineering Capability Model (EIA/IS-731.1). Washington, DC, 2002. Electronic Industries Alliance. EIA Interim Standard: Systems Engineering (EIA/IS-632). Washington, DC, 2003. Government Electronics and Information Technology Alliance. Earned Value Management Systems (ANSI/EIA748). New York, NY, 2002. www.nssn.org/search/DetailResults.aspx?docid=338699. 613 適用於服務的能力成熟度整合模式 1.2 版 Gibson 2006 Humphrey 1989 IEEE 1991 ISO 1995 ISO 2000 ISO 2002a ISO 2002b ISO 2005 Gibson, Diane L.; Goldenson, Dennis R.; & Kost, Keith. Performance Results of CMMI-Based Process Improvement (CMU/SEI-2006-TR-004, ADA454687). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, August 2006. www.sei.cmu.edu/publications/documents/06.reports/06tr00 4.html. Humphrey, Watts S. Managing the Software Process. Boston, MA: Addison-Wesley, 1989. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: IEEE, 1991. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 12207 Information Technology—Software Life Cycle Processes, 1995. www.webstore.ansi.org/RecordDetail.aspx?sku=IEEE+Std+ 12207-2008 International Organization for Standardization. ISO 9001, Quality Management Systems—Requirements, 2000. www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?C SNUMBER=21823&ICS1=3&ICS2=120&ICS3=10 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15288 Systems Engineering—System Life Cycle Processes, 2002. www.jtc1-sc7.org/. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15288 Systems Engineering—System Life Cycle Processes, 2002; www.jtc1-sc7.org/ International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 20000-1 Information Technology—Service Management, Part 1: Specification; ISO/IEC 20000-2 Information Technology— Service Management, Part 2: Code of Practice, 2005. www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detai l.htm?csnumber=41333. 614 參考書目 ISO 2006 IT Governance 2005 Juran 1988 McFeeley 1996 Office of Government Commerce 2007a Office of Government Commerce 2007b Office of Government Commerce 2007c Office of Government Commerce 2007d Office of Government Commerce 2007e SEI 1995 關於適用於服務的能力成熟度整合模式 1.2 版 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 15504 Information Technology—Software Process Assessment Part 1: Concepts and Vocabulary, Part 2: Performing an Assessment, Part 3: Guidance on Performing an Assessment, Part 4: Guidance on Use for Process Improvement and Process Capability Determination, Part 5: An Exemplar Process Assessment Model, 2003-2006. www.iso.org/iso/search.htm?qt=15504&published=true&acti ve_tab=standards/ IT Governance Institute. CobiT 4.0. Rolling Meadows, IL: IT Governance Institute, 2005. www.isaca.org/Content/NavigationMenu/Members_and_Lea ders/COBIT6/Obtain_COBIT/Obtain_COBIT.htm. Juran, Joseph M. Juran on Planning for Quality. New York: Macmillan, 1988. McFeeley, Robert. IDEAL: A User’s Guide for Software Process Improvement (CMU/SEI-96-HB-001, ADA305472). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, February 1996. www.sei.cmu.edu/publications/documents/96.reports/96.hb. 001.html. Office of Government Commerce. ITIL: Continual Service Improvement. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Design. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Operation. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Strategy. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Transition. London, UK: Office of Government Commerce, 2007. Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995. 參考書目 615 適用於服務的能力成熟度整合模式 1.2 版 SEI 2002 SEI 2006a SEI 2006b SEI 2006c SEI 2007 Shewhart 1931 Software Engineering Institute. Software Acquisition Capability Maturity Model (SA-CMM) Version 1.03 (CMU/SEI-2002-TR-010, ADA399794). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002. www.sei.cmu.edu/publications/documents/02.reports/02tr01 0.html. CMMI Product Team. CMMI for Development, Version 1.2 (CMU/SEI-2006-TR-008, ADA455858). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, August 2006. www.sei.cmu.edu/publications/documents/06.reports/06tr00 8.html. SCAMPI Upgrade Team. Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A, Version 1.2: Method Definition Document (CMU/SEI-2006-HB-002). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, August 2006. www.sei.cmu.edu/publications/documents/06.reports/06hb0 02.html. SCAMPI Upgrade Team. Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.2) (CMU/SEI-2006-TR-011, ADA454612). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, August 2006. www.sei.cmu.edu/publications/documents/06.reports/06tr01 1.html. CMMI Guidebook for Acquirers Team. Understanding and Leveraging a Supplier’s CMMI Efforts: A Guidebook for Acquirers (CMU/SEI-2007-TR-004). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2007. www.sei.cmu.edu/publications/documents/07.reports/07tr00 4.html. Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York: Van Nostrand, 1931. 616 參考書目 附錄 B. 縮寫字 關於適用於服務的能力成熟度整合模式 1.2 版 ARC CAM CAR CCB CL CM CMM CMMI CMMI-ACQ CMMI-DEV CMMI-SVC Appraisal Requirements for CMMI CMMI 評鑑需求 Capacity and Availability Management(process area) 容量與可用度管理(流程領域) Causal Analysis and Resolution (process area) 原因分析與解決方案(流程領域) configuration control board 建構管制委員會 capability level 能力度等級 Configuration Management (process area) 建構管理(流程領域) Capability Maturity Model 能力成熟度模式 Capability Maturity Model Integration 能力成熟度整合模式 CMMI for Acquisition 適用於採購的能力成熟度整合模式 CMMI for Development 適用於發展的能力成熟度整合模式 CMMI for Services 適用於服務的能力成熟度整合模式 縮寫字 617 適用於服務的能力成熟度整合模式 1.2 版 CPM CobiT COTS CPM DAR DoD EIA EIA/IS FCA GG GP IBM critical path method 關鍵路徑方法 Control Objectives for Information and related Technology 資訊與相關科技的管制目標 commercial off the shelf 現成品 critical path method 關鍵路徑方法 Decision Analysis and Resolution (process area) 決策分析與解決方案(流程領域) Department of Defense 國防部 Electronic Industries Alliance 電子工業協會 Electronic Industries Alliance/Interim Standard 電子工業協會過渡期標準 Functional configuration audit 功能的建構稽核 generic goal 一般目標 generic practice 一般執行方法 International Business Machines 國際商業機器公司 618 縮寫字 IDEAL IEEE IPD-CMM IPM IRP ISO ISO/IEC IT ITIL ITSCMM MA MDD 縮寫字 關於適用於服務的能力成熟度整合模式 1.2 版 Initiating, Diagnosing, Establishing, Acting, Learning 啟始、診斷、建立、行動、學習 Institute of Electrical and Electronics Engineers 電子電機工程學會 Integrated Product Development Capability Maturity Model 整合的產品發展能力成熟度模式 Integrated Project Management (process area) 整合的專案管理(流程領域) Incident Resolution and Prevention (process area) 事故解決方案與預防(流程領域) International Organization for Standardization 國際標準組織 International Organization for Standardization and International Electrotechnical Commission 國際標準組織與國際電機協會 Information Technology 資訊技術 Information Technology Infrastructure Library 資訊技術架構資料庫 Information Technology Services Capability Maturity Model 資訊技術服務能力成熟度模式 Measurement and Analysis (process area) 度量與分析(流程領域) Method Definition Document 方法定義文件 619 適用於服務的能力成熟度整合模式 1.2 版 ML OID OPD OPF OPP OT PCA P-CMM PA PAL PERT PMC maturity level 成熟度等級 Organizational Innovation and Deployment (process area) 組織創新與推展(流程領域) Organizational Process Definition (process area) 組織流程定義(流程領域) Organizational Process Focus (process area) 組織流程專注(流程領域) Organizational Process Performance (process area) 組織流程績效(流程領域) Organizational Training (process area) 組織訓練(流程領域) Physical configuration audit 實體建構稽核 People Capability Maturity Model 人員能力成熟度模式 process area 流程領域 Process asset library 流程資產資料庫 Program Evaluation and Review Technique 計畫評核與審查技術 Project Monitoring and Control (process area) 專案監控(流程領域) 620 縮寫字 PP PPQA PWS QA QFD QPM REQM RSKM SCON SCAMPI SD SEI 縮寫字 Project Planning (process area) 專案規劃(流程領域) 關於適用於服務的能力成熟度整合模式 1.2 版 Process and Product Quality Assurance (process area) 流程與產品品質保證(流程領域) performance work statement 績效工作說明 quality assurance 品質保證 Quality Function Deployment 品質功能展開 Quantitative Project Management (process area) 量化專案管理(流程領域) Requirements Management (process area) 需求管理(流程領域) Risk Management (process area) 風險管理(流程領域) Service Continuity (process area) 服務持續(流程領域) Standard CMMI Appraisal Method for Process Improvement CMMI 流程改善標準評鑑方法 Service Delivery (process area) 服務交付(流程領域) Software Engineering Institute 軟體工程學院 621 適用於服務的能力成熟度整合模式 1.2 版 SG SLA SOO SOW SP SSD SST STSM SW-CMM WBS specific goal 特定目標 service level agreement 服務層級協議 statement of objectives 目標描述 statement of work 工作描述 specific practice 特定執行方法 Service System Development (process area) 服務系統發展(流程領域) Service System Transition (process area) 服務系統移轉(流程領域) Strategic Service Management (process area) 策略服務管理(流程領域) Capability Maturity Model for Software or Software Capability Maturity Model 軟體能力成熟度模式 work breakdown structure 分工結構圖 622 縮寫字 關於適用於服務的能力成熟度整合模式 1.2 版 附錄 C: 適用於服務的能力與成熟度整合模式專案參與 人員 許多有才能的人士參與 CMMI-SVC 的產品團隊。下 列團隊是在 CMMI-SVC 發展期間參加一個或更多團 隊的人員。依照人員姓名排列的組織是他們在那段時 間代表加入團隊會員。 有 5 個主要團隊參與這個模式的發展: • CMMI-SVC 1.2 版模式團隊 • CMMI-SVC 1.2 版訓練團隊 • CMMI-SVC 1.2 版品質團隊 • 適用於服務的能力與成熟度整合模式顧問諮詢委員 會 • CMMI 推動組 CMMI-SVC 1.2 版模式團隊 CMMI-SVC 1.2 版模式團隊從審查者和使用者收集意 見建立 CMMI-SVC 1.2 版。 • Drew Allison, Systems and Software Consortium • Rhonda Brown, Software Engineering Institute • Brandon Buteau, Northrop Grumman • Eileen Clark, SRA International, Inc.; Tidewaters Consulting, LLC • Eileen Forrester, Software Engineering Institute7 • Craig Hollenbach, Northrop Grumman8 • Mike Konrad, Software Engineering Institute • Frank Niessink, DNV • M. Lynn Penn, Lockheed Martin • Roy Porter, Northrop Grumman • Rich Raphael, MITRE Corporation 7 SEI Team Lead 8 Industry Team Lead 適用於服務的能力與成熟度整合模式專案參與人員 623 適用於服務的能力成熟度整合模式 1.2 版 • Pamela Schoppert, SAIC • Sandy Shrum, Software Engineering Institute • Jerry Simpson, SAIC • Jeff Zeidler, Boeing 額外的團隊成員和貢獻者: • Roger Bate, Software Engineering Institute • Margaret Glover, Software Engineering Institute • Joanne O’Leary, Software Engineering Institute • Mary Lynn Russo, Software Engineering Institute • Steve Stern, Lockheed Martin • Barbara Tyson, Software Engineering Institute CMMI-SVC 1.2 版 訓練團隊 CMMI-SVC 1.2 版訓練團隊是一組包括發展者和許多 審查者的團隊。發展團隊使用由 CMMI-SVC 1.2 版模 式團隊建立的基準線及現行的 CMMI 簡介來發展 CMMI-SVC 1.2 版的訓練。 • Eileen Clark, Tidewaters Consulting, LLC • Mary Beth Chrissis, Software Engineering Institute • Bob McFeeley, Software Engineering Institute • Sandy Shrum, Software Engineering Institute • Agapi Svolou, Software Engineering Institute • Barbara Tyson, Software Engineering Institute9 9 Team Lead 624 適用於服務的能力與成熟度整合模式專案參與人員 關於適用於服務的能力成熟度整合模式 1.2 版 CMMI-SVC 1.2 版 品質團隊 CMMI-SVC 1.2 版品質團隊使用過去幾年來發展的 CMMI 模式品質保證的流程。這個團隊為 CMMI-SVC 1.2 版發展品質保證流程,以準備及公布由 CMMISVC 1.2 版訓練團隊發展的訓練教材。 • Rhonda Brown, Software Engineering Institute10 • Mary Lou Russo, Software Engineering Institute • Mary Lynn Russo, Software Engineering Institute • Sandy Shrum, Software Engineering Institute11 CMMI 服務顧問諮詢委員會 CMMI 服務顧問諮詢委員會負責提供方向給進行發展工 作的 CMMI-SVC 1.2 版模式團隊。 • Christian Carmody, University of Pittsburgh Medical Center • Sandra Cepeda, RDECOM AMRDEC Software Engineering Directorate/Cepeda Systems and Software Analysis, Inc. • Annie Combelles, DNV IT Global Services • Jeffrey L. Dutton, Jacobs Technology Inc. • Eileen Forrester, Software Engineering Institute • Craig Hollenbach, Northrop Grumman12 • Brad Nelson, Office of the Deputy Undersecretary of Defense for Industrial Policy • Lawrence Osiecki, U.S. Army Armament Software Engineering Center • Mike Phillips, Software Engineering Institute • Tim Salerno, Lockheed Martin IS&GS—Civil • Nidhi Srivastava, Tata Consultancy Services • Beth Sumpter, National Security Agency 10 Team Co-Lead 11 Team Co-Lead 12 主席 適用於服務的能力與成熟度整合模式專案參與人員 625 適用於服務的能力成熟度整合模式 1.2 版 • Dave Swidorsky, Merrill Lynch Global Technology Services CMMI 推動組 CMMI 推動組指導與核准 1.2 版產品團隊的計畫,提 供重大 CMMI 專案議題的諮詢,與確保來自眾多有興 趣團體的參與,及核准最終公布的模式。 推動組成員 • Kristen Baldwin, OUSD (AT&L) SSE/SSA • Clyde Chittister, Software Engineering Institute • Jim Gill, Boeing Integrated Defense Systems • John Kelly, NASA HQ • Kathy Lundeen, Defense Contract Management Agency • Larry McCarthy, Motorola, Inc. • Mike Nicol, U.S. Air Force ASC/EN • Lawrence Osiecki, U.S. Army • Bill Peterson, Software Engineering Institute • Bob Rassa, Raytheon Space & Airborne Systems13 • Kevin Stamey, AFMC/EN • Joan Weszka, Lockheed Martin • Hal Wilson, Northrop Grumman • Brenda Zettervall, U.S. Navy, ASN/RDA CHENG 官方推動組成員 • Lloyd Anderson, Department of Homeland Security • Roger Bate, chief architect, Software Engineering Institute • Mike Phillips, CMMI program manager, Software Engineering Institute • Beth Sumpter, National Security Agency 13 主席 626 適用於服務的能力與成熟度整合模式專案參與人員 推動組支援:採購 關於適用於服務的能力成熟度整合模式 1.2 版 • Brian Gallagher, Software Engineering Institute 推動組支援:建構管制委員會 • Mike Konrad, Software Engineering Institute 適用於服務的能力與成熟度整合模式專案參與人員 627 適用於服務的能力成熟度整合模式 1.2 版 附錄 D:詞彙 CMMI 詞彙定義用於 CMMI 模式的基本術語。詞彙通 常是數個字的術語,包含一個名詞與一個或一個以上 的限制修飾詞。(此規則有部分例外,詞彙中也有一 個字的術語說明)。 為確切表達適合 CMMI 的定義,我們諮詢許多的來源 出處。首先我們參考韋氏線上字典(www.m-w.com)及 來源模式(如 CMMI V1.2, EIA 731, SW-CMM V2. draft C 及 IPD-CMM V0.98)。如有需要我們也參考其它標 準,包括下列: • ISO 9000 [ISO 1987] • ISO/IEC 12207 [ISO 1995] • ISO/IEC 15504 [ISO 2006] • ISO/IEC 15288 [ISO 2002a] • ISO/IEC 15939 [ISO 2007] • ISO 20000-1 [ISO 2005 • IEEE [IEEE 1991] • CobiT v. 4.0 [ IT Governance 2005] • SW-CMM v1.1 • EIA 632 [EIA 1994] • SA-CMM [SEI 2002] • P-CMM [Curtis 2002]] 我們發展詞彙乃是基於「使所有模式的使用者都瞭解 專門術語」之重要性的認知。同時文字與術語在不同 的內文與環境,有不同的意義。CMMI 模式的詞彙用 628 詞彙 驗收準則 驗收測試 達成摘要 採購者 採購 採購策略 足夠的 詞彙 關於適用於服務的能力成熟度整合模式 1.2 版 來記載文字與術語的意義,應是使用最廣泛且應為 CMMI 產品使用者所瞭解的。 產品或產品組件必須符合的準則,以讓使用者、 客戶或其他經授權的實體能接受該產品或產品組 件。(請參見「交付項目」。) 讓使用者、客戶或其他經授權的實體決定是否接 受產品或產品組件,所執行的正式測試。(請參見 「元件測試」。) 連續式表述中,在提升能力程度時,一組流程領 域與其相關的能力度等級,表示組織於提升能力 度等級過程中,每個流程領域的進度。(請參見 「能力度摘要」、「目標摘要」及「目標階段 式」。) 從供應商取得或購買產品或服務的關鍵人員(請參 見「關鍵人員」。) 經由供應商協議取得產品或服務的流程。(請參見 「供應商協議」。) 根據供應的來源、採購的方法、需求規格的類 型、合約或協議的類型及相關的採購風險,以決 定產品與服務採購的特定方法。 經由這些字詞的使用,你可以依組織的經營目標 來詮釋模式的目標及執行方法。當使用任何 CMMI 模式的時候,你必須詮釋執行方法使其適 用於貴組織。而在模式的目標及執行方法中使用 這些字詞,可以用來說明其中的某些活動並不是 一直都要進行。(請參見「適當的」及「視需要 的」。) 629 適用於服務的能力成熟度整合模式 1.2 版 配置的需求 替代的執行方法 強化 評鑑 評鑑調查結果 評鑑參與者 評鑑評等 評鑑參考模式 評鑑範圍 630 將較高階需求的所有或部分績效及功能,賦予較 低階架構元件或設計組件的需求。 可用以替代 CMMI 模式中,一個或多個一般或特 定執行方法的執行方法,該執行方法在達成 CMMI 的一般或者特定目標時,具有相同的效 果。替代的執行方法未必與一般或特定的執行方 法是一對一的替代關係。 強化(amplifications)是助益的模式組件,包含特定 專業領域的相關資訊。例如:想找軟體工程的專 業領域強化,可以在模式中尋找標示為「軟體工 程適用(For Software Engineering)」的標籤。此方 式也適用於找其他專業領域強化的資訊。 在 CMMI 產品系列中,「評鑑(appraisal)」是指一 群訓練有素的專家,以評鑑的參考模式(reference model)為基礎,對一個或多個流程進行檢驗,至少 做到決定其優點及缺點。(請參見「評量」及「能 力評估」。) 評鑑調查結果界定出評鑑範圍內流程改善最重要 的議題、問題或機會。評鑑調查結果是根據證實 的客觀證據推論得到。 在評鑑時,提供資料的組織單位成員。 如同 CMMI 評鑑資料所定義的,由評鑑組對於 (a)CMMI 的目標或流程領域、(b)流程領域的能力 度,或(c)組織單位的成熟度,指定評分。經由執 行評鑑方法定義的評等流程來決定評等。 如同 CMMI 評鑑資料所定義的,評鑑組將已實施 的流程活動與此 CMMI 模式相互關連。 定義評鑑的界限,包含將被調查運作流程的組織 界限與 CMMI 模式界限。 詞彙 評鑑團隊負責人 適當的 關於適用於服務的能力成熟度整合模式 1.2 版 領導評鑑活動之個人,此人符合評鑑方法在經 驗、知識、與技能上所定義的資格準則。 經由這個字詞的使用,你可以依組織的經營目標 來詮釋模式的目標及執行方法。當使用任何 CMMI 模式的時候,你必須詮釋執行方法使其適 用於貴組織。而在模式的目標及執行方法中使用 這些字詞,可以用來說明其中的某些活動並不是 一直都要進行。(請參見「足夠的」及「視需要 的」。) 視需要的 經由這個字詞的使用,你可以依組織的經營目標 來詮釋模式的目標及執行方法。當使用任何 CMMI 模式的時候,你必須詮釋執行方法使其適 用於貴組織。而在模式的目標及執行方法中使用 這些字詞,可以用來說明其中的某些活動並不是 一直都要進行。(請參見「足夠的」及「適當 的」。) 評量 在 CMMI 產品系列中,組織為了本身流程改 善的目的所進行的一種評鑑。「評量」在 CMMI 產品系列中使用的意義與日常使用的意 義相同(例如:風險評量)。(請見「評鑑」及 「能力評估」。) 流程變異的可指 定原因 稽核 在 CMMI 中,以「流程變異的特殊原因」來替 代「流程變異的可指定原因」以確保一致性, 兩者皆有相同的定義。(請參見「流程變異的特 殊原因」。) 在 CMMI 流程改善的工作中,依據特定的準則 (例如:需求),客觀的檢驗一項工作產品或一組 工作產品。 詞彙 631 適用於服務的能力成熟度整合模式 1.2 版 基礎度量 一個實體的明確特性或特徵,以及將其量化的 方法。(請參見「衍生度量」。) 基準 經正式審查及同意的一組規格或工作產品,據 以用作未來發展的基礎,而且僅能由變更管制 程序變更。(請參見「建構基準」及「產品基 準」。) 雙向追溯性 經營目標 能力度等級 能力度摘要 能力成熟度模式 兩個或更多個邏輯實體間可辨識的雙向關聯(如指 向與來自某個實體)。(請參見「需求追溯性」及 「追溯性」。) (請參見「組織經營目標」。) 個別流程領域內流程改善達到的程度,能力度等 級由流程領域內適當的特定及一般執行方法所定 義。(請參見「一般目標」、「一般執行方法」、 「成熟度等級」及「流程領域」。) 在連續式表述中,一組流程領域與其對應的能力 度等級。(請參見「達成摘要」、「目標摘要」及 「目標階段式」。) 能力度摘要可能是一”達成度摘要”,當摘要用來 表示在提升能力度等級過程中,組織於每個流程 領域的進度。或者當它用來表示流程改善的目標 時,可能是目標摘要。 模式包含一個或多個專業領域的有效流程之基本 元件。它也描述漸進的改善途徑,從隨興的不成 熟的流程到具有改善品質及有效性的有紀律的成 熟流程。 632 詞彙 有能力的流程 原因分析 變更管理 CMMI 架構 CMMI 模式 CMMI 模式組件 CMMI 產品系列 市場現有軟體 商用現成軟體 關於適用於服務的能力成熟度整合模式 1.2 版 能滿足其特定的產品品質、服務品質及流程績效 目標的流程。(請參見「穩定流程」、「標準流 程」及「統計化管理流程」。) 分析缺失以找出其原因。 審慎使用各種方法,以達成產品或服務的變更或 建議的變更。(請參見「建構管理」。) 組織 CMMI 組件的基本結構,包括目前 CMMI 模式中的共同元件、模式產出的規則及方法、評 鑑方法(包括相關的產出)及其訓練教材。這個架 構可讓新的專業領域加到 CMMI 中,並使它可與 現有專業領域整合。(請參見「CMMI 模式」及 「CMMI 產品系列」) CMMI 架構可產生可能模式的整個集合,CMMI 模式為其中一個模式。因此依照各組織的需要, 可由 CMMI 架構產生不同的模式,目前有許多 CMMI 模式。(請參見「CMMI 架構」及「CMMI 產品系列」) 任何組成 CMMI 模式的主要結構元件,一些 CMMI 模式的主要元件包括特定執行方法、一般 執行方法、特定目標、一般目標、流程領域、能 力度及成熟度。 以 CMMI 觀念所發展的整套產品,這些產品包括 架構本身、模式、評鑑方法、評鑑資料及各種訓 練。(請參見「CMMI 架構」及「CMMI 模 式」。) 可自商業供應商處購買的項目。 詞彙 633 適用於服務的能力成熟度整合模式 1.2 版 流程變異的共同 原因 操作概念 建構稽核 建構基準 建構管制 建構管制委員會 建構識別 建構項目 因流程各組件間彼此正常與預期的交互作用,而 存在的流程變異。(請參見「流程變異的特殊原 因」。) (請參見「操作概念(operational concept)。」 執行稽核以驗證建構項目或一組建構項目建構基 準符合特定的標準或需求。(請參見「稽核」、 「建構項目」、「功能性建構稽核」及「實體性 建構稽核」。) 建構資訊是指產品或產品組件生命中某一特定時 間的資訊,建構基準加上以這些基準為主所核可 的變更,構成目前的建構基準。(請參見「產品生 命週期」。) 建構管理的元件包含評估、協調、核可或不核 可,以及正式建立建構識別後對建構項目所做的 變更。(請參見「建構識別」、「建構項目」及 「建構管理」。) 負責評估及對建構項目提出之變更的核可或不核 可,而且確保核可的變更均已執行的一組人。(請 參見「建構項目」。) 建構管制委員會又稱為 「變更管制委員會」。 建構管理的元件包含選擇產品的建構項目、指定 唯一的識別,以及記錄其功能與實體的特性於技 術文件。(請參見「建構項目」、「建構管理」及 「產品」。) 為了建構管理所指定的一組工作產品,在建構管 理流程中視為單一實體。(請參見「建構管 理」。) 634 詞彙 建構管理 建構狀態紀錄 連續式表述 合約需求 矯正措施 關於適用於服務的能力成熟度整合模式 1.2 版 應用技術與管理的引導與監督之專業訓練,來(1) 界定與記錄建構項目功能與實體的特性、(2)控制 這些特性的變更、(3)記錄與報告變更的處理與執 行的狀態,以及(4)驗證符合特定的需求。(請參 見「建構稽核」、「建構管制」、「建構識別」 及「建構狀態紀錄」。) 建構管理的元件包含記錄與報告有效管理一個建 構所需的資訊。這個資訊包括核可的建構識別清 單、建構預期變更的狀態,以及核可變更的執行 狀態。(請參見「建構識別」及「建構管理」。) 一種能力成熟模式架構,在每一特定的流程領域 中,能力度提供處理流程改善的建議順序。(請參 見「能力度等級」、「流程領域」及「階段式表 述」。) 客戶需求經分析與細化成一組的需求,以適合放 在招標文件、正式合約,或採購者與其他適當組 織之間的供應商協議。(請參見「採購者」、 「客戶需求」、「供應商協議」、與「招標文 件」。) 合約需求同時包括採購產品或服務所需要的技術 與非技術需求。 修復某種狀況、除去錯誤或調整狀態的行動或行 為。 詞彙 635 適用於服務的能力成熟度整合模式 1.2 版 客戶 客戶需求 資料 資料管理 缺失密度 已調適流程 負責驗收產品或授權付款的團體(可能是個人、專 案或組織)。客戶是專案的外部單位(當 IPPD 使用 整合團隊時,可能除外),但未必是組織的外部單 位。客戶可能是較高層的專案。客戶是關鍵人員 的一部分。(請參見「關鍵人員」。) 大部分使用這個名詞時,意指上述定義。然而, 有些情況“客戶”意含其他相關的關鍵人員。(請參 見「客戶需求」。) 最終使用者可能與客戶不同,如果對方是直接收 到服務的價值(也就是最終使用者),而不同於 安排的、付款的或協調服務合約的一方。在內容 中,客戶和最終使用者是同一方,則“客戶”一詞 可包含所有的種類。(另請參見“最終使用者”) 以客戶可接受的方式,誘導、整合及解決產品相 關關鍵人員對需要、期望、限制及介面衝突。(請 參見「客戶」。) 無論紀錄的形式與方法的紀錄資訊,包括技術資 料、電腦軟體文件、財務資訊、管理資訊、事 實、任何能夠溝通、儲存與處理的數量或數據 在資料生命週期,對經營與技術資料規劃、獲取 及提供管理之有規律的流程與系統,能與資料需 求有一致性。 每單位產品的缺失數(如每千行程式碼的問題報告 單數)。 一個已管理流程,此流程是根據組織的調適指 引,從組織標準流程所調適而來;包含維護流程 說明及對組織流程資產貢獻工作產品、度量與其 他的流程改善資訊。(請參見「已管理流程」。) 636 詞彙 交付項目 交付環境 衍生度量 衍生需求 設計審查 發展 詞彙 關於適用於服務的能力成熟度整合模式 1.2 版 設定要交付給採購者或其它指定的接收者的項 目。這個項目可以是一份文件,一項硬體、一項 軟體、服務或任何型式的工作產品。(請參見「採 購者」。) 環境與條件的完整配套下,服務的交付是根據服 務協議(請參見“服務”及“服務協議”) 遞送環境包含可能會顯著影響服務遞送的每一件 事,包括,但不只限於服務系統運作、自然環 境,以及各方不自覺產生影響的行為。例如,考 慮天氣或交通型態對運輸服務可能產生的影響 (請參見“服務系統“) 交付環境與其他的環境(例如模擬環境、測試環 境)不同。交付環境是一個服務實際交付的環 境,並需考慮到滿足服務協議。 兩個或多個基礎度量的數學函數所導出的資料。 (請參見「基礎度量」。) 在客戶需求中並未明顯陳述的需求,但可(1)自上 下文的需求推論(如應用的標準、法律、政策、 一般執行方法及管理決策),或(2)自指定產品組 件所需的需求推論。衍生需求亦可在分析與設計 產品或系統的組件時產生。(請參見「產品需 求」。) 對設計之正式的、文件化的、完整的及有系統的 檢驗,以評估設計需求與符合這些需求的設計能 力,界定問題並提出解決方案。 在 CMMI 產品系列中,不僅是發展的活動,還包 括維護活動。受益於 CMMI 最佳執行方法的專 案,可以專注於發展或維護,或者兩者並行。 637 適用於服務的能力成熟度整合模式 1.2 版 發展計畫 專業領域 文件 最終使用者 企業集團 允入準則 用以指引、執行及控制一個或多個產品之設計與 發展的計畫。(請參見「產品生命週期」及「專案 計畫」。) 在 CMMI 產品系列中,當選擇 CMMI 模式(如系 統工程)時,可使用的知識體系(bodies of knowledge)。CMMI 產品團隊未來也計劃將其他 的知識體系整合到 CMMI 架構中。 文件是資料的集合,不論其記錄媒體。文件通常 具有永久性,而且可由人或機器來閱讀。所以, 文件包括書面文件與電子文件。 最終獲取已交付的服務的利益一方(個人、專案或 組織)(請參見”客戶”)。 最終使用者可以是也可以不是客戶(能建立及接受 協議或授權付款)。 在內容中,一個單一服務協議包括不同服務交 付,任何一方啟始一個服務要求就可能被認為是 最終使用者(請參見“服務協議”及“服務需求”) 企業集團由多個公司所組成。公司可能由位於不 同地點及擁有不同客戶的多個組織所組成。(請參 見「組織」。) 在可成功開始工作投入之前,必須出現的狀態。 638 詞彙 對等的階段式 建立並維護 證據 高階主管人員 允出準則 期望的 CMMI 組 件 調查結果 正式評估流程 架構 關於適用於服務的能力成熟度整合模式 1.2 版 目標階段式由連續式表述所產生。使用目標階段 式的結果可與階段式表述的成熟度比較。(請參見 「能力度摘要」、「成熟度」、「目標摘要」及 「目標階段式」。) 不論使用何種 CMMI 表述,此階段式允許於組 織、企業及專案之間進行進度的標竿學習。組織 可能執行某些 CMMI 模式的組件超越其對等的階 段式部分組件。對等的階段式只是一個度量,以 成熟度的立場說明一個組織相對於其他組織的成 熟度。 這個字詞所包含的意義,不僅是建立並維護,它 還有書面化與使用的涵義。舉例而言,「建立並 維護組織政策,以規劃與執行組織的流程專注流 程」的意思,不僅是整理過的政策,還必須有書 面記載,並於整個組織中執行。 (請參見「客觀證據」。) (請參見「資深管理人員」。) 在可成功結束工作投入之前,必須出現的狀態。 能解釋執行什麼可滿足一個必要之 CMMI 組件的 CMMI 組件。模式的使用者可明確的執行期望的 組件,或執行與這些組件相同意義的替代執行方 法。特定與一般執行方法皆是期望的 CMMI 組 件。 (請參見「評鑑調查結果」。) 一種結構化的方法,依據已建立的準則評估備選 解決方案,並決定推薦的方案,以解決議題。 (請參見「CMMI 架構」。) 詞彙 639 適用於服務的能力成熟度整合模式 1.2 版 功能分析 功能架構 功能建構稽核 一般目標 一般執行方法 一般執行方法的 詳細說明 目標 檢驗已定義的功能來界定完成該功能所需的所有 子功能;界定功能的關係與介面(內部及外部), 並在功能架構中呈現;可自上層績效需求引導, 並將這些需求指定給下層的子功能。(請參見「功 能架構」。) 功能的階層式安排,其內部及外部(聚集本身的外 部)的功能介面、外部的實體介面、相關功能,以 及績效需求及設計限制。 執行稽核以驗證建構項目的發展已滿足的完成, 建構項目在功能或配置建構識別的績效與功能特 性已達成,以及操作與支援文件已完成與滿意。 (請參見「建構稽核」、「建構管理」及「實體建 構稽核」。) 必要的模式組件,說明制度化流程實施流程領域 必須呈現的特性。(請參見「制度化」。) 期望的模式組件,對達成相關的一般目標相當重 要。與其一般目標相關連的一般執行方法,說明 為達成一般目標結果的期望活動及貢獻流程領域 相關流程的制度化。 有助益的流程組件,出現在一般執行方法之後, 提供一般執行方法如何應用到流程領域的指引。 必要的 CMMI 組件,可能是一般目標或特定目 標。當在 CMMI 模式看到目標字詞時時常參考到 模式組件(例如一般目標與特定目標)。(請參見 「一般目標(goal)」、「目的(objective)」及「特 定目標」。) 640 詞彙 硬體工程 高層管理 不完整的流程 助益的 CMMI 組件 整合團隊 關於適用於服務的能力成熟度整合模式 1.2 版 應用有系統化、有紀律的及數量化方法,將一組 使用文件化的技術表示關鍵人員需要、期望與限 制之需求,轉換為設計、實施及維護有形的產 品。(請參見「軟體工程」及「系統工程」。) 在 CMMI 中,硬體工程代表所有的技術領域(例 如:電子、機械),轉換需求與構想為有形及可生 產的產品。 提供流程政策與整體性指導,並非提供日常流程 監督與控制的人員。此種人員在組織中高於負責 流程的中層管理人員。可能是(但不一定是) 資深 管理人員。(請參見「資深管理人員」。) 未執行或只執行部分的流程(又稱為能力度第 0 級)。該流程領域的一項或多項特定目標未達成。 可幫助模式使用者瞭解模式必要與期望組件的 CMMI 組件。這些組件包括範例、詳細解釋或其 他有助益的資訊。細部執行方法、註解、參考資 料、目標標題、執行方法標題、來源、典型的工 作產品、強化及一般執行方法詳細說明等,都是 助益的模式組件。 一組具備完整技能與專業知識的人員,能適時合 作並承諾交付特定的工作產品。整合團隊成員對 工作產品生命期各階段提供適當的技能與支持, 並能共同負責交付指定的工作產品。整合團隊應 包括來自組織、專業領域及功能的授權代表,他 們對於工作產品的成功都有利害關係。 詞彙 641 適用於服務的能力成熟度整合模式 1.2 版 介面控制 生命週期模式 已管理流程 管理人員 成熟度 度量 度量作業 協議備忘錄 自然界限 642 建構管理中的流程,包括:(1)由一個或一個以上 的組織所提的二個或多個建構項目,界定與其介 面相關的所有功能與實體特性的流程,以及(2)在 執行之前,確保對這些特性提出的變更,是經過 評估與核可的流程。(請參見「建構項目」及「建 構管理」。) 將一個產品或專案的生命週期分成數個階段。 已執行的流程依照政策規劃與執行;雇用有技能 的人有足夠資源生產受管理的產出;納入相關的 關鍵人員;有監督、控制與審查;以及評估遵循 流程說明程度。(請參見「已執行的流程」)。 在 CMMI 產品系列中,管理人員提供技術與管理 的方向與控制給其責任區域內執行工作與活動的 人員。管理人員傳統的功能包括:責任區域內規 劃、組織、領導及管制工作。 流程改善的程度,在一組事先定義的流程領域 中,其所有的目標皆達成。(請參見「能力度」及 「流程領域」。) 用來賦予度量值的變數。(請參見「基礎度量」、 「衍生度量」及「度量作業」。) 一組用來決定度量值的作業。(請參見「度 量」。) 二個或多個團體之間瞭解或協議必須遵守的文 件。(又稱為「備忘錄」。) 流程的本質以流程績效的度量來表示,有時稱為 「流程的聲音」。使用如管制圖、信賴區間與預 測區間的技術,來決定變異是來自於共同原因(即 流程是可預測的或「穩定的」),或來自於某些可 以且應找出並移除的特殊原因。 詞彙 非發展項目 非技術需求 目標 客觀證據 客觀評估 觀察 操作概念 關於適用於服務的能力成熟度整合模式 1.2 版 採購或發展流程中,於使用之前即已發展完成的 供應項目,該項目可能只需要較小的修改,以符 合其目前期望的使用需求。 合約規定、承諾、條件及條文,將影響產品或服 務如何獲得。例如:交付的產品、交付現成品 (COTS)與非發展項目(NDIs)的資料權、交付日期 及有允出準則的里程碑。其他的非技術需求包括 訓練需求、場地需求及部署時程等。 在 CMMI 產品系列中,「目標(goal)」一詞已有 特定的用途,即使用於「一般目標」與「特定目 標」中。所以,當模式中需要表達日常使用之 「目標(goal)」的意義時,會以「目標 (objective)」來表示。(請參見「目標(goal)」。 如 CMMI 評鑑資料、文件或面談結果,用來當做 模式執行方法的實施與制度化的指標。客觀證據 的來源能包括工具、簡報文件及訪查。 依據準則審查活動與工作產品,將審查人員的主 觀與偏見減至最小。由獨立的品質保證功能人 員,針對需求、標準或程序所執行的稽核是客觀 評估的範例。(請參見「稽核」。) 如同 CMMI 評鑑資料,「觀察」是一份書面的紀 錄,用以表示評鑑組成員在評鑑資料蒐集活動 中,對於所見所聞的瞭解。該書面紀錄可以用報 告表的格式,也可以用其他的表格來記錄,只要 可以保存資訊的內容即可。 一個實體使用或操作方法的一般描述。(又可稱為 「操作概念(concept of operations)」。) 詞彙 643 適用於服務的能力成熟度整合模式 1.2 版 操作劇本 最佳化流程 想像之事件順序的描述,包括產品與其環境與使 用者的相互作用,以及產品組件之間的相互作 用。操作劇本用來評估系統的需求與設計,並驗 證與確認系統。 根據瞭解流程變異的共同原因,而改善的量化管 理流程。以漸進與創新的改善,最佳化流程專注 於流程績效範圍的持續改善。(請參見「流程變異 的共同原因」、「已調適流程」及「量化管理流 程」。) 組織 組織成熟度 組織政策 組織流程資產 一個行政管理結構由成員共同管理一個或多個專 案。這些專案有共同的資深管理人員,並在相同 的政策下運作。不過在 CMMI 模式中,「組織」 也可以是只有一個人以執行某功能的小組織;如 果在大組織中,這些功能可能由一組人執行。(請 參見「企業集團」及「組織單位」。) 組織明顯且一致地推展流程的程度,這些流程已 文件化、已管理、已度量、已控制及持續改善。 組織成熟度可由評鑑來度量。 通常由資深管理人員所建立的指引原則,組織採 納後將會影響並決定決策。 流程的說明、實施及改善有關的成果(artifacts) (如 政策、度量、流程說明及流程實行支援工具 等。),「流程資產」指出發展或取得這些成果的 目的,在於滿足組織的經營目標。流程資產也代 表組織的投資,並預期這些投資會提供目前及未 來的經營價值。(請參見「流程資產館」。) 644 詞彙 組織單位 組織經營目標 組織度量儲存庫 組織流程資產館 組織標準流程 關於適用於服務的能力成熟度整合模式 1.2 版 組織中接受評鑑的部分。組織單位推展一個或多 個流程,這些流程具有一致性的流程範圍,並在 一致性的經營目標下執行。組織單位通常是較大 組織的一部分,然而在小組織中,組織單位可能 就是整個組織。 資深管理人員所發展的策略,用來確保組織永續 存在及增強其獲利率、市場佔有率,以及其他影 響組織成功的因素。(請參見「品質與流程績效的 目標」及「量化目標」。) 當應用至系統工程的活動時,這樣的目標包括降 低系統整合階段需求變更的次數、減少發展週期 時間、增加發展的第一或第二階段錯誤發現的數 目、減少客戶所報告的缺失數等等。 蒐集與提供流程與工作產品之度量資料的儲存 庫,尤其是與組織標準流程相關的資料。儲存庫 包含或參考實際的度量資料或其參照的資料,以 及瞭解與估計度量資料所需的相關資訊。 用來儲存與使有用流程資產館。它使組織中定 義、實施及管理流程的人員,可以取得這些有用 的流程資產。這資訊庫包含流程相關文件,如政 策、已調適流程、檢查表、學習心得的文件、樣 板、標準、程序、計畫、及訓練教材等。 組織中引導所有活動之流程的定義。這些流程說 明涵蓋基本的流程元件(process elements)(及其相 互的關係,如次序與介面)。而且這些基本的流程 元件必須合併到整個組織的專案所執行的已調適 流程中。標準流程使整個組織具有一致的發展活 動與維護活動,也是長期之穩定性及改善的重要 條件。(請參見「已調適流程」及「流程元 件」。) 詞彙 645 適用於服務的能力成熟度整合模式 1.2 版 委外 同仁審查 已實現流程 實體建構稽核 已規劃的流程 政策 流程 流程行動計畫 流程執行團隊 646 請參見”採購”。 在工作產品發展期間,由工作同仁對工作產品所 執行的審查,以界定須移除的缺失。在 CMMI 產 品系列中,使用「同仁審查(peer review)」,而不 使用「工作產品檢查(work product review)」。(請 參見「工作產品」。) 完成所需的工作以產生工作產品的流程。流程領 域的特定目標已經滿足。 執行稽核以驗證所建立的建構項目,符合技術文 件的定義與說明。 (請參見「建構稽核」、「建 構管理」及「功能建構稽核」。) 指包含說明與計畫之文件化的流程,說明與計畫 應彼此協調,而且計畫應包括標準、需求、目 標、資源及工作指派等。 (請參見「組織政策」。) 在 CMMI 產品系列中,活動可視作 CMMI 模式中 執行方法的實施。這些活動可以對照到 CMMI 流 程領域的一個或多個執行方法,以允許模式有用 於流程改善及流程評鑑。(請參見「流程領域」, 「子流程」及「流程元件」。) 在一般目標與一般執行方法的敘述與說明,「流 程」字詞有特別的用法。「流程」如同使用再第 二部份時,是指實施該流程領域的一個流程與許 多流程。 通常是評鑑結果後的計畫,針對評鑑時發現的缺 失,記錄如何實施改善。 記錄於流程行動計畫中,負責發展及執行組織流 程改善活動的團隊。 詞彙 流程與技術改善 流程架構 流程領域 流程資產 流程資產館 流程屬性 流程能力 流程範圍 流程定義 流程說明 關於適用於服務的能力成熟度整合模式 1.2 版 對流程或產品技術漸進與創新的改善。 標準流程中,流程元件間的次序、介面、相互依 賴,以及流程元件間的其他關係。流程架構也說 明流程元件與外部流程(例如:合約管理)間的介 面、相互依賴及其他關係。 一組同屬某領域及相關的執行方法,當共同執行 時,可以達成一組目標,而這些目標對該領域的 重大改善是重要的。對連續式表述與階段式表述 所有的 CMMI 流程領域而言,都是共通的。 組織認為達到某流程領域目標有用的任何事物。 (請參見「組織流程資產」。) 流程資產的蒐集,可用於組織或專案。(請參見 「組織流程資產館」。) 流程能力的可度量特性,可適應用於任何流程。 遵循一個流程可達到之預期結果的範圍。 記載在評鑑輸入文件中,影響評鑑評等判斷與比 較的一組因素。 這些因素包括但不限於(a)受評鑑組織單位的大 小;(b) 組織單位的地域分布;(c)產品或服務的 應用領域;(d) 產品或服務的大小、關鍵性、與複 雜度;與(e) 產品或服務的品質特性。 定義與描述流程的行動。流程定義的結果為流程 說明。(請參見「流程說明」。) 以文件化的表達方式,表示執行一組活動以完成 某特定的目的。 詞彙 647 適用於服務的能力成熟度整合模式 1.2 版 流程元件 流程組 流程改善 流程改善目標 流程改善計畫 流程度量 流程負責人 流程的基本單位。以子流程或流程元件的方式定 義流程,子流程可以繼續分解成其他的子流程與/ 或流程元件,但流程元件則不能繼續分解。 每一個流程元件包含一組關係密切的活動(例如: 估計元件、同仁審查元件)。可使用待完成的樣 版、待調修的摘要,或待修正或使用的說明,來 描述流程元件。流程元件可以是一項活動或工 作。 協助定義、維護及改善組織所使用之流程的專家 群。 用來改善組織流程績效與成熟度的行動計畫,以 及該計畫的成果。 採用可度量方式所建立一組目標特性,用以改善 現有流程的指引。度量方式可以是產品結果的特 性(例如:品質、績效、標準的符合程度等),或 是流程執行的方式(例如:除去多餘的流程步驟、 合併流程步驟、改善週期時間等)。(請參見「組 織經營目標」及「量化目標」。) 基於充分瞭解現在組織流程與資產的優點與缺 點,為達成組織流程改善的目標的計畫。 用來度量流程及其產品的定義、方法與活動,其 目的是瞭解該流程及記述其特徵。 負責定義與維護流程的個人(或團隊)。在組織層 級,流程負責人是負責描述標準流程的個人(或團 隊)。在專案層級,流程負責人是負責描述已調適 流程的個人(或團隊)。因此在不同層級責任中, 一個流程可能有多個流程負責人。(請參見「已調 適流程」及「標準流程」。) 648 詞彙 流程績效 流程績效基準 流程績效模式 流程調適 產品 產品組件 產品組件需求 關於適用於服務的能力成熟度整合模式 1.2 版 遵循一個流程所達成實際結果的度量。是由流程 度量(如工作量、週期時間及缺失移除的效率)與 產品度量(如可靠度、缺失密度及反應時間)所描 述。 遵循一個流程所達成實際結果的特性紀錄,用來 作為比較實際流程績效與預期流程績效的標竿。 (請參見「流程績效」。) 描述流程與其工作產品的屬性間的關係,它們自 歷史的流程績效資料發展而來,並使用專案所蒐 集的流程與產品度量加以調校,以及來預測後續 流程達成的結果。 為了某特定目的而製作、修改或改編流程說明。 例如:專案自組織標準流程調適其已調適流程, 以符合專案的目標、限制及環境。(請參見「已調 適流程」、「組織標準流程」及「流程說明」。) 在 CMMI 產品系列中,產品是指預定交付給客戶 或最終使用者的工作產品。產品的形式依不同的 情況而異。(請參見「客戶」、「產品組件」、 「服務」及「工作產品」。) 在 CMMI 模式中,產品組件通常指產品中較低階 的工作產品,產品組件經由整合以組合成產品, 產品組件可以有許多層次。(請參見「產品」及 「工作產品」)。 在整個流程領域中所使用的產品及產品組件一 詞,其所指的意義也包含服務、服務系統及其組 件。 產品組件的完整規格,包含適合、表格、功能、 績效及其他需求。 詞彙 649 適用於服務的能力成熟度整合模式 1.2 版 產品生命週期 產品線 產品相關的生命 週期流程 產品需求 產品系列 摘要 計畫 從產品的構想開始,到產品不再使用的期間,通 常分幾個階段。組織可能同時為多個客戶生產多 個產品,單一產品生命週期的描述可能不足。所 以組織可以定義一組經驗證的產品生命週期模 式。這些模式通常可以從公開的刊物上尋得,但 多半須調適才能適用於組織。 產品生命週期可包含下列的階段:(1)概念/願景; (2)可行性研究;(3)設計/發展;(4)生產;(5)廢 除。 擁有共同的及已管理特性的一系列產品,可滿足 某一部分市場或任務的特定需要。 與產品生命週期一個或多個階段相關的流程(例 如:從概念設計到產品汰除),例如:製造與支援 流程。 將客戶的需求調修成發展者的語言,將隱含的需 求變成明確的衍生需求。(請參見「衍生需求」及 「產品組件需求」。) 發展者使用產品需求來指引設計與產品的製作。 (請參見「CMMI 產品系列」。) (請參見「達成摘要」與「目標摘要」。) (1)一個專案。(2)一組相關的專案及支援它們的 基礎架構,包括目標、方法、活動、計畫及成功 的度量。(請參見「專案」。) 650 詞彙 專案 關於適用於服務的能力成熟度整合模式 1.2 版 在 CMMI 模式中,一組受管理的相關資源,以便 交付一項或多項產品給客戶或最終使用者。專案 有明確的開始點(例如專案啟動)及依據計畫執 行。這個計畫大多以文件記載,並說明將交付與 實作的產品、所使用的資源與經費、工作項目及 工作時程表。一個專案也可以由多個專案組成。 (請參見「專案啟動」。) 專案一詞是指一群人和資源在已分享的工作中投 入規劃、監督和執行已調適的流程,以達到一組 目標。 詞彙 651 適用於服務的能力成熟度整合模式 1.2 版 專案管理人員 專案計畫 專案進度與績效 專案啟動 專案已調適流程 在 CMMI 產品系列中,負責規畫、督導、控制、 組織及推動專案的人。專案管理人員負責滿足客 戶的需求。 計畫提供執行與控制專案活動的基礎,以處理對 專案客戶的承諾。 專案規劃包括估計工作產品與工作項目的屬性、 決定所需的資源、協商、承諾、產生時程,以及 界定與分析專案風險,有時需要重覆些活動足以 建立專案計畫。 專案根據執行專案計畫所達成者,包括工作量、 成本、時程及技術績效。 當一組相關的資源被指示去發展或交付一個或多 個產品給客戶或最終使用者。(請參見「專 案」。) 由組織標準流程調適而得的已整合與定義的流 程。(請參見「已調適流程」。) 652 詞彙 雛型 品質 品質與流程績效 的目標 品質保證 量化目標 關於適用於服務的能力成熟度整合模式 1.2 版 產品或產品組件的初步類型、形式或實例,可作 為後續階段或最終完成產品的模型。這個模型(實 體的、電子的、數位的、分析的等)可用於下列 (及其他)目的: 評量新的或不熟悉技術的可行性。 評量或降低技術風險。 確認需求。 展示重要的特性。 證明產品合格。 證明流程合格。 證明流程合格。 說明物理的原理 產品、產品組件或流程本身特性的能力,以滿足 客戶需求。 產品品質、服務品質、與流程績效的目標與需 求。流程績效目標包括品質;然而,在 CMMI 產 品系列中為了強調品質的重要性,所以使用品質 與績效目標字詞而不是流程績效目標。 保證管理以有計劃的與系統化的方法,引用已定 義的流程標準、執行方法、程序及方法。 以量化的度量表示期望的目標值。(請參見「流程 改善目標」及「品質與流程績效的目標」。) 詞彙 653 適用於服務的能力成熟度整合模式 1.2 版 量化管理流程 評等 參考資料 參考模式 相關的關鍵人員 表述 必要的 CMMI 組 件 需求 需求分析 需求誘導 654 已經以統計及其他量化技術來控制的已調適流 程,在整個專案過程中,產品品質、服務品質及 流程績效的屬性是可度量與控制的。(請參見「已 調適流程」、「最佳化流程」及「統計化管理的 流程」。) (請參見「評鑑評等」。) 助益的模式組件,它指引在相關的流程領域中更 多詳細的資訊。 當作度量某些屬性之標竿的模型。 界定參與某特定活動與納入計畫的關鍵人員。 (請參見「關鍵人員」) CMM 組件的組織、使用及展示。總體而言,顯 然有兩種方法表示最佳執行方法:階段式表述與 連續式表述。 在流程領域中,要達成流程改善的必要 CMMI 組 件,這些組件在評鑑中用以決定流程的能力。特 定目標與一般目標是必要的模式組件。 (1)使用者解決問題或達成目標所需的條件或能 力。(2)產品或產品組件必須符合或擁有的條件或 能力,以滿足合約、標準、規格或其他正式提出 的文件。(3)記錄(1)或(2)所述之條件或能力的文 件。 以客戶需要、期望及限制的分析;操作觀念;人 員、產品及流程的預期使用環境;以及度量的有 效性為基礎,來決定產品特定的績效與功能的特 徵。 使用有系統的技術,例如雛型與結構化調查,以 主動界定與記錄客戶與使用者的需要。 詞彙 需求管理 需求追溯 投資報酬率 風險分析 風險界定 風險管理 風險管理策略 根本原因 關於適用於服務的能力成熟度整合模式 1.2 版 管理專案收到或產生的所有需求,包括技術與非 技術的需求,以及組織對專案的需求。 需求與相關需求、實施及驗證間可識別的關連。 (請參見「雙向追溯性」及「追溯性」。) 輸出(產品)相對於生產成本的收益比,用以決定 組織是否由產生產品的執行行動中獲得利益。 風險的評估、分類及設定優先順序 有組織且完整的方法,以尋找達成目標時可能的 或實際的風險。 一個有組織、分析式的流程,用以界定可能造成 傷害或損失的來源(界定風險);評量及量化已界 定的風險;以及發展並於必要時執行適當的方 法,來避免或處理可能造成巨大傷害或損失的風 險原因。 一個有組織、技術的方法,用以界定可能造成傷 害或損失的原因(界定風險);評量及量化已界定 的風險;以及發展與並於必要時執行適當的方 法,來避免或處理可能造成巨大傷害或損失的風 險原因。通常風險管理是為專案、組織或發展產 品的組織單位而實行。 缺失的源頭,一旦去除,缺失會減少或清除。 詞彙 655 適用於服務的能力成熟度整合模式 1.2 版 資深管理人員 服務 在 CMMI 模式中,一個組織中,層次夠高的管理 角色。資深管理人員主要專注於組織永續的經 營,而不是短期的專案及合約的顧慮與壓力。資 深管理人員有權分配或重分配資源,以支持組織 流程改善的有效性。(請參見「高層管理」。) 符合以上條件的管理人員都可以是資深管理人 員,包括組織負責人。資深管理人員的同義詞有 「執行長(executive)」與「高層主管(top-level manager)」,但為了確保模式的一致性及實用 性,CMMI 模式裡並不使用這兩個同義詞。 在 CMMI 產品系列中、服務是無形與不可儲存的 產品。(請參見「產品」、「客戶」、「工作產 品」及「服務」。) 服務是經由服務系統的使用而交付,而服務系統 已被設計用來滿足服務需求。(另請參見「服務 系統」) 許多服務定提供者交付綜合的服務及商品。一個 服務系統可以交付二種型態的產品。例如,一個 訓練組織可以交付訓練教材及訓練服務。 服務可以藉由手動及自動流程的綜合型態交付。 656 詞彙 服務協議 服務型錄 服務事故 詞彙 關於適用於服務的能力成熟度整合模式 1.2 版 須遵守的、寫下的,服務提供者和客戶間,已承 諾的價值的交換的紀錄。(另請參見“客戶”) 服務協議可以是完全可協商的、部份可協商或不 可協商的,可由服務提供者、客戶或雙方先草 擬,端視情況而定。 一個「已承諾的價值交換」表示一聯合的認可與 接受任一方提供給另一方的內容,以滿足協議。 通常,客戶提供貨款以交換交付的服務,但其他 的安排也是可能的。 一個寫下的紀錄可能不會包含在一單一文件或其 他成果中。反而是,可能非常簡短地在一些服務 型態中描述(例如,一個確認服務、價格和收貨 人的收據) 一個儲存標準化服務定義的清單。 服務型錄可能包含有關可提供的服務等級、品 質、價格、可協商/可調適項目,及條件與情況 等細節的不同程度。 一個服務型錄可能不會包含在單一文件或其他成 果,而可能是提供對等資訊項目的綜合(例如連 結到資料庫的網頁)。對某些服務,一個有效的 型錄可能是簡單印出的可提供的服務及其價格的 清單。 服務型錄資訊可分為不同的子集,以支援不同型 態的關鍵人員(例如,客戶、最終使用者、提供 者、供應商) 一個對服務實際或潛在干擾的指標。 服務事故可能發生在服務領域,因為客戶和最終 使用者的抱怨是事故的種類,而甚至最簡單的服 務也會產生抱怨。「事故」這個字即為「服務事 故」的簡寫,以使其意義更為清楚。 657 適用於服務的能力成熟度整合模式 1.2 版 服務等級 服務等級協議 服務等級度量 服務線 服務請求 一個服務交付績效的強度、等級或品質。(請參見 「服務」及「服務等級度量」。) 一個服務協議說明交付的服務;服務的度量;可 接受和不可接受的服務等級;期望的責任、信賴 及預測情形下提供者和客戶的行動。(另請參見 “度量”、“服務”和“服務協議”) 服務等級協議是服務協議,記載「定義」中的 詳 細事故。 使用「服務協議」一詞總是包括「服務等級協 議」,如同一個次目錄,以及前者可視為後者的 簡寫。然而,「服務等級協議」是一個較喜歡使 用的術語,當它被希望用來強調可接受服務的不 同專等級,或當其他的服務等級協議的細節對討 論可能是重要的時候。 服務績效度量可作為驗收結果或行為之目標。(請 參見「度量」及「服務」。) 一個明確的、標準化的一套服務及服務等級可滿 足已擇定的市場或任務領域的特定需求。(另請 參見“服務等級”) 一個從客戶或最終使用者所傳達的一個或數個特 定的服務交付實例的想法。這些需求會寫在服務 協議內容中。(另請參見“服務協議”) 如果服務持續地或定期地交付,一些服務需求可 能即是在服務協議中明確地確認。 其他情形,服務需求落在先前依客戶或最終使用 者的期望發展,而訂立的服務協議的範圍之外。 658 詞彙 服務需求 服務系統 服務系統組件 詞彙 關於適用於服務的能力成熟度整合模式 1.2 版 一整套會影響服務交付及服務系統發展的需求。 (另請參見“服務系統”) 服務需求包括技術及非技術的需求。技術需求是 要交付服務的專門領域,服務系統是用來啟動交 付。非技術需求可以包括額外的情形、條款、承 諾及合約、協議及規則中確認的條件,以及從營 運目標中衍生出所需要的能力與條件。 一個整合的、相互依賴的組件資源的綜整,以滿 足服務需求(另請參見“服務系統組件”及“服務需 求”)。一個服務系統包含服務交付所需的每件 事,包括工作產品、流程、設備、工具、消耗及 人力資源。 請注意,一個服務系統包括需呈現服務系統流程 的人員。在內容中,最終使用者必須呈現完成服 務交付的一些流程,而最終使用者也是服務系統 的一部份(至少在互動的那一段時間中)。 一個複雜的服務系統可以分成不同的交付與支援 系統或子系統。而這些分隔及不同對服務供應商 組織而言可能很重要,它們可能對其他的關鍵人 員不具意義。 服務系統所需的資源,以成功地交付服務。一些 組件可能仍由客戶、最終使用者或第三方擁有, 在服務交付開始及服務交付結束後。(另請參見 “客戶"及“最終使用者")。 一些組件可能是服務系統的一部份在一特定時間 的短暫的資源(例如:在維修商店修理的項目) 組件可包含流程和人員。“組件”這個字可以在“服 務系統組件”中視為簡寫,以使意義更清楚。 架構這個字可整合地使用在服務系統組件,它們 是明確的,且重要的。視內容及服務型態,架構 可以包括人力資源。 659 適用於服務的能力成熟度整合模式 1.2 版 服務系統消耗品 共同願景 軟體工程 招商 招商文件 流程變異的特殊 原因 特定目標 一個服務系統組件可以減輕為可提供的或藉由它 的使用,在服務交付時變成永久地。燃料、辦公 室供應品及可丟棄的容器是消耗品的例子。特別 型態的服務有它們特別的消耗物品(例如,一個 保健服務可以需要藥品或血液補充)人員不是可 消耗的,但他們的工時是可消耗的。 一種指導原則的共識,包括任務、目標、期望的 行為、價值及最終結果。共同願景由專案所發展 與使用。 (1)應用系統化、有紀律的及量化的方法,來發 展、操作及維護軟體。(2)關於第(1)項方法的研 究。(請參見「硬體工程」及「系統工程」。) 準備招商文件及選擇供應商(承包商)的流程。 描述技術與非技術需求的正式文件,以作為招標 書(標書)、建議書徵求文件(建議書)、或要求能力 陳述與報價(報價單)之用。這份文件因此作為選 擇提供產品或服務之供應商的基礎。 缺失的原因是特有的某些瞬間情況,而不是流程 本身所造成。(請參見「流程變異的共同原 因」。) 必要的模式組件說明必須要呈現以滿足該流程領 域的獨特屬性。(請參考「能力度」、「一般目 標」、「組織經營目標」及「流程領域」。) 660 詞彙 特定執行方法 穩定流程 階段式表述 關鍵人員 標準 關於適用於服務的能力成熟度整合模式 1.2 版 對達成相關的特定目標是重要的期望類模式組 件。特定執行方法說明一組活動,這組活動被期 望可達成某流程領域的特定目標。 (請參見「流 程領域」及「特定目標」。) 在連續表述方式中,每一個特定執行方式都伴隨 一個能力等級。在階段式表述方式中,沒有特別 註明能力等級,所以所有的特定執行方式都被平 等對待。 當所有流程變異的特殊原因皆已移除,且避免再 發生,以致只留下流程變異的共同原因。(請參見 「有能力的流程」、「流程變異的共同原因」、 「標準流程」、「流程變異的特殊原因」及「統 計化管理的流程」。) 一種模式架構,當達到一組流程領域的所有目 標,則建立了一成熟度等級;每一等級是後續等 級的基礎。(請參見「成熟度」及「流程領 域」。) 在 CMMI 產品系列中,承擔計畫執行結果或受計 畫影響的個人或團體,關鍵人員可能包括專案成 員、供應商、客戶、最終使用者及其他。(請參見 「客戶」及「相關的關鍵人員」。) 在 CMMI 模式中,當名詞使用的「標準 (standard)」是指一個正式且具強制性的需求,這 些需求被發展及用來規定具有一致性的發展方法 (例如:ISO/IEC 標準、IEEE 標準、組織的標 準)。我們使用與「標準」有相同意義的其他術語 來代表一般日常意義的「標準」(例如:典型的、 傳統的、通常的或慣例)。 詞彙 661 適用於服務的能力成熟度整合模式 1.2 版 標準流程 工作說明書 統計的可預期度 統計流程管制 統計技術 統計化管理的流 程 細部執行方法 子流程 基本流程的操作定義,用來指導組織共用流程的 建立。 標準流程描述基本的流程元件,期望這些流程元 件可包含在任何已調適流程中,它也描述這些流 程元件之間的關係(如順序與介面)。(請參見「已 調適流程」。) 完成專案所需之協議工作的說明。 量化流程的績效,可由統計及其他量化的技術所 控制。 以統計的方法分析流程與度量流程的績效,可界 定流程績效,變異的共同與特殊原因,並將流程 績效維持在某一範圍內。(請參見「流程變異的共 同原因」、「流程變異的特殊原因」及「統計化 管理的流程」。) 應用統計方法的分析技術(例如:統計流程管制、 信賴區間及預測區間)。 已以統計技術管理的流程,此流程已被分析、界 定流程變異的特殊原因,且績效維持在明確界定 的範圍內。(請參見「有能力的流程」、「流程變 異的特殊原因」、「穩定流程」、「標準流程」 及「統計流程管制」。) 提供指引詮釋與執行特定或一般執行方法,為助 益的模式組件。細部執行方法以規範式的文字描 述,僅提供可用於流程改善的意見而不具強制 性。 較大流程的部分流程。子流程能再細分為子流程 及/或流程元件。(請參見「流程」、「流程說 明」及「流程元件」。) 662 詞彙 供應商 供應商協議 維持 系統工程 多系統組成的系 統 調適 關於適用於服務的能力成熟度整合模式 1.2 版 (1)一個可交付購買產品或提供服務的實體。(2) 個人、合夥、公司、法人、協會或其他的服務機 構,與採購者有協議(合約),在協議(合約)的條款 下進行設計、發展、製造、維護、修訂或供應商 品。 採購者與供應商之間的書面化協議(例如,合約 書、授權書、協議備忘錄) 確保產品可供最終使用者與客戶操作的流程。 橫跨不同專業領域,管控整個技術與管理投入之 方法,用來將客戶的需要、期望及限制,轉換成 為產品的解決方案,並在產品生命週期內支援該 解決方案。(請參見「硬體工程」及「軟體工 程」) 包括技術的績效度量定義,整合工程的特性來建 立產品的架構,以及支援生命週期流程的定義, 用來平衡成本、績效及時程的目標。 一套或一組系統,它來自整合一些獨立與有用的 系統以構成提供特定功能的大系統。 調適流程為了特定目的,製作、改變或調整流程 說明。舉例而言,某專案經由調適組織標準流 程,來建立一套已調適流程,以符合專案的目 標、限制及環境。 詞彙 663 適用於服務的能力成熟度整合模式 1.2 版 調適指引 目標摘要 目標階段式 技術績效 技術績效度量 技術需求 測試程序 追溯性 664 組織指引,能讓專案、團隊及組織功能經由適當 的調適標準流程,以符合他們的使用。在 CMMI 模式中,組織標準流程只是一般性的說明,不見 得可直接用來執行流程。 調適指引可輔助為專案建立已調適流程的人。調 適指引的內容涵蓋:(1)選擇一標準流程,(2)選擇 一經驗證的生命週期模式,以及(3) 調適所選擇的 標準流程及生命週期模式,以符合專案的需要。 調適指引說明調適時哪些內容是否可修改,並界 定哪些流程組件是可修改的對象。 在連續式表述中,一組流程領域與其相關的能力 度等級,可表示流程改善的目標。(請參見「達成 摘要」及「能力度摘要」。) 在連續式表述中,用來描述流程改善途徑,以供 組織遵循的一系列目標摘要。(請參見「達成摘 要」、「能力度摘要」及「目標摘要」。) 一般定義為功能或技術需求的流程、產品或服務 的特性(例如,預估的準確度、使用者功能、安全 功能、回應時間、元件準確度、最大重量、最小 產出率、與允差範圍)。 精確定義一項需求或能力,或需求與能力的組合 之技術性度量。(請參見「度量」。) 欲採購或發展的產品或服務的內容(屬性)。 為某特定測試的準備、執行及結果評估的詳細說 明。 兩個或更多個邏輯實體(如需求、系統元件、驗證 或工作項目)間可辨識的關聯。 (請參見「雙向追 溯性」及「需求追溯性」。) 詞彙 替代方案研究 訓練 典型的工作產品 元件測試 確認 驗證 版本管制 分工結構圖 關於適用於服務的能力成熟度整合模式 1.2 版 根據準則與系統化分析,評估各個方案,以選擇 能達成目標的最佳方案。 正式與非正式學習選項,可包括課堂訓練、非正 式指導:上網訓練、自我引導學習及正式工作中 訓練計畫。對每一情況的學習是基於選擇訓練需 要的評量及欲解決的績效落差。 提供某特定執行方法的產出範例之助益的模式組 件。這些範例之所以稱為典型的工作產品,是因 為除了這些具代表性的範例之外,還有其他的工 作產品也是有助益的,但未被列出。 個別的硬體或軟體單元或一組相關單元的測試。 (請參見「驗收測試」。) 證實所提供的產品(或即將提供的產品),符合其 預期的使用需求。換句話說,「確認」確保「你 做了正確的事」(請參見「驗證」。) 證實工作產品是否適當的反映其指定的需求。換 句話說,驗證確保「你做對了」。(請參見「確 認」。) 建立與維護基準及界定基準的變異,使還原至前 一個基準成為可能。 工作項目的安排、其彼此之間的關係,以及與最 終產品之間的關係。 詞彙 665 適用於服務的能力成熟度整合模式 1.2 版 工作產品 工作產品與工作 項目屬性 在 CMMI 產品系列中,一個流程所產出的有用結 果。工作產品包括檔案、文件、產品、產品組 件、服務、流程說明、規格及出貨單。工作產品 與產品組件的主要差異,在於工作產品不必要是 產品的一部分。(請參見「產品」及「產品組 件」。) 在 CMMI 模式中,許多地方使用了工作產品及服 務字詞。雖然工作產品的定義已包含服務,但在 討論中,使用這個字詞強調工作產品包括了服 務。 產品、服務及專案工作的特性,可協助估計專案 的工作量。這些特性的項目包括如:規模大小、 複雜度、權重、表格、安裝與功能。它們通常作 為輸入以推得其他的專案及資源的估計值(如工作 量、成本、時程)。 666 詞彙 報告紀錄頁 Form Approved OMB No. 0704- 0188 資料蒐集的公開回報負荷,每個回應平均約需一小時,包含審查指令的時 間,搜尋現有資料來源,蒐集、維護所需資料,完成與審查所蒐集的資 料。對本負荷評估的評論,或者任何其他資料蒐集,包含對減輕負荷的建 議,請告知華盛頓總部服務中心,Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202- 4302, and to the Office of Management and Budget, Paperwork Reduction Pro- ject (0704-0188), Washington, DC 20503. 1. 限機關使用 (空白) 2. 報告日期 2009 年 2 月 4. 主標題與副標題 CMMI for Services, Version 1.2 6. 作者(群) CMMI Product Team 7.執行組織與地址 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 9. 贊助/監督單位名稱及地址 HQ ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2116 11. 補充附註 12A 發行/取得聲明 未管制/無限制,DTIC, NTIS 3.報告的類別與 日期 結案 5. 贊助編號 8. 執行組織報告 編號 CMU/SEI2009-TR-001 10. 贊助/監督單 位 報告編號 017 12B 發行代碼 適用於服務的能力成熟度整合模式 1.2 版 13. 摘要(最多 200 字) 適用於服務的能力成熟度整合模式提供指引給服務供應商組織以建 立、管理及交付服務。這個模式著重在服務供應流程及整合對成功的 服務交付而言很重要的知識體。 CMMI-SVC 提供最佳範例給服務供應商,以用來 • 決定應提供何種服務、定義標準服務及讓人們瞭解。 • 確認他們有所有交付服務時需要的東西,包括人員、流程、消耗品 及設備。 • 取得準備好的新系統,修改現行的系統,汰換損壞的系統,並整體 確認不會發生嚴重錯誤。 • 建立協議、注意服務需求及運作服務系統 • 確認有所需的資源以交付服務,以及當需要時可提供服務-以適當 的成本。 • 處理錯誤的部份—可能的話,在第一時間避免錯誤。 • 確保它們準備好從潛藏的災難中復原,以及當災難發生時,能回復 到交付服務。 14. 主要名詞 CMMI, 服務 16. 價格 15. 頁數 531 17.報告之安全等 級 未管制 18.本頁之 19.摘要之安全等級 安全 未管制 等級 未管制 20.摘要限制 無限制 NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18 298-102 668

Top_arrow
回到顶部
EEWORLD下载中心所有资源均来自网友分享,如有侵权,请发送举报邮件到客服邮箱bbs_service@eeworld.com.cn 或通过站内短信息或QQ:273568022联系管理员 高进,我们会尽快处理。