模板
教程
环境
性能
功能
管理
实战：长期的IT外包合同如何实施与执行
我的team为客户公司各种信息系统提供技术支持，是大IT外包合同下的一个维护项目，负责客户business中的Europe和Asia区。客户的US business不在我team的support scope内，但有时候需要与US的一些team打交道。这里US port就不予仔细考虑。
由于客户把IT外包给我们，客户方就不用招聘很多的IT人员，大部分的工作依照外包合同都由外包服务提供者来完成(我们公司并不是客户唯一的外包商，某些方面的服务还外包给了其他专业公司，如HelpDesk的工作和服务器维护就外包给了HP——HP的HelpDesk非常不错，而且服务器就是HP服务器^_^)。因此，绝大多数客户方的IT人员都是外包合同的执行参与者与项目管理者。客户对自己的IT部门人员所进行的培训除了必要的business培训，就是leadership的培训。
客户是一家全球500强企业，Business非常多，客户的IT工作量也非常大。那么客户如何与外包商合作、沟通、实施这么大的外包合同呢?这就有必要提到外包商的customer relationship management team。 这个team和客户的management team密切合作，交换意见，共同研究合同的实施与改进，并致力于与客户关系的建立。因为合同签订的出发点就是双方都能从合同中受益，双方都有责任和义务帮助对方提高Business和收益，要不然，这个长期的合同可能没多久就会被Close。
customer relationship management team经常会和客户一起评估当前的business以及IT的服务情况，做一些必要的变化。这不，去年Europe刚被merge into Asia的管理team，才一年的时间，由于这一年客户Business的变化，Europe的Business变的重要起来，今年就又要 seperate出去，成立独立的management team，方便更好地support Business。
客户和BRM(Business relationship manager)一起评估project的大小，需要多少resource，然后我们(外包商)就开始project team的招兵买马，作为客户的Contract员工组成客户的IT部门。所谓Contract员工就是人是我们招的，和客户签聘用合同，我们为客户工作，每个resource每小时多少钱客户付给我们公司，我们来进行人员管理，客户只关注项目上的事。(我们有时候叫自己公司为人贩子公司，从另一方面来公司做的是目前时髦的人力猎头工作，只不过人都先招过来了，推荐合适的供客户挑选。呵呵)
客户把整个IT部门分成很多team，各team负责不同的工作，彼此间又相互支持。除了与程序直接打交道的各种Business team外，其中IT部门的HelpDesk team、Database workgroup、CTO team、Common application team和Ops team与我们team联系最密切。前面几个team一看就知道他们做什么的，我稍微解释一下Common application team和Ops team做什么。
Common application team顾名思义就是负责一些Common applications的，比如客户要求所有程序都是SSO(Single Sign On) enable的，这就需要有个系统能实现SSO的需求，保证程序的访问安全，并统一利用公司的员工信息库，保证信息的一致，防止各系统“各自为政”，减少重复工作。客户是使用的Site Minder作为SSO服务器，那么SSO的配置与维护就是一个Common的工作，这就是Common application team要做的事。当然，还有很多这样的Common application。
Ops team一般负责系统的CCM(Change Control Management)中的deploy。如果系统做了改动，在客户同意执行change后，Ops team就会执行这次change。
除了以上这些team，IT部门还有Data Warehouse team，ERP team等其他team，虽然与他们也打交道，但由于不是经常性的，这里就不专门介绍。
好了，那么我们到底如何来support Business的呢?
所有的team如何执行自己的职责在project的小合同中都有说明。其中如何处理客户的issue与需求，哪些事情是哪个team的scope都在 escalation chart中明确定义了的，然后让HelpDesk拿着这些escalation chart来处理。HelpDesk是在做IT系统维护时各个IT support team与Business之间唯一的联系点(SPOC - Single point of Contact)。当然，这是理想状态，也有Business用户直接联系我们的。
HelpDesk接到用户escalate的issue后，先自己做初步的分析，如果HelpDesk能自己解决，问题就不会再往下传递了;如果是 Business方面的问题，用户把问题发到用户的队列中，并跟踪问题什么时候关闭;如果是我们系统技术方面的问题或Bug，HelpDesk就按照前面定义的escalation chart，把问题dispatch到我们team的队列中;如果是其他team的范围也同样的process。因为所有的程序在交给我们team(或其他team)之前就定义了程序的信息，专门有team来维护所有程序的信息。根据客户对所有Business的评估，把相应的程序分为不同的重要程度，这样所有的问题也都根据对Business的影响程度定义了几种不同的紧急程度，再定义了每种紧急程度的问题需要在规定的时间内解决。用户定义了一些 metrics用来度量我们服务的质量，并规定了可需要达到的值。这些都在project的合同中定义，双方签字同意。这就是传说中的SLA (Service Level Agreement)^_^。相应地，我们也在我们公司(外包商)的project Plan中阐述客户的metrics，让所有member都知道并执行，保证meet客户的SLA。
当问题被dispatch到我们的队列中后，我们就需要在SLA规定的时间内解决问题。每周，专门的Monitor team会从工具中run出各个team这周服务的report，查看是否meet SLA。甚至那些对Business非常重要的系统每天就有report，然后report给management team。这也是客户对我们考核的一个重要指标。
由于我们中国的team要support客户Europe和Asia的系统，欧洲客户与中国有6个小时时差，这要求我们的team有灵活的上班安排，来 meet客户的Business时间。我们把team分成2部分，一部分support欧洲程序，一部分support亚洲程序。由于我们公司在中国只是一个分公司，印度还有team，印度和中国也有2个小时时差，所以我们安排中国team上 下午班，这样下班不用太晚;印度team同样上 下午班，但他们和欧洲只有4个小时时差，这样就可以更好地meet客户的Business时间。
当然有US的程序，上班时间又有些不同。在其他时间team的member提供On Call support。所谓On Call Support就是说在这段时间内，如果我们support的系统有问题，用户或HelpDesk可以Call我们的工作Cell Phone，我们就可以马上登陆到内部工作环境，开始移动办公。
