Page 14 - Vol.43

Tech
Notes
技術專文

表1、變更管理六種活動流程
活動 下屬活動 說明
識別潛在的變更 需要新功能 客戶需要新功能並闡述需求。
遇到問題 客戶遇到系統上的問題(例如：程式錯誤)，並導致一件問題報告的後果。
請求變更 客戶透過建立一個變更請求，提案變更。
分析變更請求 確定技術可行性 確定變更請求提案的技術可行性，導致一個「變更技術可行性」。
確定成本和效益 確定變更請求提案的成本和效益，導致一個「變更成本和效益」。這和上述的下屬活動可以任何順序完成，彼此獨
立。因此，建模為無序的活動。
評估變更 基於變更請求，其「變更技術可行性」和「變更成本和效益」由變更委員會作成通過/未通過的決策。這被建模為一
個單獨的活動，因為它是一個重要的流程步驟，並且具有執行它的另一個角色。蘭柯‧何姆斯〈Remko Helms〉建
議將此建模為一個下屬活動〈沒有任何活動包含它〉 。
規劃變更 分析變更影響 在一個「變更影響分析」確定了變更範圍，這個活動導致另一個通過/未通過的決策，或甚至構成「分析變更請求」
活動的一部分，可能會有爭議。
建立計畫 為了實施變更而建立一個變更計畫，一些流程說明〈例如：Mäkäräinen, 2000〉闡明可能「保留」變更，並以批式
方式處理這些變更，這個活動可被視為一個好做法。
實施變更 執行變更 變更是「被計劃的」，這個活動和普及變更有很強烈的關係，因為系統的其他部分〈甚至其他系統〉有時也需要適
應變更。
普及變更 由「執行變更」活動而來的變更，必須普及於受其影響的系統其他部分，因為這個與上述下屬活動彼此高度依賴，
而被建模為並行活動。
測試變更 變更執行者測試其所執行的變更，是否滿足了「變更請求」。如圖所示，這可能導致一個和上述二個下屬活動一起
進行的疊代流程。
更新文檔 「文檔」更新，以反映實施的變更。
發布變更 一個新的「系統發布」公開化，以反映實施的變更。
審查和變更結案 驗證變更 新的「系統發布」中的變更實施，由專案經理進行最後一次的驗證。也許這必須在發布之前發生，但是由於其與文
獻資料來源和圖表複雜性相互矛盾的考量，選擇以這種方式進行建模，並包括這個議題。
變更結案 完成這個變更周期，亦即，結束「變更日誌登記」。

3. 研究方法

3.1 驗收移交過程資訊整合方法

為了達到有效率的資訊整合及傳達，需採取正確的專案
生命週期資訊策略，包含以下：

① 澄清主要之資訊類別
• 定義優先順訊
• 確定資訊提供者，是誰?(Whom)且何時提供?(When)
• 確定資訊內容為何?(What)

② 指派資訊負責人，確保以下工作
• 整合串聯資訊提供流程
• 建立標準化/結構化資訊格式
• 確定資訊之品質(正確性/即時性)
• 維護及管理資訊之移交

根據以上之策略，澄清資訊種類及對應負責窗口與優先
需處理的事項，並依據過往建廠專案執行現況收集及分析後，
於成廠驗收移交期間主要移交資訊可分類為以下三大類 : ①品
質；②進度；③法規，並依此分類方向歸納出主要的資訊項
目，且將每個資訊項目也清楚定義提供者/接受者及負責人，
圖6、變更管理流程圖
包含定義資訊應該啟動及完成的時間，如 表2所示。

12