ITIL好看不好吃.docx

ITIL好看不好吃.docx

《ITIL好看不好吃.docx》由会员分享，可在线阅读，更多相关《ITIL好看不好吃.docx（18页珍藏版）》请在冰豆网上搜索。

ITIL好看不好吃

ITIL好看不好吃？

一头是上级的要求、一头是员工的抵制。

要想在“行驶中换轮子”，还真有些力不从心。

他怎样解决运行管理的问题呢？

“南桔”成“北枳”

王主任是某省电信公司计费业务中心主任。

五、六十人的计费业务中心负责全省计费、经营分析等重要业务系统的建设和运行工作。

计费业务中心虽说人不少，但具体到每个系统，也就一、两个人负责。

由于业务变化快、系统升级改造频繁，这些人的主要精力放在了项目建设和工程施工上，运行保障工作基本处在比较初级的自发状态：

工作以“救火队”方式的被动响应为主，故障处理和系统维护过程基本没有记录和总结。

王主任理解，ITIL（信息技术基础架构库）建设是管理项目，ITIL标准的确先进，咨询专家说得也绝对正确，大厂商昂贵的软件功能确实很多，但落实到本部门实际工作中，总感到很隔膜。

听专家和厂家介绍起来头头是道，只要买了他们的产品和服务就能包治百病，但真花了很多钱之后似乎什么病也没治好，还说不清人家的东西哪里不好。

是ITIL到了国内水土不服，还是国际大厂商开出的药方不对症？

总不能说自己生的病不对吧？

ITIL在该企业中的应用归结下来主要有以下几方面问题：

Ø系统建设耗费大量部门资源，无力进行运行保障工作；

Ø部分员工不愿接受ITIL带来的变化；

Ø流程“一人多角”现象严重，执行层面阻力较大；

Ø流程工具使用情况不理想，系统建设成效不够显著。

勿让ITIL成“北枳”

企业在IT运营过程中遇到的80%的问题是由管理原因导致，而管理问题需要采用管理的手段加以解决，这也是身为IT管理最佳实践的ITIL如此受到推崇的原因之一。

然而，尽管ITIL拥有国外各大企业成功实践的“纯正血统”，但正如“南桔北枳”的道理一样，对他人成功的简单移植却并不一定能够确保自己的成功。

根据我们对国内各大企业的调查表明，国内企业上马ITIL的不少，但真正能够有效利用并体现其价值的却寥寥无己。

大家讨论的话题也逐渐地由What转移到了How。

如何在组织内部正确地实施ITIL，使其最佳实践的理念和方法在国内IT的土壤中生根发芽、茁壮成长，最终收获期望的果实，如何让“北枳”与“南桔”一样甜美，甚至超过“南桔”变成世人称道的“北桔”，成为一个严峻而富有挑战的现实问题。

北方如何收“南桔”—ITIL角色

如果企业认识到应首先对部门的组织结构进行改造，以适应ITIL流程的需要，则可以避免后面出现类似“系统建设耗费大量部门资源，无力进行运行保障工作”的问题，而这是一个庞大的工程，如果能够快速的建立ITIL流程所需要的组织结构呢？

网管软件在这方面提供了基于ITIL的完整角色定义，简单来讲，只需要把组织结构中的人员加入到对应的角色中来就可以了，正好解决这个难题，在ITIL中设计的角色大致如下：

当然，对各种角色的说明是必不可少的，在这里可以看到每一个角色的职责，这样就可以不需要考虑组织结构的问题了，对应的问题找对应的角色就完全可以满足要求了。

角色的好处就只有这些？

那你可错了，在满足ITIL要求的同时，还需要注重系统的安全性，所以，在页面访问上也需要做权限的控制，当然，从使用简单的角度考虑，只需要对应不同的角色给看不同的页面就可以了，一个角色，既满足了ITIL的要求，又可以快速的使用起来，还可以做权限的控制，这样的设计还是非常人性化的。

 人性化的东西需要的是操作简单，往角色里添加人员？

简单，只需要像下面这样，1分钟搞定！

 一头是上级的要求、一头是员工的抵制。

要想在“行驶中换轮子”，还真有些力不从心。

他怎样解决运行管理的问题呢？

北方如何收“南桔”——解决好用和不好用

在流程设计完毕之后，如果没有工具的辅助，流程永远无法真正落地。

但落地言易行难，国内太多客户都面临流程工具利用率不高的窘境。

