Rookie's IT&BP Management

IT委外合約相對於有實體物品之合約多了許多風險，標的物為客製化之無形軟體，因為每個人的使用習慣不同、認知不同很難以質或量來驗收，若有爭議時也很難評斷誰對誰錯，為了未雨綢繆或許在訂定合約時可以多加注意，筆者有以下經驗分享。

甲方(委託人、買方)可留意之事項:

      在探討行銷學中的STP時，其中Positioning 市場定位，啟發我過去幾年一直嘗試解決同仁工作量分配不均的靈感，組織內部同仁之個人特質與能力可以與目標業務之特性進行定位，例如將個人能力與特性分成五項10級分: 程式設計能力、資料庫能力、邏輯分析能力、溝通能力與團隊合作意願，同時也將目標業務分成五項10級分:複雜度、異動性、關鍵性、難纏度與整合性，由同仁自行評估或互相評出自己的五項特性，再透過共議決決定目標業務的五項特性，此時將會產生多種雷達圖(如100個目標業務，依照圖形相似度平均分成10組)，將目標業務進行圖形分類後，一定可以找到相同走勢的雷達圖在某個同仁身上而進行配對(如10個同仁每人分1組目標業務)。

     2006年11月是我在美國的最後一年，趁著老婆待產與空閒時間把ITIL Foundation徹底的瞭解了一下，就地在LA 就報名了ITIL Foundation certification的考試，也很順利通過了考試，今年找個時間再把ISO 20000考掉吧。 

    在前一篇文章中已經簡單的介紹了ITIL V2的Service Delivery 的5個管理部分，接下來我將接著介紹Service Support所提到的5個管理流程與服務櫃台的運作，在Service Support中共包含了事件管理、問題管理、異動管理、結構(組態)管理及發布管理5項管理規範。

Service Support Funcation

    ITIL是IT Infrastructure Library的縮寫，可翻譯成資訊技術基礎架構庫，是在1980中期由英國政府電腦暨電信局(CCTA)受委託發起，現已納入英國政府商務辦公室 OGC–the Office of Government Commerce）開發，用於規範IT服務管理的架構，提倡資源利用之最佳化、提昇資訊服務水準，許多跨國各大資訊廠商(如IBM、HP、Microsoft、CA等)也都參與並實踐其理想，ITIL所包含的內容非常完整，最初是由40本左右的手冊所構成，1990中期OGC為因應產業變更，並增加其閱讀性與實用性，重新規劃後產出ITIL Version 2.0（以下簡稱為ITIL V2），核心在於描述Service Delivery及Service Support。到了2007年OGC為了因應快速發展變化的IT服務管理市場，推出最新的ITIL Version 3.0（以下簡稱為ITIL V3），以符合市場的實際需求。ITIL V3與V2的主要差別，在於引進服務生命週期（Service Life Cycle）模型，並修正了部分有關management 跟 processes的描述。

   因筆者主要熟悉 ITIL V2，以下就針對ITIL V2所描述之Service Delivery及Service Support的10項管理流程跟Service Desk做簡單的描述。

    RFP在IT專案中是相當平凡的一個名詞也是相當重要的一份文件，它代表了導入方向賣方以文件方式提出需求，這個需求包含了專案所需的軟體、硬體、需求、預算、時程等說明，這份RFP通常也會伴隨合約成為合約的一部分。在ISO 20000(另一文章介紹) Part1第5節Service Delivery Processes-Service level management中也有提到The full range of services shall be agreed and documented. Each service to be delivered shall be recorded in an SLA(Service Level Agreements) together with the corresponding targets. 很明白的描繪出所有的服務需求必須被文件化，每一項服務的達到必須被記錄在服務文件中，與RFP所描述有異曲同工之妙，未來再專案的執行上有任何的爭端，都需要以RFP作為解釋的基礎 。

    RFP的撰寫範例再網路上很容易都搜尋的到，每人寫法也會有所不同但是目標與方向均大同小異，我僅針對我接觸的專案介紹簡單的章節與範例。

   專案開發流程與軟體生命週期已經廣泛的運用在現階段IT專案管理上面，一般都是以最基本的瀑布式模型為主軸各自發揮加以改良。瀑布式的專案模式我們也可以稱為階梯式模式，差別只在於是要由上往下走還是由下向上走。專案開發的成功與否，除了工作團隊基本能力與分工外，對使用者的資訊能力也需要有一定的了解，當使用者提出「怎麼跟我當初想的不一樣」或是「我當初的意思不是這樣」時，只會有兩種可能，一種是使用者有很明確的需求但是系統分析師分析錯誤，而另一種比較容易被大家所忽略的就是系統分析師沒有細心了解使用者的資訊能力與使用行為，反而是用系統分析師自己本身的觀點下去分析。

   在ISO 20000(另一文章介紹) Part1第7節Relationship Processes-Business relationship management的objective 中明白描述 To establish and maintain a good relationship between the service provider and the customer based on understanding the customer and their business drivers，為建立及維持服務供應商與使用者良好的關係必須清楚明白使用者的行為跟他的業務行為，關鍵即為customer and their business drivers不單單只是business drivers，然再一般的專案開發過程中，系統分析都著重於業務需求分析，卻時常忽略了使用者本身的行為。

   IT專案的開發除了基本的硬體設備外，80％都會是客製化為客戶量身訂做，所以了解客戶（使用者）的使用行為是非常重要的一環，優秀的系統分析師要有能力在訪談應答之間，了解使用者的資訊能力並加入專案的評估，並適時回報給專案管理員，若將四個指標分開討論，則可推論以下的觀點：

       委外專案開發實務經驗讓我學習到從專案開發前的RFP撰寫、公開招標、廠商駐點、系統開發到最後的專案驗收等流程。在標準化的專案執行層面，除了人員訪談、需求分析、系統分析、系統設計、程式開發、整合測試與系統上線外，在實務執行上我發現其實是不太夠的，我們必須在現在有的標準流程上多納入一個使用者行為分析，這個分析必須要著重在系統使用者的使用型態。往往IT專案的SOP為了有效控管專案進度與開發人力的分配，避免重複開發或是需求不明，都會在人員訪談、需求分析、系統分析上面下許多的功夫，要求使用者再三確認，但是真正上線後能夠讓使用者滿意的卻很有限。一個標準的系統分析師一定是依照使用者的需求畫出系統流程圖與程式規格，但是往往忽略到使用者本身的使用行為而造成日後的異動頻繁。

   一個有效的專案管理除了遵循標準的專案執行週期外，必須多考慮到使用者的行為分析，除了基本的使用者人數分析外，我們必須要多增加幾個重要的變數就是使用者的電腦素養、使用者意願、使用者誘因及使用者習慣。大型專案計畫的評估大部分都著重在成本評估、人員評估、時程評估與風險管理，但是這些評估都是以專案開發單方面角度來看，而忘記用最重要的一群也就是未來系統使用者的角度來看。使用者在訪談階段洋洋灑灑所說的需求，雖然有完整的確認流程，但是正式上線呈現後，往往比不上一句「怎麼跟我當初想的不一樣」，其實這是很正常的反應，因為「改變」總是困難的，要讓使用者跳脫原本的使用習慣更是難上加難。如何減少使用者說出「怎麼跟我當初想的不一樣」，就成了決定專案開發成功與否的重要關鍵。