公司與客戶簽訂的是一個長期的IT外包大合同，包括軟件，硬件，服務(wù)等等。從另外一個角度來說，包括開發(fā)，維護(hù)，BI等等。這么大的合同客戶與外包商是如何實施與執(zhí)行的？如何保證客戶的Business一如既往地運行，并且還更好地受益于IT的外包呢？我試著從我的team角度，以及從我所能得到的信息盡量來理解這個大的合同是如何實施與執(zhí)行的。盡管這只是對這個IT外包大合同管中窺豹，但我希望我的文字也能讓更多的人認(rèn)識一個外包案例，也希望能和此案例有興趣的做IT外包的方方面面的專家和公司探討。 
    我的team為客戶公司各種信息系統(tǒng)提供技術(shù)支持，是大IT外包合同下的一個維護(hù)項目，負(fù)責(zé)客戶business中的Europe和Asia區(qū)。客戶的 US business不在我team的support scope內(nèi)，但有時候需要與US的一些team打交道。這里US port就不予仔細(xì)考慮。 
    由于客戶把IT外包給我們，客戶方就不用招聘很多的IT人員，大部分的工作依照外包合同都由外包服務(wù)提供者來完成（我們公司并不是客戶唯一的外包商，某些方面的服務(wù)還外包給了其他專業(yè)公司，如HelpDesk的工作和服務(wù)器維護(hù)就外包給了HP -- HP的HelpDesk非常不錯，而且服務(wù)器就是HP服務(wù)器^_^）。因此，絕大多數(shù)客戶方的IT人員都是外包合同的執(zhí)行參與者與項目管理者?？蛻魧ψ约旱腎T部門人員所進(jìn)行的培訓(xùn)除了必要的business培訓(xùn)，就是leadership的培訓(xùn)。 
    客戶是一家全球500強企業(yè)，Business 非常多，客戶的IT工作量也非常大。那么客戶如何與外包商合作、溝通、實施這么大的外包合同呢？這就有必要提到外包商的customer relationship management team。 這個team和客戶的management team密切合作，交換意見，共同研究合同的實施與改進(jìn)，并致力于與客戶關(guān)系的建立。因為合同簽訂的出發(fā)點就是雙方都能從合同中受益，雙方都有責(zé)任和義務(wù)幫助對方提高Business和收益，要不然，這個長期的合同可能沒多久就會被Close。 
    customer relationship management team經(jīng)常會和客戶一起評估當(dāng)前的business以及IT的服務(wù)情況，做一些必要的變化。這不，去年Europe剛被merge into Asia的管理team，才一年的時間，由于這一年客戶Business的變化，Europe的Business變的重要起來，今年就又要 seperate出去，成立獨立的management team，方便更好地support Business。 
    客戶和BRM（Business relationship manager）一起評估project的大小，需要多少resource，然后我們（外包商）就開始project team的招兵買馬，作為客戶的Contract員工組成客戶的IT部門。所謂Contract員工就是人是我們招的，和客戶簽聘用合同，我們?yōu)榭蛻艄ぷ?，每個resource每小時多少錢客戶付給我們公司，我們來進(jìn)行人員管理，客戶只關(guān)注項目上的事。（我們有時候叫自己公司為人販子公司，從另一方面來公司做的是目前時髦的人力獵頭工作，只不過人都先招過來了，推薦合適的供客戶挑選。呵呵） 
    客戶把整個IT部門分成很多team，各team負(fù)責(zé)不同的工作，彼此間又相互支持。除了與程序直接打交道的各種Business team外，其中IT部門的HelpDesk team、Database workgroup、CTO team、Common application team和Ops team與我們team聯(lián)系最密切。前面幾個team一看就知道他們做什么的，我稍微解釋一下Common application team和Ops team做什么。 
    Common application team顧名思義就是負(fù)責(zé)一些Common applications的，比如客戶要求所有程序都是SSO（Single Sign On） enable的，這就需要有個系統(tǒng)能實現(xiàn)SSO的需求，保證程序的訪問安全，并統(tǒng)一利用公司的員工信息庫，保證信息的一致，防止各系統(tǒng)“各自為政”，減少重復(fù)工作?？蛻羰鞘褂玫腟ite Minder作為SSO服務(wù)器，那么SSO的配置與維護(hù)就是一個Common的工作，這就是Common application team要做的事。當(dāng)然，還有很多這樣的Common application。 
    Ops team一般負(fù)責(zé)系統(tǒng)的CCM（Change Control Management）中的deploy。如果系統(tǒng)做了改動，在客戶同意執(zhí)行change后，Ops team就會執(zhí)行這次change。 
    除了以上這些team，IT部門還有Data Warehouse team，ERP team等其他team，雖然與他們也打交道，但由于不是經(jīng)常性的，這里就不專門介紹。 
    好了，那么我們到底如何來support Business的呢？ 
    所有的team如何執(zhí)行自己的職責(zé)在project的小合同中都有說明。其中如何處理客戶的issue與需求，哪些事情是哪個team的scope都在 escalation chart中明確定義了的，然后讓HelpDesk拿著這些escalation chart來處理。HelpDesk是在做IT系統(tǒng)維護(hù)時各個IT support team與Business之間唯一的聯(lián)系點（SPOC - Single point of Contact）。當(dāng)然，這是理想狀態(tài)，也有Business用戶直接聯(lián)系我們的。 
    HelpDesk接到用戶escalate的issue后，先自己做初步的分析，如果HelpDesk能自己解決，問題就不會再往下傳遞了；如果是 Business方面的問題，用戶把問題發(fā)到用戶的隊列中，并跟蹤問題什么時候關(guān)閉；如果是我們系統(tǒng)技術(shù)方面的問題或Bug，HelpDesk就按照前面定義的escalation chart，把問題dispatch到我們team的隊列中；如果是其他team的范圍也同樣的process。因為所有的程序在交給我們team（或其他team）之前就定義了程序的信息，專門有team來維護(hù)所有程序的信息。根據(jù)客戶對所有Business的評估，把相應(yīng)的程序分為不同的重要程度，這樣所有的問題也都根據(jù)對Business的影響程度定義了幾種不同的緊急程度，再定義了每種緊急程度的問題需要在規(guī)定的時間內(nèi)解決。用戶定義了一些 metrics用來度量我們服務(wù)的質(zhì)量，并規(guī)定了可需要達(dá)到的值。這些都在project的合同中定義，雙方簽字同意。這就是傳說中的SLA （Service Level Agreement）^_^。相應(yīng)地，我們也在我們公司（外包商）的project Plan中闡述客戶的metrics，讓所有member都知道并執(zhí)行，保證meet客戶的SLA。 
    當(dāng)問題被dispatch到我們的隊列中后，我們就需要在SLA規(guī)定的時間內(nèi)解決問題。每周，專門的Monitor team會從工具中run出各個team這周服務(wù)的report，查看是否meet SLA。甚至那些對Business非常重要的系統(tǒng)每天就有report，然后report給management team。這也是客戶對我們考核的一個重要指標(biāo)。 
    由于我們中國的team要support客戶Europe和Asia的系統(tǒng)，歐洲客戶與中國有6個小時時差，這要求我們的team有靈活的上班安排，來 meet客戶的Business時間。我們把team分成2部分，一部分support歐洲程序，一部分support亞洲程序。由于我們公司在中國只是一個分公司，印度還有team，印度和中國也有2個小時時差，所以我們安排中國team上 下午班，這樣下班不用太晚；印度team同樣上 下午班，但他們和歐洲只有4個小時時差，這樣就可以更好地meet客戶的Business時間。 
    當(dāng)然有US的程序，上班時間又有些不同。在其他時間team的member提供On Call support。所謂On Call Support就是說在這段時間內(nèi)，如果我們support的系統(tǒng)有問題，用戶或HelpDesk可以Call我們的工作Cell Phone，我們就可以馬上登陸到內(nèi)部工作環(huán)境，開始移動辦公。 
    這個項目還有很多可以說的，限于篇幅，這里也就草草收尾（也說了一大堆廢話了）。如果這篇文章有很多人有興趣，希望了解更多，我也可以接下來再寫一些文字。有興趣的朋友也可以聯(lián)系我，大家offline探討。