这其中主要可以概括为“不好用”和“用不好”两方面。

 “不好用”主要是指工具本身功能或者性能方面无法达到期望，建议对反映最强烈的或对流程效率影响最大的点进行分析和改进。

比如事件表单的设计，本来事件流程就强调解决时间，但很多工具往往在事件记录时耗费了大量时间。

面对这种情况，应考虑如下原则：

Ø减少一些不必要的字段，只保留核心的信息字段

Ø多做“选择题”，少做“填空题”，尽量不做“问答题”

Ø建立信息之间的关联，以便填写某字段后，大量相关信息自动带出

Ø多使用模版进行记录 

至于“用不好”，就得从工具的价值层面来考虑了。

如果使用工具无法为员工带来益处，推动使用工具自然是阻力重重。

因此，我们不能简单地将工具强制“推”给员工，而是应当对工具价值充分挖掘，以“吸引”员工使用。

为了解决上述“用不好”的问题，对于ITIL实现的关键部分提供向导式的产品配置方式，通过简单的设定即可轻松实现产品的初始化过程。

CMDB配置向导

服务台配置向导

   同时，还提供流程的版本控制，可实现同一处理事件切换不同的处理流程，方便在不同的管理环境下进行运维，提供一套流程的多套版本，极大的方便了用户使用：

流程版本配置界面

对于“不好用”的问题，流程设计工具上通过MIPD可以实现对流程的可视化设计：

Ø“即配置，即所得”：

业务分析员实现可视化流程设计，在简单的拖拽中，以直观、易用的方式，“零编码”完成流程设计。

业务分析员完成流程设计后，一键发布，流程立即执行，无需漫长等待。

MIPD具有动态执行能力，允许业务分析员灵活地同时创建和改进流程应用，快速适应企业需求，无需技术人员支持。

MIPD提供建立工作流模型所需的各类基本元素，比如活动、子过程、连接弧等以及属性的设置。

Ø适用于复杂、跨应用及多种异常业务流程：

MIPD可设计上百种丰富的流程执行模式，包括串行、并行等。

除简单、通用的工作流程，MIPD也适用于会签等复杂的大规模流程方案。

Ø动态适应机构的变化：

企业组织架构调整屡见不鲜。

MIPD基于角色的流程定义，有别于以人名识别的方式，当组织架构调整、人员调动和离职时，无须更改流程设计。

Ø与表单无缝集成：

每个流程都可绑定需要的表单，也可实时修改表单。

流程设计工具界面

北方如何收“南桔”——CMDB核心的建设

 配置管理数据库（ConfigurationManagementDatabase，缩写为CMDB）是ITIL最佳实践的核心模块，所有的用户关注的资源，包括各种软件、硬件、应用、业务单位、人员等，均被识别为配置项（ConfigurationItem）并存储在CMDB。

通过这样的描述，不难发现，要进行CMDB的建设，与以往热议的资产管理的建设有一点相似，共同点就在于，看起来内容很简单，实际上却因为数量大而难以管理。

大家知道，CMDB有两部分重要内容，一是CI，二是CI之间的关系，这两部分构成了CMDB比较核心的内容，在CMDB初始化方面，很多产品只是提供了手工输入的方式对CI的初始化，用户需要面对大量的需要手工输入的信息，造成系统使用前的高门槛，可以通过两种方式快速进行CMDB的初始化，第一种是自动发现CI，第二种是从监控系统中导入，大大简化了用户管理员的工作，快速搭建ITIL最佳实践平台。

   上图是在产品中进行自动发现CI的方式快速初始化CMDB。

上图是在产品中通过导入的方式快速初始化CMDB。

    除此之外，CI之间的连接关系非常重要，当资源故障时可以辅助用户管理员快速判断故障点的位置以及与故障点相关联的其他IT资源，快速的找到对应资源的关联关系和服务厂商。

   上图是对CI连接的设定，包括依赖、属于、连接、使用、安装等，而对于资源之间的关联关系，只需要通过图中所示的鼠标点击的方式即可轻松完成。

、

    产品以CMDB为运维核心，其实最关键的就是关联CI与事故、问题、变更、发布等流程的关系，可以在ITIL服务的整个过程中随时调取对应资源的CI以及CI关联，辅助管理员对故障的处理决策和影响分析。

