ITILv3流程建立的顺序

转自：ITSMv3

　　以下是一份在产品数据中心环境中很关键的ITIL流程清单。制定序列表的理由是其对稳定性的要求更为严格。

　　首先，IT运营团队，特别是数据中心运营团队需要有固定的流程来管理生产中的变更。无论其环境是由20年之久的传统系统组成还是由尖端的高密度 组成，一旦发生一个错误变更所有的设备都会面临崩溃。此外，很多小的、计划不周的变更可能引发很多不易察觉的错误，如果它们发生在最为糟糕的时 段，会引发许多保密性、完整性和可靠性相关问题。精心设计和实施变更管理流程可以保证业务的稳定性，并允许组织针对是否实施变更制定有效的风险权衡措施。 借用一个朋友的观点，如果不将变更管理作为改革的第一步，你的ITIL项目可能会成为停机等安全事故的借口。

　　第二，必须有一个配置管理系统(CMS)，来存储每个系统及其与创建服务相关的数据。和我合作的机构总是对构成彼此关联服务的各种配置项目 （Cis）缺乏足够认识。这导致计划、发展、测试、操作和安全方面的考虑不够周全。相反，如果有一个CMS系统，就能够及时掌握与变更管理相关的数据更 新。实施和采纳CMS是为了尽可能地了解系统并提升其性能。

　　第三，总会有事件由于这样或那样的原因而不符合标准操作。一个IT机构如何应对突发事件，对于用户、顾客和整体业务而言关系重大。从业务运营角 度来看，事件和事件管理这两个进程同等重要。ITIL v3包含了“事件”的概念。这是一个关键的进程，涵盖研发、测试和生产领域，旨在了解各种运营环境标准之间的关系以及IT部门对其的反应。某些情况下，它 会自动反应，如在非高峰时段控制一台服务器重起并从已知的内存泄漏中恢复。它也可以通过用于持续恢复的IT（ITKM）来收集并应用所学的经验教 训。

　　第四，了解问题的根本原因，彻底解决问题或在业务开展时阻止问题的出现是很有必要的。这属于问题管理领域。如果问题是可解决的，那就不要让它继 续存在下去。

　　变更管理和配置管理能在整个服务生命周期内提高业务的稳定性和规划性，同时也验证了以上排序的合理性。突发事件和预知事件在本质上是相反的，这 有助于IT部门制定相应对策。问题管理在处理事件时反应要快，这样对于找不根本原因的事件可以通过一定的前瞻性在初始阶段就避免事件和问题的发生。而究竟 是否应该遵循这个过程? 这取决于你如何去实现它们。

　　对一些组织机构来说，变更管理和配置管理需要同时执行，其次是突发事件和预知事件管理，接着才是问题管理。在其他面临大范围稳定性挑战的机构 中，要做的第一件事是用基础变更管理来“止血”。通常来讲，那些彼此冲突的资源才能够真正推动企业的发展。

　　有一个概念你需要仔细考虑——IT部门中最宝贵的资源是人，我们不能浪费他们的时间去彼此争夺资源。他们得努力工作并定制工作计划以推进组织机 构的发展。因此，我们需要制定一个进程为他们创造稳定的环境。

　　那么，这就是全部吗？当然不是。研发部门创造了稳定的服务，运营部门维持了服务的稳定，必须有其他部门来进一步促进IT业务的发展，这是其他 ITSM进程，如服务水平管理、可用性、容量规划等进程发挥作用的地方。我不是一名ITIL狂热爱好者，但我相信如果你在追求组织目标时可以采用务实的进 程，ITIL可以给你提供很多东西。ITSM并不意味着结束——它只是实现目标的手段。在当前的经济形下,IT部门需要弄清业务需求及其实现手段，以及如 何保护其价值的存在。

　　总之，IT部门需要有效的过程预测业务结果。业务无法承受任何资源浪费，包括时间、金钱和管理注意力。此外，IT部门必须能以一种可持续满足需 求的方式持续地提供服务，否则业务可能会遭遇极大的风险。对于IT业务的需求是不变的，而且这种需求必须以为整个机构创造和保护价值的方式来实现。