从企业实务角度解读 ITIL4 之14个通用管理实践

公众号回复：干货，领取价值58元/套IT管理体系文档

公众号回复：ITIL教材，领取最新ITIL4中文教材

正文

纵观如今的企业环境，我们不难发现 ：IT 技术已不再作为一种“乙方”产品提 供给组织内部的“甲方”-- 业务，然后业务方再单独以服务的形式交付给外部用 户了。取而代之的是 ：IT 技术作为关键环节，已经深度地融合到了业务的组成部 分之中，它们共同对外提供服务 ,业务已变得更加智能了。ITIL 4迎合了新的“IT  + 业务”生态链模式，不但 IT 从业者需要重新解读与践行，就连管理层也应当有 所了解与参与。面对全新的 ITIL 4，我们又该如何在日常工作中进行实践，并在 企业中起到积极地推进作用呢？下面，我将带着大家一起进行抽丝剥茧式地深入 解读。

核心概念与通用管理实践

核心概念

过去的 ITIL 版本主要偏向于服务管理与运营的各种流程，而如今的 ITIL 4 则提出了服务价值系统（Service Value System）的概念，即：无论是从宏观上将企业看作一个整体，还是从细微的角度来看日常运营中的某个服务系统，它们都可以在逻辑上将外部机会与需求（Opportunity/demand） 视为输入，同时以自身的价值（Value）作为输出。那么为了保证端到端的流畅输入与输出，我们就需要在其内部提供一整套完备的理论指导与实践方法。理论指导可以分为强制 性 的 指 导 原 则（Guiding principles）和建议性的（或者说需要通过协调来实现的）治理规范（Governance）。业界有着许多大家屡试不爽的实践（Practices）方法。面 对 这 些 类 似“超 市货架上的商品”，我们需要通 过 服 务 价 值 链（Service value chain）的 形 式 采 取灵活组合，并配上具体的操作与实施。同时，对于那些实施效果的欠妥之处，则需要通过持续改进（Continual improvement）来不断完善和自身增值，如图 1 所示。

由图 2 可知，服务价值链（SVC）是 服 务 价 值 系 统（SVS）的核心。那么怎么来理解这个所谓的 SVC 呢？按照 Foundation 给 定 的 逻 辑图，它是由九个环节所组成，分 别 是 ：需 求（Demand）、参与（Engage）、计 划（Plan）、设 计 与 转 化（Design and transition）、获 得 与 构 建（Obtain / build）、交付与支持（Deliver and support）、改进（Improve）、产品与服务（Products and services）、以及价值（Value）。为了方便理解和记忆，我在此运用本企业的一项新服务的推出，来详细解释 SVC 的这九个环节 ：

1. 需求

公司业务人员提出搭建并提供一个“云端在线交流与协作平台”，以供他们与客户及合作商开展业务往来，并提升随时随地能够访问与处理事务的效率。

2. 参与

该需求流转到了公司管理层的利益相关方（Stakeholder，或 称 资 方），他们根据企业整体的业务方向评估和论证该需求，并最终给出支持与否的批复。

3. 计划

公司该业务部门领导、协同 IT 管理部门以及财务和法务部门的领导进行讨论、分析与计划，重点包括 ：

（1）该平台需求与当前IT 架构是否存在逻辑上和业务上的重合或冲突。

（2）当前的 IT 系统是否能够提供资源，是否拥有技术储备，是否具备支持能力。当然如果缺少的话，应考虑购置。

（3）该平台成本估算，包括新建、购置、运维等方面。

（4）根据现有法规，是否存在合规方面的风险。

4. 设计与转化

成立项目组并启动项目，需求方（该业务部门人员）罗列功能性需求列表 ；实现方技术部门）人员进行需求分析和概要设计。双方共同定义产品转化目标。

5. 获得与构建

项目组技术人员通过获取相关资源，构建产品的原型，频繁与需求方进行沟通，持续开发与完善。

6. 交付和支持

技术人员向需求方提交试运行产品，并提供后续部署与使用中的故障支持。

7. 改进

在试运行期间，技术开发部门收集平台的缺陷反馈，并持续进行改进与迭代。根据敏捷的概念，这会是一个长期且循环的过程。

8. 产品与服务

技术开发部门提供培训与文档，通过“建转运”的过程，让 IT 运维部门接手该平台，并继续提供相应的服务。

9. 价值

