学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放

来自《亿腾专刊》

       我们发现，每一项工程项目刚开始时似乎总是信誓旦旦，但不幸的是，不是每一个项目都能够最终获得完满的成就。那么怎样才能开始实施ITIL，然后维持其良好运转发展状态和维持实施ITIL 所必需的能量水平和关注程度呢？
       这里引用莎士比亚的一句话，"期望乃痛苦之根源。"有戏剧性的是：虽然免不了触壁，但当你负责某项项目实施时，还是不
得不设定各种目标以促使其兴旺发展。对不住这吟游诗人了，我把他的这句话改成"不理性的期望乃痛苦之根源。"

       我怎么知道哪些期望是合理的呢？

       不管你是否有系统开发、工程管理、业务分析或其它的专业背景，都不可能没听说过设定期望的重要性。但如果真的每个人都知道了它的重要性，那又为什么不是每一个项目实施到最后都能与期望一致呢？可能更实际一点的问题是：怎样才能设定合理的期望呢？
       设定期望也就是设定合适的目标和确定目的。这篇文章的目的，就是想说明和希望利益所涉各方应确保目标与项目实施保持一致。高度明确的目标最有益，因其最容易衡量。显然，项目成功的标准是由利益相关的参与者来设定，要是预期目标未实现，他们所受打击也最大。为了使项目风险降至最低，首先要知道利益相关的参与者都有谁，并且保证每个投资者都参与进来。如果发现某个利益相关的参与者无意参与，你有几个选择：说服他参与，征求管理方的帮助把他弄到会议桌前，万一不行，你只能在项目章程上作为危险因素写上他并不愿意参与。项目实施的不尽人意只能使利益相关的参与者感到沮丧，不管他们愿意与否。其次，应该采取措施使在不确定情况下作出的决定越少越好。当然了，你作出决定之前很少能够对实际情况了如指掌，那么怎样才能克服它呢？

       怎样开始项目？

       很多项目的实施都有一个起始阶段。这个阶段要做的是：确定利益所涉各方，拟定项目章程大纲并规定目标和目的，详细描述资金来源和数量，罗列项目组人员、发起人，还应包含所涉重要事件和交付标准。不幸的是，大多数项目是在起始阶段之后，也就是在重要决定在项目章程大纲中定下来之后才开始对相关职员培训。而你想要的是在项目起始之前，再作出不可反悔的选择之前培训关键人员。起始阶段期间，公司开始和销售商沟通，购买用于实施ITIL 方案的设备软硬件。你若是想与卖主沟通时不处于下风，就不得不事先提高内部人员专业性，方法是利益所涉人员和工作组成员参加学习ITIL 基础知识。
       即使你不想与卖主大费周折，早期的培训还能使你的工作组发展一个共享知识库，以便于快速准确地讨论如何构建网络框架。项目工作组的一个常见的哀叹是："我们对过去不知道的现在还是一无所知。"因此需要通过早期培训克服此弊端。

       确定ITIL 项目期望的四个关键挑战

       为了成功，任何项目的工作组必须设定和运用期望--这方面ITIL 项目并无它异。在ITIL 项目中你需要掌控的最大期望也就
是你能够像管理其他项目一样管理它。下面是四个不同点，它们会在项目章程大纲制定会议期间做各种决定时起作用，还会贯穿于项目的整个生存周期中。

1、ITIL 项目实施需要多年

       据此，要看到你企业的ITIL 项目的各个目标是在整体之外某阶段起作用，这一点至关重要。据个例子来说，当你执行配置管理方案时，你会定义一个配置管理数据库（CMDB）来储存所有配置项（CI）的信息。在单个项目循环周期中，应该尽力首先配置最重要的类型的配置项。通过创建方案实施时间表来明确特定的配置项类型何时加入CMDB 的做法会得到一致同意。各个利益相关人员可能不喜欢在该列表上排最后，但他们还是会支持该项目，他们知道他们并没有被忘记或忽略。记住这一点，共同的培训经验让每个人都能平等协商。

2、管理ITIL 的各个项目应有程序规划

       大多数企图实施ITIL 的公司都能形成执行各个项目的方法，但却极少有机制来管理若干年内的互相关联的一组项目。考虑到ITIL 实施需要若干年而单个项目的持续时间较短，可以成立一个成员组，这个成员组不以单个项目的存在时间为限--而是一个宏观规划的组。该组的职责在于保证整个计划安排的客观连续性，以及仲裁平行运行的项目间产生的冲突。 可以上面谈到的CMDB 的例子进一步说明，可以注意到被如此描述的CMDB 是一个精确的，保持最新的CI信息库。而且该库的存在并不虚无。它需要信息变更管理以维持数据保持最新状态（项目１）。信息存储完备后，就可以通过事件管理来改善服务调用应答而使用了（项目２）。问题管理能把校对整理事件通知单以获得问题通知单（即找出问题的根由）（项目３）。阐明研究CI 之间的关系（项目４）来改善当计划做一些系统调整时各个部分相互影响的分析，不断提升应用程序可用性和减少不在计划内的停工期。这些都需要宏观规划组来监视。如果你还没有这么一个组，那得赶快组建一个。

