ITIL v4框架概述文档格式.docx

ITIL v4框架概述文档格式.docx

《ITIL v4框架概述文档格式.docx》由会员分享，可在线阅读，更多相关《ITIL v4框架概述文档格式.docx（16页珍藏版）》请在冰豆网上搜索。

其实，对于ITIL4的诞生，许多人期待的同时，也在观望，它将给我们带来什么？

2.3.ITIL4Foundation

必须要说明的是，相比ITILv3刚推出的时候五本书共计数千页来说，ITIL4本次仅仅是出具了Foundation版本，第一个Draft版本217页，第二个相对正式的版本不久前发布，为222页，即便比起ITILv2，这个篇幅也是比较少的。

至于说，后面是不是有更完整的版本，我觉得应该是的，因为在体系中，明确指出了如下图的认证结构（这个结构篇末会重点介绍）。

我们的感觉是，以往ITIL是以核心出版物为基础，根据对内容的不同深度理解，形成不同等级的个人认证，也许更具有商业头脑的

AXELOS，会把认证等级的材料与出版物一体化？

这个也许在未来才能知晓。

2.4.ITIL4的意义

ITIL4这时候的产生，还是很有时代意义的。

要知道，如今技术发展比以往任何时候都快。

云计算（IAAS,SAAS,PASS）、机器学习和区块链等技术的产生，为价值创造开辟了新的机遇，这意味着IT已经成为重要的业务驱动因素和竞争优势的来源。

当然，现在所有的方法论、技术、商业机构都清晰并利用了这一点，ITIL4是以什么面貌出现呢？

ITIL4很冷静的用它一贯所擅长的思维来解读这个时代，就是“服务管理”。

ITIL4提出：

在数字化时代，每个组织都是一个服务组织，而如今几乎所有服务都由IT驱动的。

所以服务管理被作为一组特定的组织能力，最终以服务的形式为客户创造价值。

这段话其实描述了这么两个事实：

第一、服务是组织实现价值的关键；

第二、服务基本

上都离不开IT。

那么，我们再进一步延伸，是不是可以理解为：

业务服务与IT服务将融合一体，传统

的IT运维将与业务运营一体化？

（关于一体化运营管理的思想，可以联系阅读北宙小范围

发布的《基于数字化时代的一体化运营管理体系》，里面提到的IIITOMS,SIA,ABCD,V-

PODAT等内容与之关系较大。

）

结论：

ITIL4依然是针对ITSM（IT服务管理）的实践框架，不过ITSM已经进入到一个新的时代——这个时代更崇尚服务，而且服务的形态也与以往不同。

3.ITIL4的核心概念

我们不需要花太多时间去背诵术语，以下提到基本概念，是理解ITIL4比较关键的几个，我们知晓即可。

ITIL以往提的比较多的是ServiceProvider与Customer，甚至提的更多的是ITSP（ITServiceProvider），但在ITIL4中，消费者（Consumers）成了最后价值的总获取者，消费者包括了：

客户（Customer）、用户（User）与Sponsor（赞助者或发起人），通俗解释就

是：

提要求的、使用的、出钱的（或拍板的）。

不过，除了这三类主要的消费者外，ITIL4还提出了一个“其它利益干系人”的概念，这包括了：

员工、合作伙伴、股东、供应商等。

服务关系管理（ServiceRelationshipManagement）就是基于服务提供者与服务消费者之间的一个服务架构，能用好ITIL4的前提，就是梳理好这个服务关系的模型。

我们可以看一个基于ITIL4ServiceRelationship的例子。

这是一个很好的模型，能让我们清晰理解自己的服务组成，怎么借助资源（Resouce）形成产品（Product，笔者认为这里应该是Product&

Service会更容易理解），基于这些产品，以实物货品（Goods）、资源访问（AccessToResource）、服务行为（ServiceAction）的组合进行服务的提供（ServiceOffering），最终达成预期的服务关系（Service

Relationship）。

这里采用了很好的产品思路来形成模型，目前许多组织，无论甲方还是乙方，如何服务产品化是有困惑的，这个困惑其实是可以通过ITIL4的建议来尝试解决的。

我们可以尝试实现一个“某部门的桌面支持”这么一个服务关系实现。

可以看到，通过这样的方式，我们能够清晰知道，实现了什么业务关系？

服务了什么（谁）？

服务中有什么？

