【正文】 Jim Zheng/ 鄭澤旗 內(nèi)容 ? 對變動申請的管理 – 變動申請應對該變動的影響 , 成本 , 緊迫性和關聯(lián)性進行分析 – 該分析是整個變動管理的基礎 ? 審批變動并確定其時間表 ? 審查變動的建立 ,測試和實施 ? 回顧審核所有已實施的變動 質量及服務管理 Jim Zheng/ 鄭澤旗 變動申請 —范圍 ? 變動發(fā)起人及高層審批 /受益人 ? 變動咨詢顧問組織 – 涉及變動處理流程的所有人員是該組織的一部分成員 ? 變動類型 – 變動管理經(jīng)理負責依據(jù)對變動的影響 ,資源需求等的評估對變動進行分級 ,該分級決定哪些人應該參與對變動申請的審核 ? 1級 對現(xiàn)有服務影響輕微 , 變動管理經(jīng)理可以批準 ? 2級 對現(xiàn)有服務有明確的影響 , 變動申請必須與變動咨詢顧問組織討論 ,變動管理經(jīng)理需取得對此變動的授權和計劃的高層意見 ? 3級 對服務和生意有顯著性影響 , 需要較大的人力及資源投入 , 變動申請需提交IT執(zhí)行委員會批準 ? 變動優(yōu)先級 ? 所需資源估計 ? 對服務的影響 ? 什么變動 ,為什么變動 ,何時變動 質量及服務管理 Jim Zheng/ 鄭澤旗 變動優(yōu)先級 ? 變動優(yōu)先級用于對變動申請的處理進行排序 ? 變動管理經(jīng)理負責設定變動申請中變動的優(yōu)先級 ,變動申請者可以提供意見或要求某一優(yōu)先級 – 緊急 ? 馬上必須進行變動 ,否則服務會受影響 ? 緊急的變動需要調用特殊處理流程以盡快處理該變動申請 ,變動咨詢顧問組織和IT執(zhí)行委員會應該舉行緊急會議立即討論該變動申請 – 高級 ? 需要盡快進行變動 , 否則對服務會有潛在的影響 – 中級 ? 該變動主要解決一些令人頭疼的錯誤或缺少某些功能 , 可以安排時間表來解決 – 低級 ? 該變動帶來的提高不大 , 并非一定需要 ? 變動優(yōu)先級基于服務嚴重性定級或所影響的用戶數(shù)量 質量及服務管理 Jim Zheng/ 鄭澤旗 變動處理流程 變動管理經(jīng)理 變化咨詢顧問組織 IT執(zhí)行委員會 變動建立人員 變動實施人員 變動申請人 Request Assess 變動計劃 /建立 確定變動時間表 實施 回顧及完成變動 質量及服務管理 Jim Zheng/ 鄭澤旗 變動處理流程 ? 變動實施前必須取得變動管理經(jīng)理的最終批準 ? 變動實施前必須取得所有涉及到變動處理流程的人員的批準 – 這些人員中的一部分應該有權力中止某一變動 ,如果他們認為該變動具有較大的風險且沒有沒有獲得足夠的授權去實施 質量及服務管理 Jim Zheng/ 鄭澤旗 變動顧問咨詢組織成員 ? 變動管理經(jīng)理 – 兼任主席 ? 服務水平經(jīng)理 ? 應用程序經(jīng)理 ? 資深 /高級業(yè)務代表 ? 財務經(jīng)理 ? 軟件控制與發(fā)放經(jīng)理 ? 問題處理經(jīng)理 ? 其他需要參與的人員 質量及服務管理 Jim Zheng/ 鄭澤旗 變動顧問咨詢組織 ? 名稱并不一定 ,可以是變動董事會等類似稱呼 ? 應該定期或不定期舉行正式或非正式的會議 – 不超過 20天應該舉行一次 – 也可一周舉行幾次會議 ? 一些成員應該定期參加會議 ,另外一些可以只在有需要的時候參加 ? 在考慮變動的影響的時候 ,應該問“如果不執(zhí)行這個變動會有什么結果” – 對成本高昂 ,影響甚微的變動 ,不執(zhí)行該變動有時候往往是最好的決定 質量及服務管理 Jim Zheng/ 鄭澤旗 變動管理的基本知識 ? 目標 – 只執(zhí)行已獲批準的變動 ,最低的風險和成本 ? 變動申請 – 對所有 IT相關的部分都應當采用 ? 任務 – 管理變動申請 ,批準變動并安排時間表 ,審核變動的建立 ,測試和實施 ,生意支持 ? 變動顧問咨詢組織 /IT執(zhí)行委員會 – 成員 – 顧問角色 – 評估變動的影響 ,緊急程度和所需資源 – 緊急變動 ? 緊急程度 /優(yōu)先級 : 緊急 ,高級 ,中級 ,低級 ? 影響級別 : 沒有影響 …… 影響巨大 ? 撤銷 ? 在變動處理流程的最后一定要對變動進行回顧 質量及服務管理 Jim Zheng/ 鄭澤旗 變動管理的經(jīng)驗 ? 與軟件的控制和發(fā)放相結合 ? 把流程和對流程的管理分開 ? 盡可能獨立于日常行政級別地確立對流程的負責人 ? 良好地計劃緊急變動而非依賴于一般的變動流程來實現(xiàn)緊急變動 質量及服務管理 Jim Zheng/ 鄭澤旗 變動管理對生意的好處 ? 盡量減少變動對生意的影響 ? 更好地預計所提議的變動的成本 ? 通過打包升級的方法減少零碎的變動次數(shù) ? 減少失敗的變動 ? 更好的就變動與客戶進行溝通 ? 獲得有價值的管理信息 ? 提高客戶和 IT人員的工作效率 ? 提高吸取更高級別的無錯誤變動經(jīng)驗的能力 質量及服務管理 Jim Zheng/ 鄭澤旗 變動管理的常見障礙 ? 跟蹤整個變動的過程 ,文檔工作過于煩瑣 ? 試圖繞過已定流程實施變動 ? 有外部供應商介入 ? 對流程紀律的接受程度 ? 對戰(zhàn)略性權宜方法的過度煩瑣規(guī)定 ? 過度熱心導致分析偏執(zhí) 質量及服務管理 Jim Zheng/ 鄭澤旗 問題與解答 質量及服務管理 Jim Zheng/ 鄭澤旗 軟件控制與發(fā)放 Software Control Distribution 質量及服務管理 Jim Zheng/ 鄭澤旗 軟件控制與發(fā)放的目標 ? 不僅僅是對軟件的應用 ? 保護所有軟件及其相關內(nèi)容 – 包括操作系統(tǒng)軟件 ,中間軟件 ,基礎設施和應用軟件 – 也可能包括啟動文檔甚至軟硬件結合部分 ? 確保只使用已經(jīng)測試的 ,正確的授權軟件 – 有賴于與變動管理的嚴格結合 – 過去 ,現(xiàn)在和計劃中的 ? 正確的軟件 ,正確的時間 ,正確的地點 質量及服務管理 Jim Zheng/ 鄭澤旗 軟件控制與發(fā)放的任務 ? 確定軟件發(fā)放政策 ? 控制權威軟件中心 (Definitive Software Library, DSL) – 只有已經(jīng)確認授權的軟件可以放進 DSL – 放在 DSL中的軟件必須嚴格保護直至撤出 ? 發(fā)放軟件及相關說明 ? 執(zhí)行軟件檢查 – 軟件的發(fā)放和實施必須檢查回顧以確保正確的流程得以嚴格執(zhí)行 ,對這些流程的任何變動得以更正 ? 控制軟件發(fā)放 ? 監(jiān)督軟件發(fā)放版本的工作完成 質量及服務管理 Jim Zheng/ 鄭澤旗 權威軟件中心 (DSL) ? 權威軟件中心是保存在安全位置的軟件配置內(nèi)容和存檔信息 – 可以是電子媒體的保存 (如磁帶 ,光盤 ,軟盤等 ) ? 權威軟件中心是一個邏輯中心 – 邏輯上只有一個軟件 (版本 )實體存在 – 物理上可以有很多軟件復制品 ? 軟件權威中心負責 – 軟件的物理保存 – 軟件的物理發(fā)放 – 軟件的邏輯保存 – 軟件的質量檢查 (病毒 /版權 /測試 /完成 ) – 軟件發(fā)放版本的建設 質量及服務管理 Jim Zheng/ 鄭澤旗 發(fā)放流程 ? 權威軟件中心的環(huán)境應該與外部相獨立 – 與可控制的移植路徑相獨立 – 與所有發(fā)放版本的檢查跟蹤和撤銷相獨立 ? 存檔環(huán)境應該看作權威軟件中心的一個子環(huán)境 ,其環(huán)境要求與權威軟件中心相一致 ? 如果在測試中發(fā)現(xiàn)不可接受的錯誤并進行了相應的變動 ,軟件版本必須遞增 ? 所有的工作都應該在遵從變動管理的前提下完成 質量及服務管理 Jim Zheng/ 鄭澤旗 軟件的發(fā)放版本 ? 軟件發(fā)放版本的內(nèi)容 – 發(fā)放版本號 ? 軟件的發(fā)放版本號可以保證每一個發(fā)放版本通過分配版本號來確保其可識別性 – 發(fā)放單位 ? 發(fā)放單位 : 通常情況下給定類型軟件的發(fā)放級別 ,如全套軟件 ,某一模塊或某一應用程序 – 發(fā)放頻率 ? 應該有一個廣為人知的 ,可預期的發(fā)放頻率及廣泛同意的內(nèi)容變動限度 – 決定因素應該是業(yè)務的需要而非技術的方便性 – 發(fā)放版本的版本要求應該事先確定以保證有足夠的測試時間 – 緊急變動 ? 緊急的變動要遵從緊急變動流程 ,相應的應該有一個軟件的緊急控制和發(fā)放流程 – 完全 /打包 /DELTA發(fā)放版本 ? 完全發(fā)放版本 : 用來替換某一已經(jīng)發(fā)放版本的全部內(nèi)容的發(fā)放版本 ,無論其內(nèi)容是否已全部更改 ? DELTA發(fā)放版本 : 只包括已經(jīng)更改內(nèi)容的發(fā)放版本 ? 打包發(fā)放版本 : 包括測試當中涉及到的所有相關軟件 ,如電腦環(huán)境包括電子郵件 ,模擬器 ,OFFICE及操作系統(tǒng)等 質量及服務管理 Jim Zheng/ 鄭澤