3、你是在构建一个框架而非安装一个产品

       一般来说，产品安装比起框架构建要显得简单。大多数主要的软件销售商经常抱怨他们的产品在多个公司安装的过程。然而，当准备构建ITIL 框架时，你就会突然面临决策问题，即怎样才能使现存的网络处理模型适应欲构建的ITIL 项目。因为现存的处理过程包含于现存的应用程序中，把这些程序有机的组合是一大挑战。不要期盼找到一个简单的最佳解决方案。你不得不使用你培训所得的技能，权衡不同的处理方法，另外，基于ITIL 的一些方案的自动化需用到的许多工具有固有的局限性，你也不得不同时作权衡，通过权衡做出明确的有机组合的方案。可能最重要的是，你需要促使利益所涉人员积极的作出各种决定。因为ITIL 不要求人们只以一种方式工作，但人们可能想保留选择权而迟迟不做出决定。如果你遇到的正是这种情况，提醒各相关人员每个项目只不过是整个**上的一小步而已。在将来的某个阶段你可以重审这个决定。

4、在工程进行过程中你会损失资源

       在项目审查会议上，能发现项目计划的一个最常见的假设（或不如说是危险）是假设资金、时间和人员在项目结束前能保持连贯恒定。根据你单个项目的持续时间，你可能能够数出从项目开始到结束都在的人员。然而，对于一个历时几年的ITIL 工程，我怀疑每个人都能自始自终和你在一起。你应在工程中制定保障措施以管理人员的变换--对那些较高级的职员也得提防。有两个缓和措施可以采取：第一，确定候补人员，而且该候补人员是适合越多的项目越好。你无需给与正式的职位，但要尽量使更多的人了解你的单个项目的关键元素。很明显，实时状态的文件和状况报告能帮上忙，但你应避免只送单个人员去培训。如果根据预算只能培训单个人员，应该设法把培训知识传递到组内成员之间。第二，做出培训计划以使项目组新成员快速的进入项目状态。作为一个小组的新成员，但没有制定好的措施使其快速跟上并快速发挥作用，那状况要多糟糕就有多糟糕。ITIL 工程的管理不同于其他项目的管理。你若遵照此文要点办事，在结束的那一天，每个人的期望都会获得圆满的实现。

学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放

来自《亿腾专刊》

       我们发现，每一项工程项目刚开始时似乎总是信誓旦旦，但不幸的是，不是每一个项目都能够最终获得完满的成就。那么怎样才能开始实施ITIL，然后维持其良好运转发展状态和维持实施ITIL 所必需的能量水平和关注程度呢？
       这里引用莎士比亚的一句话，"期望乃痛苦之根源。"有戏剧性的是：虽然免不了触壁，但当你负责某项项目实施时，还是不
得不设定各种目标以促使其兴旺发展。对不住这吟游诗人了，我把他的这句话改成"不理性的期望乃痛苦之根源。"

       我怎么知道哪些期望是合理的呢？

       不管你是否有系统开发、工程管理、业务分析或其它的专业背景，都不可能没听说过设定期望的重要性。但如果真的每个人都知道了它的重要性，那又为什么不是每一个项目实施到最后都能与期望一致呢？可能更实际一点的问题是：怎样才能设定合理的期望呢？
       设定期望也就是设定合适的目标和确定目的。这篇文章的目的，就是想说明和希望利益所涉各方应确保目标与项目实施保持一致。高度明确的目标最有益，因其最容易衡量。显然，项目成功的标准是由利益相关的参与者来设定，要是预期目标未实现，他们所受打击也最大。为了使项目风险降至最低，首先要知道利益相关的参与者都有谁，并且保证每个投资者都参与进来。如果发现某个利益相关的参与者无意参与，你有几个选择：说服他参与，征求管理方的帮助把他弄到会议桌前，万一不行，你只能在项目章程上作为危险因素写上他并不愿意参与。项目实施的不尽人意只能使利益相关的参与者感到沮丧，不管他们愿意与否。其次，应该采取措施使在不确定情况下作出的决定越少越好。当然了，你作出决定之前很少能够对实际情况了如指掌，那么怎样才能克服它呢？

       怎样开始项目？

       很多项目的实施都有一个起始阶段。这个阶段要做的是：确定利益所涉各方，拟定项目章程大纲并规定目标和目的，详细描述资金来源和数量，罗列项目组人员、发起人，还应包含所涉重要事件和交付标准。不幸的是，大多数项目是在起始阶段之后，也就是在重要决定在项目章程大纲中定下来之后才开始对相关职员培训。而你想要的是在项目起始之前，再作出不可反悔的选择之前培训关键人员。起始阶段期间，公司开始和销售商沟通，购买用于实施ITIL 方案的设备软硬件。你若是想与卖主沟通时不处于下风，就不得不事先提高内部人员专业性，方法是利益所涉人员和工作组成员参加学习ITIL 基础知识。
       即使你不想与卖主大费周折，早期的培训还能使你的工作组发展一个共享知识库，以便于快速准确地讨论如何构建网络框架。项目工作组的一个常见的哀叹是："我们对过去不知道的现在还是一无所知。"因此需要通过早期培训克服此弊端。

       确定ITIL 项目期望的四个关键挑战

       为了成功，任何项目的工作组必须设定和运用期望--这方面ITIL 项目并无它异。在ITIL 项目中你需要掌控的最大期望也就
