最近因为某些原因写了一些东西，发到这里。
 
由于信息技术在组织中应用的范围趋于广泛，应用程度趋于深入，组织对于 IT 服务的依赖程度相应的持续提高，对于服务质量的要求也不断的提高，但是考虑到信息技术本身以及信息产业的极大发展， IT 服务本身的复杂度也有了巨大的提升，这就形成了一对矛盾。传统的解决方法是养一些技术上全能的员工，出了什么问题都能解决，但是这样的方式也存在很大的问题，首先存在比较大的风险，如果这样的资源进入不可用的状态，例如离职或者假期，那么组织的业务就存在因为 IT 服务的故障而遭受巨大冲击的风险；其次，拥有成本高，全能的员工需要大量的成本来培养以及挽留；第三，替代成本高，如果这样的员工流失，寻求其替代者将是非常困难并且昂贵的；其他的一些问题不多讨论。典型的现代解决方法是收集所有可能的信息，包括环境、硬件、软件、人员等等的信息，识别出其中各个要素对于 IT 服务的影响及影响程度，以及要素本身的变动程度等信息，通过系统的方法论，以流程的形式，对于各要素进行管理与控制，以期在合理的成本下达到符合用户要求的 IT 服务水准。有关的基本要素（不包括人员要素，因其不具备普适性）以及方法论、流程等的集合，就是 ITIL ，而在 ITIL 基础上构建的对于 IT 服务的管理体系以及实践，则是 ITSM 。
ITIL/ITSM 的基本思想可以在全面质量管理（ TQM ）中找到其源头，因此实际上可以认为 ITIL 与同样脱胎自 TQM 的 6 西格玛、 CMM/CMMI 、 ISO9000 等体系有相通之处，或者都是 TQM 在不同领域内的投影。
ITIL/ITSM 的实践，基本的原则是通过把 IT 系统的要素与出现的问题结合分析，发现问题的根源，对于其中一部分，通过改变相应的要素，永久性的消除问题，对于另一部分，则通过把解决方法固化并形成相应的知识，保证 IT 服务的提供者可以以较低的成本获得解决问题所必须的信息，这就在一定程度上避免了前面所描述的风险、拥有成本以及替代成本方面的问题。同时，还通过对于有关要素对于问题的影响，来预先控制可能会对 IT 服务出现冲击的行为。
从具体的实践来看，没有组织可以 100% 的按照 ITIL 的指导来构建自身的 IT 服务管理实践，这需要根据组织自身的情况对于 ITIL 进行一定的剪裁，这也体现在不同的厂商基于 ITIL 开发出了不同的 IT 服务管理实践框架，例如 HP 的 IT 服务参考模型， IBM 的 IT 流程模型，微软的运营框架（ MOF ）等，具体的组织也可以根据自身的情况来定义自己的 IT 服务管理架构，但是应注意到的是这一过程应该是一个动态的过程，根据组织自身不断的发展与变化，相应的一些实践也需要进行不断的优化，这也可以参考戴明质量环 PDCA ：计划（ PLAN ） — 执行（ DO ） — 检查（ CHECK ） — 行动（ ACT ），通过持续的改进，可以不断的提高组织的服务水平，而对于影响服务及其质量的要素的掌握，以及流程的规范与标准化，则可以对于服务的成本进行度量以及管理和改进。
这是我对于 ITIL/ITSM 的一些体会，在几年前，我也有机会对于这个领域进行一些探索和实践。对于国内的企业来说，很少有企业能够接受对一个 ITIL/ITSM 项目进行投资，因为大部分企业都把 IT 部门视为一个花钱的部门，如果要投资业务上的 IT 系统还没有太大的问题，如果要投资 IT 部门自己的项目就难以接受了。事实上我当时也处于这样的一个环境下，所以，有关的实践只能是在不增加投资的前提下来进行。
在 ITSM 常规的 11 个部分中，我们主要在配置管理、服务台、事件管理、问题管理、变更管理、发布管理上做了一些工作，在能力管理与可用性管理上有少量工作，对于 IT 服务连续性管理、 IT 服务财务管理以及服务水平管理则安排在后续的工作计划中。
在配置管理方面，主要对公司内部的所有 IT 设备，包括 PC 、笔记本、 PC 服务器、小型机、存储设备、网络设备、安全设备、电源设备、打印 / 输出设备、与 IT 部门有关的空调设备等， IT 环境如网络环境、软件环境等进行了信息的收集与整理，并且汇总管理。收集的信息包括型号、基本的硬件配置、厂商、采购时间、保修时间、所处地点、所有者（或责任人、使用者）、关联项、版本（针对软件）、许可证（针对软件）、维护纪录等等，有关信息的维护由专人负责，产生一个 EXCEL 文件， IT 部门员工都有一份副本，服务器上也保存一份副本，更新时需要同步更新，这部分准备在未来作为 CMDB 的基础；
在服务台方面，我们在公司内部网上发布了一个专门的分机号码作为服务号，有关的服务请求尽量由同一位同事接听，并且要进行记录，对于其他同事接听的服务请求电话，也需要在这位同事处进行记录，我们开发了记录的统一表单格式，对记录进行统一管理，对于服务的请求，可以通过电话解决的都通过电话解决，需要现场服务的，由负责接听电话的同事调派人员去解决，无论通过什么途径解决，都有自行开发的统一服务表单进行记录；
在事件管理和问题管理方面，我们是将这两部分合并执行的，对于一些常见的事件通常是通过电话指导用户动手解决，如果无法解决，再将问题转到二线支持的同事到现场解决，如果无法立即解决的，我们视情况提供一些替代的方式，并且通过供应商等三线力量试图解决，在解决的流程中都有表单记录跟踪，在查明原因并且解决问题后，根据实际情况，将解决方法记录下来，转为已知错误，在部门内部确定支持层级，并共享给所有部门同事了解；
变更管理也是与发布管理结合起来进行的，主要是对于硬件更换组件以及软件的版本发布和升级定义了流程进行管理，同时也对配置文件进行相应的管理；
在能力管理方面，主要的工作在于通过用户报告的情况对于设备或软件资源进行管理，对于出现资源不足的情况时提供必要的设备支持，同时，对于支持人员进行培训以提高服务能力，安排支持人员的工作以确保服务能力被投入到高优先级的事件上，例如， IT 部门有两位同事专门负责二线的服务，同时，另一位同事和我也作为后备支持人员提供服务，平时在安排调休或休假时，保证部门至少有两个可以提供服务的人员，在发生大规模的紧急事件时，全部门的人员都可能被投入到服务中去，而另一方面，我们通过在业务部门中选择一些较年轻并且对电脑比较有兴趣的同事，作为类似 “ 兼职 ” 的服务人员，通过平时对于一些已知错误解决方法的共享和临时的电话支持，可以负担一部分的现场服务；
可用性管理方面的工作主要在于一方面在规划上尽量提供周全的防护，例如对电源等环境因素影响的规避，另一方面则是加强日常的维护与巡检，这样可以把一些可能影响到可用性的问题消除在前期，例如我们有一个规定，二线支持的同事在到某部门进行支持后，要尽可能的对该部门的其他设备进行健康检查，包括检查系统补丁情况，杀毒软件版本，系统资源等等，或者对部门内其他用户进行访谈，了解设备使用情况，通过这样的方式可以将可用性提高（这也牵涉到问题管理部分的前馈活动）；
对于 IT 服务连续性管理、财务管理以及服务水平管理三个方面，因为资源不足，因此未开展有组织的活动。
限于条件，我们当时的实践是比较有限的，就长期来看，我们准备在积累一定的数据以及经验后，选择一个时机自行开发一个供部门内部使用的简单的管理系统，因为随着公司 IT 系统和设备的增加，依靠手工进行管理的工作量也在增加，这对于保持一定的服务质量是不利的，并且通过数据的积累，也可以对于一些问题出现的趋势以及提供服务的成本进行一定的分析，对后续开展 IT 服务的财务管理以及服务水平管理积累一定的信息。更进一步则是在 IT 服务管理获得一定的收效之后，向公司申请立项以及相应的资源来实施一个比较规范的 IT 服务管理项目。 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

该项目的实际收益在于 IT 部门很好的保障了公司 IT 系统以及 IT 基础架构的顺利运行，用户平均 MTBF 可达到 500 工作小时以上，同时，通过对服务过程中的表单收集的数据进行分析，可以提供对 IT 方面一些问题的决策支持，例如，通过对服务记录有关 PC 故障的分析，我们制定了公司内部 PC 的更新策略，通过购买原厂商 的延长保修服务，比其他方式可以节约至少 20% 左右的成本。

 
 
实际上，ITIL没有一个固定的框框，做什么，怎么做，做多少，都可以根据自己的实际情况来剪裁，关键是要抓住问题的核心，做的内容，一定是要对于降低业务的不确定性有益处的，如果反而增加了不确定性，那还不如不做了。