（实体？

权限？

还是过程？

）是一个什么样的产品？

产品的背后是什么？

（硬件？

软件？

人员？

除此以外，ITIL4还提出了通过服务关系，把不同组织之间关联，可能你是A服务的消费者，同时又是B服务的提供者。

在这里，我非常建议大家去看一本《ServiceCentricity》的书，很好的诠释并给予这种服务链的关系。

当我们了解了ITIL4的基本概念和思想后，就能更好的去了解ITIL4的核心了，其实了解ITIL4并不难，主要是：

服务管理的四个维度、服务价值体系与服务价值链、管理的实践。

其中管理的实践部分，是ITIL的“传统粉丝”很容易理解的。

4.服务管理的四个维度

在ITILv2时期，PPT（People,Process,Technology&

Tools）是广为人知的，不过流程是相对核心的部分，一个著名的观点就是“以客户为中心，以流程为导向”。

ITILv3开始，提出了4P（People,Process,Product,Partner）的概念，这次ITIL4把4P的概念做了一次升级，如下图。

ITIL4中，对产品（Product）定义不仅仅是技术与工具，而是放到与服务平行的价值成果上，这个定义是非常合理的。

围绕产品与服务，四个维度分别是：

组织与人员（Organization&

People）、信息与技术（Information&

Technology），合作伙伴与供应商（Partner&

Suppliers），价值流与流程（Valuestreams&

Process）。

关于维度定义的思路，是目前大部分管理方法所提倡的，例如PMBOK的十大知识域

（第六版），PRINCE2的七大主题，ITSS的PPTR（People,Process,Techology,Resource），也包括北宙咨询提出的V-PODAT（Value–Process,Organization,Data,Application,

Technology），以上一些体系我们可以找其它机会进一步探讨，关于ITIL4，我们最需要关

注的是Valuestreams这个词，因为在后面很大的篇幅中，ITIL4都是遵循Valuestreams的方式来进行价值交付并贯穿流程的，相比以前版本中的大量流程累积，ITIL4明显感觉到这种没有场景驱动的流程罗列形式，对实践指导的效果实在太差。

很多人学了一堆流程，昏头昏脑，但还是不知道怎么用于实践。

所以采用Valuestreams就像在两个孤岛间搭起一个浮桥，那些以前的流程如今被统一称为实践（Practice）的部分好比势浮桥中的一块块木板。

另外，围绕这四个维度，ITIL4特别提出许多外部影响因素的存在，包括：

政治因素、经济因素、社会因素、技术因素、法律因素、环境因素，这不禁让我想起产品战略管理中著名的PESTLE理论——不好意思，这就是PESTLE理论。

5.服务价值体系与价值链

ITIL服务价值体系（SVS,ServiceValueSystem）描述了组织的所有组件和活动作为一个系统如何协同工作并实现价值创造的。

这些组件和活动以及组织资源可以随着环境的变化以灵活的方式及多种组合进行配置或重新配置，但这需要活动、实践、团队、授权和责任的整合协调，才能从各方面产生效果。

服务价值链（ServiceValueChain）是核心，等下我们需要再深入讲解，这个核心需要依靠实践（Practices）和治理（Governance），简单来说，分别解决“怎么做”和“做了没”的问题。

为了确保实践能优化持续，所以需要采用持续改进（Continualimprovement），为了治理有方，则需要提出明确的指导原则（Guidingprinciples）。

不过这一切，都是一座桥梁，这个桥梁连接了机会需求（Opportunity）与价值（Value）——正如前面所说，以前ITIL是IT服务者与客户（业务）的桥梁，现在升华为需求甚至潜在需求与价值实现的桥梁了。

我们再看看最核心的部分，就是服务价值链（ServiceValueChain）。

作为连接需求（Demand）与价值（Value）的核心引擎，这个模型把价值链分为七个环节：

驱动（Engage）[按：

这个官方术语表尚未出来，我曾询问官方，并表示是否需要我们支持，但是目前还没有反馈，我们暂且翻译成驱动]、产品与服务（Products&

Service）、计划（Plan）、改进（Improve）、获取或构建（Obtain/Build）、设计与转换（Design&

Transition）、交付与支持（Deliver&

Suport）。

其中驱动来自需求或潜在需求，产品与服务实现最终价值。

关于这个模型，对于ITIL4的学习者是要很重视的，我们在以后开展的培训中，也会把这作为我们多年IT服务管理经验的传递工具。