是你能够像管理其他项目一样管理它。下面是四个不同点，它们会在项目章程大纲制定会议期间做各种决定时起作用，还会贯穿于项目的整个生存周期中。

1、ITIL 项目实施需要多年

       据此，要看到你企业的ITIL 项目的各个目标是在整体之外某阶段起作用，这一点至关重要。据个例子来说，当你执行配置管理方案时，你会定义一个配置管理数据库（CMDB）来储存所有配置项（CI）的信息。在单个项目循环周期中，应该尽力首先配置最重要的类型的配置项。通过创建方案实施时间表来明确特定的配置项类型何时加入CMDB 的做法会得到一致同意。各个利益相关人员可能不喜欢在该列表上排最后，但他们还是会支持该项目，他们知道他们并没有被忘记或忽略。记住这一点，共同的培训经验让每个人都能平等协商。

2、管理ITIL 的各个项目应有程序规划

       大多数企图实施ITIL 的公司都能形成执行各个项目的方法，但却极少有机制来管理若干年内的互相关联的一组项目。考虑到ITIL 实施需要若干年而单个项目的持续时间较短，可以成立一个成员组，这个成员组不以单个项目的存在时间为限--而是一个宏观规划的组。该组的职责在于保证整个计划安排的客观连续性，以及仲裁平行运行的项目间产生的冲突。 可以上面谈到的CMDB 的例子进一步说明，可以注意到被如此描述的CMDB 是一个精确的，保持最新的CI信息库。而且该库的存在并不虚无。它需要信息变更管理以维持数据保持最新状态（项目１）。信息存储完备后，就可以通过事件管理来改善服务调用应答而使用了（项目２）。问题管理能把校对整理事件通知单以获得问题通知单（即找出问题的根由）（项目３）。阐明研究CI 之间的关系（项目４）来改善当计划做一些系统调整时各个部分相互影响的分析，不断提升应用程序可用性和减少不在计划内的停工期。这些都需要宏观规划组来监视。如果你还没有这么一个组，那得赶快组建一个。

3、你是在构建一个框架而非安装一个产品

       一般来说，产品安装比起框架构建要显得简单。大多数主要的软件销售商经常抱怨他们的产品在多个公司安装的过程。然而，当准备构建ITIL 框架时，你就会突然面临决策问题，即怎样才能使现存的网络处理模型适应欲构建的ITIL 项目。因为现存的处理过程包含于现存的应用程序中，把这些程序有机的组合是一大挑战。不要期盼找到一个简单的最佳解决方案。你不得不使用你培训所得的技能，权衡不同的处理方法，另外，基于ITIL 的一些方案的自动化需用到的许多工具有固有的局限性，你也不得不同时作权衡，通过权衡做出明确的有机组合的方案。可能最重要的是，你需要促使利益所涉人员积极的作出各种决定。因为ITIL 不要求人们只以一种方式工作，但人们可能想保留选择权而迟迟不做出决定。如果你遇到的正是这种情况，提醒各相关人员每个项目只不过是整个**上的一小步而已。在将来的某个阶段你可以重审这个决定。

4、在工程进行过程中你会损失资源

       在项目审查会议上，能发现项目计划的一个最常见的假设（或不如说是危险）是假设资金、时间和人员在项目结束前能保持连贯恒定。根据你单个项目的持续时间，你可能能够数出从项目开始到结束都在的人员。然而，对于一个历时几年的ITIL 工程，我怀疑每个人都能自始自终和你在一起。你应在工程中制定保障措施以管理人员的变换--对那些较高级的职员也得提防。有两个缓和措施可以采取：第一，确定候补人员，而且该候补人员是适合越多的项目越好。你无需给与正式的职位，但要尽量使更多的人了解你的单个项目的关键元素。很明显，实时状态的文件和状况报告能帮上忙，但你应避免只送单个人员去培训。如果根据预算只能培训单个人员，应该设法把培训知识传递到组内成员之间。第二，做出培训计划以使项目组新成员快速的进入项目状态。作为一个小组的新成员，但没有制定好的措施使其快速跟上并快速发挥作用，那状况要多糟糕就有多糟糕。ITIL 工程的管理不同于其他项目的管理。你若遵照此文要点办事，在结束的那一天，每个人的期望都会获得圆满的实现。