该平台发挥其既定的作用，并体现系统服务的目标价值。再来看看组成管理架构的具体要点。这里涉及到了一共三个大类、三十四种管理实践。它们就像积木一样，可以方便我们自由拼装与组合，以实现各种特定价值的交付。下面将从原文基础要点、笔者解读以及企业实务三个维度逐一展开。通用管理实践此部分由于有一定通用性，因此所涉及到的实践比较偏向于企业宏观层面，统领后面的各项 IT 服务与技术。

架构管理

基础要点

1. 提供不同元素的相互关联，以结构化和敏捷的方式管理复杂的变更。

2. 系统要变得高效、自动、以及有“弹性”。

3. 完整的体系结构管理包括 ：业务、服务、信息、技术和环境。

解读

针对上述要求，我们应当先后开展访用户、钻机房、登设备、查线路、测数据等“摸爬滚打”式的清查活动，厘清本企业当前所使用的 IT 服务系统、以及里面牵扯到的各种元素。当然也不要忘记了与人员相关的组织架构，我们会在后面涉及到此方面的管理。总的说来，就是要“绘制”各种关系图。其中，我们在统计造册如下清单时，应特别注意 ：

1. 硬件设备清单，体现 ：品牌、型号、序列号、MAC 地址、IP 地址、操作系统、固件版本、以及 BIOS等异构特性，同时按需说明兼容性以及备件等配套信息。

2. 软件服务清单，可以按照主营业务、办公邮件、电话通讯、服务台、用户桌面、文档协作、会议视频、IT 工具、以及云端虚拟化等领域进行划分。其中，

（1）如果是成品购置的软件，应体现 ：软件名称、开发商 / 提供商 / 经销商、激活代码 / 序列号、序列号的转移方式、安装程序的位置。

（2）如果是二次开发的软件，应识别 ：应用场景与逻辑位置、当前用到的功能模块、配套日志的路径、以及调用依赖性等信息。

3. 人员架构图表，考虑到人员的流动性，我们只需落实到角色，并按照他们具有的访问权限、以及所对应负责的软硬件模块，整理出树形结构便可。

4. 规章制度清单，包括 ：企业对于社交 / 即时通讯软件的使用规则与态度，对于数据与信息的发布 / 转发 /披露等方面的监控与限制策略。

上面收集并总结是一些“静态”的数据资料，可是在企业实务中，光凭这些是远远不够的。下面我们来进一步梳理并归纳出三种“动态”的图表关系。它们分别是 ：

系统逻辑框架图、网络架构图和应用之间数据流转图。这些图表可以清晰地定义出 ：何种类型的数据将会在逻辑上或物理上被存储在何处，它们在组织 / 系统间如何进行流动，以及它们受了何种方式的管理和保护等。

实务

那么在企业具体实操中，我们可以借鉴如下方面 ：

1. 采取画思维导图、分层 / 分级、以及局部细化的方式逐一完善。

2. 在填写清单里的具体内容之前，需要 IT 管理层对清单里的条目分类进行事先定义，以便按图索骥、生成的清单才能够更加具有参照性和条理性。

3. 考虑到填表人个人理解的不同，应当鼓励他们在“注释和状态”栏中留下原始的描述信息。通过上述结构的梳理，我们基本能够草拟出一套基于系统“画像”的服务状态基线。籍此，我们便能够轻松地发现某些服务在效率、自动化、以及鲁棒性方面的缺失与不足，进而着手予以改进。针对上述要点中“完整的体系结构管理”所涉及的五个方面，我们可以理解为 ：

业务 ：在企业层面上，我们想为“客户”做什么。

服务 ：基于现有业务，我们拥有什么、以及能够提供什么样的服务。

信息 ：从 IT 服务角度出发，我们能给用户提供什么。

技术 ：在 IT 能力层面上，我们拥有和维护着什么样的技术架构。

环境 ：面对审计和外部环境，我们需要遵守哪些法律法规，如 ：通用数据保护条例（GDPR）或《网络安全法》。

持续改进

基础要点

1. 通过 SWOT 分析，评估当前状态，淘汰旧的方法，采用 DevOps 方法确保改进。

2. 在组织内每个人、以及外部供应商与承包商的合同中鼓励为持续改进做出贡献。

3. 对内设置改进协调员、导师岗位 ；对外为改进实践提供数据源与分析支持。

解读