而且，以前传统的ITIL管理流程，例如事件管理，问题管理的应用，也要进行一次场景化整合。

我们不妨举个例子：

在一家工厂里，仓库中采用物联技术管理叉车运载，但是WiFi出了故障，这样所有的物流系统都因此受损，及时交货就会有问题。

如果按照以前的思路，仅仅把故障报给服务台，然后再按部就班处理，仓库经理和叉车工都会被隔离在流程外，会很焦虑，这也是以前传统ITIL的诟病。

在这里，不妨也说一下DevOps，这些年DevOps明显被“妖魔化”了，其实DevOps

在敏捷的开发测试运维一体化、基于精益的持续交付等方面很卓越，但这并不意味着

DevOps擅长解决服务交付的问题。

不过，在服务管理中，DevOps是后面提到的发布管理

（ReleaseManagement）的最好伴侣。

那么采用服务价值链来再造这个服务流程吧。

我们用列表的方式来简化这个流程。

第一步：

识别需求（Demand）

组件

Demand

角色

仓库经理，叉车司机

活动

发现仓库的一个区域没有WiFi覆盖。

这意味着叉车司机接受指令会延迟，

自动化拣货系统也会出问题，这将导致延误并有可能错过业务截止日期。

第二步：

响应驱动（Engage）

价值链

Engage

实践（Practice）

服务台，事件管理

仓库经理，服务台坐席

仓库经理致电服务台坐席并描述问题，确定这是优先级为2的事件，并且管理者希望的解决时间。

服务台记录有关此事件的信息。

第三步：

交付支持（Delivery&

Support）

Delivery&

Support

服务台坐席，网络支持工程师

该事件迅速升级给网络支持团队。

第四步：

支持改进（Devliery&

Support,Improve）

Devliery&

Support,Improve

事件管理，变更控制，服务配置管理，IT资产管理，持续改进（问题管

理，知识管理）

网络支持工程师

网络支持工程师识别出WiFi出现故障，并将其切换到备用WiFi上。

这是标准变更（StandardChange），因此工程师无需额外批准即可从配置管理系统（CMS）中获取配置新访问点所需的信息，并更新IT资产信息以显示此备件已被使用。

继而网络工程师更新事件管理系统并将案例标记为已解决。

同时，网络工程师会考虑这背后的原因，考虑能否预测问题，采用更好更快的解决方法。

第五步：

回应驱动（Engage）

服务台坐席，仓库经理

服务台坐席联系仓库经理以检查一切现在是否正常，然后关闭事件。

第六步：

确认价值（Value）

WiFi问题解决，叉车工愉快的工作。

第七步：

驱动改进（Engage,Improvement）

Engage,Improvement

服务台，事件管理，持续改进

仓库经理，服务台经理

发一个简要的满意度调查给仓库经理，他们完成并回复后，将分数用于识

别满意度情况，服务台经理进行改进考虑。

考虑到只是导读，所以我们采用了一个最简洁的例子进行剖析，所以有关获取构建、设计转换、产品服务等环节都没有提及。

如果以后大家有机会参加北宙的相关培训，我们在多年的IT服务管理实践中有很多例子可以分享。

在这里，我们只需要意识到一个事实，就是ITIL4已经不再提倡采用简单的事件管理、变更管理来驱动服务流程了，而是把这些流程里的方法作为“实践（Practice）”来应用。

其实这个方法并不是空洞的理论，在我们多年的IT服务管理咨询中，考虑到不同组织文化、不同业务模式，早就采用类似的思路去设计流程，用中国人常用的话来说，就是“落地”。

当然，这个方法的推行，还需要一段时间，目前的主流工具、国际标准（ISO20000）都还是遵循流程的架构进行服务管理，不过我相信，很快这种方法会得到践行。

下面我们就罗列一下ITIL4提出的实践（Practice）。

6.ITIL实践方法

通过前面的了解，大家可以理解，ITIL以往的流程将以实践的方式来由大家“选用”，我们在这个导论中，将不去详细讲解每一个实践，只做简单说明。

深入的学习可以在以后的培训、咨询、交流中进行。

目前分为：

通用管理实践（GeneralManagement）、服务管理实践（ServiceManagement）与技术管理实践（TechnologyManagement）。

6.1.通用管理实践

