关于ITIL在金融危机中对IT治理的指导意义，我们其实有三个论题需要去思考的：第一方面是金融危机对我们目前IT组织的影响，第二方面是IT管理与IT治理之间的区别，第三方面则是IT服务管理中重要的方法论ITIL中有哪些关键因素是能为减缓当前金融危机产生影响所采用的方法。 关于金融危机对世界的影响，大家是谈虎色变，但具体到底影响到什么程度，则众说纷纭。至于具体到IT组织的影响，更难严格定义。我们手中有一份来自Gartner的报告，在这份报告中指出IT服务提供商面临着重要的选择，即：是等到经济形式有所好转再行动还是现在立刻采取行动？当然，立刻采取行动是无法预料结果的，错误的选择对业务乃至组织的生存都有极大的影响。
对此，Gartner建议：“将现阶段形势视为可能无限期延长的趋势”。
当然，无论是Gartner还是任何ITSP（ITServiceProvider），并不可能因此放弃决策而听之任之。Gartner认为，在机遇的地方，ITSP依然可以通过灵活的方式与能力的管理来保持IT服务的提供。为此Gartner提出了十点建议：
- 提供共享风险和成果的价格计划
- 以财务报表的形势表达价值
- 无论产品是什么，都要关注成本优化
- 了解客户的风险环境、风险承受力和风险管理方法
- 快速了解政府目标，并快速制定经济干预计划
- 对提供给客户的服务更新或服务重用真的变得容易
- 当对你的业务和客户产生意义时，快速向效用定价转移
- 减少实施中的痛苦和执行的风险
- 跟上创新和流程改进的趋势
- 开拓市场
提出的建议实际上已经将我们的IT“管理”（ITManagement）上升到了IT“治理”（ITGovernance）的层面。那么IT管理与IT治理是否有区别呢？严格的讲还是有的。IT管理相对来说注重企业的信息管理、信息系统运营以及对于实现IT目标所采用的战略与设计及转换等。而IT治理指的是管理最高层（往往是董事会）用于监督管理层在IT战略上的过程与结构，从宏观上把控IT投资与运营的正确方向。
从这点来看，对于金融危机这样一个全球性的，影响面极大的事件来说，将对IT的直接运营管理上升到对企业战略性的IT治理还是很有必要的。
那么对于ITIL（ITInfrastructureLibrary）这样一个用于IT服务的最佳实践框架，是否具备对IT治理的指导意义呢。确切地讲，ITIL的方法论是具有较强的指导意义的，并且有些文献把ITIL也作为IT治理的体系中的理论来考虑。
那么ITIL的哪些流程对IT治理的指导相对直接并可能产生直接的成果呢？严格的讲，将ITIL的流程分别对待去考虑对IT治理的整体性影响并非最科学的。但是对于某些企业或IT组织来说，可能在金融危机的现状下迫切解决一些当前问题或改善现状。那么通过部分流程入手也是一种可取的方案。如果在ITILV2的流程体系中，我们建议变更管理（ChangeManagement）、容量管理（CapacityManagement）要逐步被考虑进IT治理的范畴。
那么为什么我们不将IT财务管理（ITFinancialManagement）与服务级别管理（ServiceLevelManagement）考虑进来呢？其实如果一个IT组织能实施IT财务管理与服务级别管理对IT治理有很大的指导意义，但这两个流程的实施往往需要组织消耗大量的人力物力与时间，对于金融危机这个破坏力极强的怪兽来说，我们的重点是“守”而非“攻”，与其在不明状况的情况下去过于主动地扩大影响面乃至过度投资，无疑是风险的扩张。
实际上变更管理与容量管理意味着阶段性控制与范围性设计。
变更管理中，我们强调的是三个方面：CAB（变更管理委员会）的建立、变更模型（ChangeModel）的建立、紧急变更的比例控制。
CAB：建立一个变更管理委员会，是对所有的非标准变更进行一个评审的委员会。CAB并非一个常驻团队，更多的是一种概念化组织，对于不同的变更完全可能由变更经理（ChangeManager）邀请不同的人加入到CAB当中。从流程来说，可能有问题经理、发布经理加入，从岗位上来说，则从CIO到ServiceDesk也都有可能被邀请加入。所以，设立CAB并非行政上做调度，重要的是建立这样一个变更机制，对需要变更的部分包括对变更的风险、成本、影响范围做全面的控制。在金融危机的侵蚀中，我们尤其要注意在变更管理里的回滚计划，没有回滚计划的变更所隐蕴的风险是难以预计的！
ChangeModel：建立并归类变更，形成变更模型，是量化变更并提升增加变更效率的重要方法。我在给IBM的学员做培训的时候，观察到他们欧洲部的IT变更部门采用的是“答卷式”的方式，巧妙地将变更模型做成易判断的问题列表，这些问题列表针对的则是提交的变更请求（RFC）如：是否包含了回滚计划？影响用户数多少？同类变更历史成功数？服务级别？……借助多维度的判断可以得出有利的变更依据，并安排出变更日程。
紧急变更的比例控制：为了不僵化变更思想，变更管理建立设立（ECABorCAB/EC）紧急变更委员会，当一部分紧急的变更需要审批与实施的时候，我们可以暂时跳过一些进程而快速进行变更流程，这需要ECAB审批与规划。但是，我们并不提倡紧急变更在所有变更中的比例过高，实际上，如果紧急变更比例过高的话，往往意味着我们在设立紧急变更的尺度过宽，这样的结果会造成变更对风险的把控不严格，增加不确定性的风险。按照IDC（国际数据中心）的数据提供，比较优秀的IT组织的紧急变更比例能控制在千分之五。
变更管理通过对变更风险的控制加强了IT治理的力度，而容量管理则通过IT组件与资源与客户需求的平衡做好IT能力的规划。优秀的容量管理中包含了“削峰填谷”的概念，在ITILV3中还可以将需求管理（DemandManagement）结合思考，采用ServiceLevelPackage的方式建立一个IT组织与客户之间双赢的桥梁。
在不少IT组织中，容量管理总是处于一个可做可不做的境地。我在一个某保险公司的咨询项目中，他们的ITManager非常无奈地说，他们无法做容量管理，比如说他们当年IT的投资总共不过1180万，这里包括他们整个亚太地区的软硬件投资与部分人员成本，有一套中央服务器，价值大约40万。早就知道这台服务器会出问题，下面的人员也提过多次，但是预算就是不够，只好等到坏到不能用了再说。
实际上，容量管理并非就是提供冗余那么简单，我觉得“服务器等到坏到不能用再说”并非就不合理，我们要分析，对业务产生影响的故障有两类状况。第一类状况是一旦发生了故障，就将造成极大的业务影响，尽管随着时间的推移这个影响的增幅不大；另一类情况是发生故障后，业务初期影响不大，但随着时间推移业务影响会逐渐增大。
对于第一类情况，我们要注重预防，而对于第二类情况，我们则可以选择事后修复。在ITIL的可持续性管理（ServiceContinuityManagement）中也有过这类思想的体现。也因此我们可以感受到，在金融危机大家感觉到前途难以预料并且成本需要急剧缩减的情况下，我们需要做的是合理安排成本而并非单方面减少成本，在没有经过对客户需求了解并管理的成本缩减往往可能因造成客户满意度的下降而引起更大的“服务危机”！
ITIL并非仅仅流程管理，对于人员与工具的采用均为ITIL所关注，在ITIL最佳实践的框架中，我们如果能系统地对之进行深入的剖析和了解，会发现大量的方法论值得我们去探索。对于金融危机这样一个特殊的环境下，我们对IT组织的价值能正确认识并加以引导对IT治理来说是至关重要，也预祝我们的企业及相关IT组织能谨慎当前的诸般行为，早日走出危机的阴影！
|
转播
分享
淘帖
()