CI的定制也尤为重要，上面的界面是CMDB设计工具，提供给用户可视化的工具对CI进行扩展，方便日后的使用。

北方如何收“南桔”-监控事件自动触发服务台请求

为了更加方便的进行故障处理，同时在IT管理中也需要对所有出现的故障进行记录和统计，不放过任何漏网之鱼，所以，监控系统产生的重要故障报警自然不能轻易放过，如果有一种自动化的故障事件触发策略，当出现故障事件时，除了按照常规方式报警之外，还可以按照预定义规则触发故障处理流程给管理员，做到监控与运维的无缝集成，那么对于IT故障管理来讲，就解决了一个最大的服务台请求来源的问题。

监控系统与服务台的紧密结合，从配置角度上来讲当然是越简单越好，比如我们所讲的“四步曲”，通过四步操作就能触发对应的服务台请求：

1.1 选择需要产生运维流程的IT资源

1.2 选择当产生某种事件时触发运维流程

1.3 选择触发流程的类型

1.4 选择流程处理人员

   将这些内容设置完毕后可以在服务台中看到对应的故障单：

   另外一个重点，请求自动触发到服务台，一线处理人员在进行处理的过程中就会面对一个重要的问题，就是这个问题是否可以提供给我处理依据，可以将以往已经处理过得类似的处理方式提供给我做参考，所以这才是服务台的关键，自动化的根据故障的类型，关联出知识库中的对应条目，那就更好了，比如下面途中的示例：

   点开操作按钮就可以看到具体的处理步骤了：

所以，在IT运维管理的过程中，有一个非常重要的点就在于我们上述所讲到的：

监控事件自动触发服务台请求，统一管理所有IT事故，同时，在进行请求处理的过程中，还可以自动的关联出对应的知识条目，这样一来就可以使IT运维的过程更加自动化，也方便了统计和管理。

北方如何收“南桔”-报表及KPI，度量运维阶段工作效率

数据的统计分析是在整个ITIL实施中非常关键的环节，也是把握服务台、问题、变更、发布等重要环节效率并制定提高效率的直接参考依据，所以，直观的查阅这些数据，就成了一个非常重要的问题。

就像下面这样：

可对目前各种事务状态做查询和汇总，至少应该提供以下内容的报表：

服务台请求事务状态统计类型

统计效果示意图

除此之外，还需要考虑到报表/KPI的自定义，给使用者提供自行对所关注的内容提供可定制化的报表设计界面。

自定义统计查询

北方如何收“南桔”-建立故障点关联裙带展现

故障分析往往是最头痛的，因为在这个过程中寻找问题原因需要花费很多的时间，但是在我们以往的操作中往往会出现一种现象，就是费了很大工作量将一个故障处理完毕后，马上有人打电话过来说怎么这个问题解决了另外的一个功能又不好用了呢？

其实，当管理人员全心去处理故障的时候往往忽略了与这个故障点相关的其他IT资源，所以导致我们工作中可能会出现“拆东墙补西墙”的现象，如果有一种机制可以做到在一个故障点处理的过程中帮助管理员将与之有依赖关系的IT资源也同时列出来的话，那么管理员在处理故障时就会有一个参考，事先做到故障处理过程中的风险分析，这样一来，就不会出现解决老问题引起新问题的现象了，比如下面这个故障：

我们看到，如果故障点在Latte-OA2上，那我们在对这个应用进行故障处理的过程中自然会考虑到其他两个相关的IT设备，易于风险控制。

当然，风险控制是一方面，如果我们在处理这个问题的时候需要厂家或者供货商的支持人员给予协助时，怎么面对数量非常多的供货商和厂家，立即找到这个故障点所对应的厂家或供应商的技术支持联系方式，这个问题也是在故障处理的协作中非常重要的一点。

比如下面这个页面，就是在故障点上点击右键查看资源详细信息时能够带给我们的信息：

我们看到，如果故障点在Latte-OA2上，那我们在对这个应用进行故障处理的过程中自然会考虑到其他两个相关的IT设备，易于风险控制。

当然，风险控制是一方面，如果我们在处理这个问题的时候需要厂家或者供货商的支持人员给予协助时，怎么面对数量非常多的供货商和厂家，立即找到这个故障点所对应的厂家或供应商的技术支持联系方式，这个问题也是在故障处理的协作中非常重要的一点。

 比如下面这个页面，就是在故障点上点击右键查看资源详细信息时能够带给我们的信息：