通用管理实践可以理解为已经在业务管理中被广泛认知的一些实践，可以理解为“不是

ITIL原创”的实践，我们罗列一下：

•架构管理（Architecturemanagement）

•持续改进（Continualimprovement）

•信息安全管理（Informationsecuritymanagement）

•知识管理（Knowledgemanagement）

•度量与报告（Measurementandreporting）

•组合管理（Portfoliomanagement）

•组织变革管理（Organizationalchangemanagement）

•项目管理（Projectmanagement）

•关系管理（Relationshipmanagement）

•风险管理（Riskmanagement）

•服务财务管理（Servicefinancialmanagement）

•战略管理（Strategymanagement）

•供应商管理（Suppliermanagement）

•劳力人才管理（Workforceandtalentmanagement）

很多人看到这么多实践，想必又会“吐槽”ITIL4搞得很复杂。

其实，如果这么想，应该还是没有理解“价值链”的应用，价值链如何实现业务流程才是关键，至于这些实践，不能都用，要不要用，取决于需求与价值的关系。

例如刚才那个“叉车”的例子，仅仅用到了服务管理的实践，而且更多的是服务台与事件管理的实践。

但我们在一次CMDB的场景设计流程中，就确实用到了战略管理和项目管理的实践。

其实，如何灵活使用管理方法，也是一种卓越的管理能力。

6.2.服务管理实践

服务管理实践基本上是ITIL自有的设计，其中许多实践已经成了业内的事实上标准，我们先看一下。

•可用性管理（Availabilitymanagement）

•业务分析（Businessanalysis）

•容量与性能管理（Capacityandperformancemanagement）

•变更控制（Changecontrol）

•事件管理（Incidentmanagement）

•IT资产管理（ITassetmanagement）

•监控与事态管理（Monitoringandeventmanagement）

•问题管理（Problemmanagement）

•发布管理（Releasemanagement）

•服务目录管理（Servicecataloguemanagement）

•服务配置管理（Serviceconfigurationmanagement）

•服务连续性管理（Servicecontinuitymanagement）

•服务设计（Servicedesign）

•服务台（Servicedesk）

•服务级别管理（Servicelevelmanagement）

•服务请求管理（Servicerequestmanagement）

•服务验证与测试（Servicevalidationandtesting）

同样，并非所有的实践都会被采用，不过，从这个清单来看，如果一个组织把这些实践都落地了，那一定是伟大的。

为了便于大家比较，我们特别做一张表，把这个部分内容与ITIL

ITIL4

服务管理实践

ITILV2

ITILv3

ITIL2011

ISO20000

2005/2010

2018

V-PODAT

可用性管理

√

业务分析

≈

容量与性能管理

变更控制

事件管理

IT资产管理

监控与事态管理

问题管理

发布管理

服务目录管理

服务配置管理

服务连续性管理

服务设计

服务台

服务级别管理

服务请求管理

以往的版本以及北宙研发的用于一体化运营管理的V-PODAT进行对应。

（√表示一致，≈表示有所涉及，空白表示不涉及）

从这张表中可以看到，相比来说，ITIL4并没有颠覆以往太多的实践或流程，这是有利于企业平稳过度的。

ITIL4没有像许多人所说的一样，开始往DevOps上去完全靠拢，而是很沉着的继续为服务价值实现做贡献。

但这不等于说它不拥抱改变，例如下图：

这图表明在发布管理中，应该充分关注不同的发布需求，应该选择不同的模式，是传统瀑布模式，还是敏捷DevOps模式呢？

这点在北宙的《数字化时代的一体化运营管理体系》中有所提及，欢迎探讨。

不过需要特别提出的是，在过去的很多年，“炒概念”是一种社会现象，但无论是企业还是投资方，虽然有从中牟利者不在少数，但因此受创的恐怕更多。

所以建议读者还是能“修心养性”，不是为了“数字化”“DevOps”“互联网”这些字眼来学习新的方法，而是从业务价值的本质，去看待这些方法。

尤其中国的组织多样性很强，例如银行不仅要面对业务拓展，更面临银监会的监管，政府单位没有财务回报的说法，但是如何保障民众服务就是政府单位的业务价值，这些才是我们的目的。

6.3.技术管理实践

技术管理实践在ITIL的知识体系中，一直是“不得不提”，但又感觉有些“游离”，在ITILv2时期，有本书叫《I