, x& a. b2 A, M$ ^' o7 H' X1 J( jIT服务可以分为三大类：IT开发提供的应用程序开发服务，IT运维提供的运维管理服务和IT数据分析提供的数据分析服务。从IT的角度来看，这些服务分别定位在信息系统的开发、运维和应用（数据分析是特殊的由IT部门主导的应用），对IT而言，其中的数据分析服务又可以归结为开发和运维服务。因此，IT服务最终可以归结为开发和运维服务。 - _* V8 \- x: d8 o: R
) q% j" W- u4 N
要找到IT服务和成本之间的关系，要找到IT投入和相应产出（服务）之间的关系，实施IT服务的“服务水平协议”管理势在必行。 ' j5 V I& ?& u) F8 G& A ; L8 w# }0 ~% E6 j, l, \IT服务水平协议主要包括开发和运维服务水平协议。从IT自身的管理上来说，对已有项目应当逐步评估维持服务水平现状的成本以及进一步拓展业务的成本，对新项目来说应当从项目立项的开始就根据项目要求的服务水平分别计算其开发和运维成本，最终过渡到全面服务水平管理。 3 F, ]/ p: [7 o2 V0 x6 o* d
[3 p# f/ X! W: Z' l) U3 N1 F( U
由于开发服务只是在信息系统的定制开发阶段起作用，在信息系统的生命周期里只占一小部分。根据IDC有关世界范围内IT投入的数据统计，IT投入中直接与开发相关的部分只占总额的约5%。因此，无论是从需求部门覆盖面还是从IT投入比例上来说，运维服务的比重都远远大于开发服务。从这个意义上来说，运维服务水平协议是IT服务水平协议的主体，和IT投入的效率以及需求部门的直接感受密切相关。* H5 g) }! s8 F2 s/ H4 q: g0 C4 O
! j, W3 _ o* v用个不太恰当的比方来说，假如IT部门是一只足球队，那么研发就是前锋，平时开发得再烂，只要关键时刻能冲得上去，能够有新的东西出来，“引领业务的发展”或者“形成企业核心竞争力”，都可以既往不咎；反之，运维就是守门员，即使平时工作做得再好，89分钟滴水不漏，一旦在90分钟掉了链子，一切功劳都被抹杀不说，反过来还要追究责任。1 f. v P- N4 }% x' E$ f! I! ?. J p
: H, D* [+ a& J8 Y; @0 E
在当今时代，IT和业务的融合是与时俱进，越来越深。尤其是在总部，恨不得每个部门都想有自己的IT队伍，而IT会说，要你们那么多部门干什么？我这里一条龙全部搞定。这种争论，最后能有个结果吗？最多是矩阵式管理，IT派驻需求管理员到各个部门，或者各个部门派驻人员到IT，其实并没有解决实质性的问题。在这里，组织架构并不是最重要的，恰当划分IT和业务的界限，明确服务水平协议才是解决问题的关键。 J x! G6 W* `. b- V 3 l' N1 P' E u. l& g+ ]对IT来说，则要理清自己的基本盘和争取对象。满足业务需求，保证系统正常运转是基本盘；引领业务发展，构建创新模式是争取对象。基本盘没稳定住，再引领业务发展也会有连本带利还清的一天。而要稳定基本盘，就得算清帐。如果永远是预算和需求两条路，无法对接，IT黑洞就会永远存在。公司发展得好，不在乎IT那点钱，那你就没事；要跟你算账了，那肯定到处都是事。: A. _. A4 f2 Y1 i' p
; t$ p0 j0 l- Z1 \6 z5 E, @/ b
或者还是拿服务水平来说，两个极端不会有问题。一种是银行，业务万万停不得，这个就好办，要多少领导就得给多少，哪个领导也不会不开眼承担这种责任；或者是业务本来就无所谓，停就停了吧，还有别的办法，那领导就是不给钱，也是可以的。怕就怕的是中间层，你说万万停不得吧也还不是，停个几个小时半天也不是真的就不行，但停多了业务也不干。分预算时砍你一半你也没话说，过了半年领导说我们要的是7*24，你IT为什么不能保证？像这样的，你不在分预算时把服务水平对应起来，后面绝对死定了。