是一个介绍如何利用思科先进技术解决客户难题的栏目。每期聚焦一个技术热点或应用场景，邀请资深思科技术专家深入浅出地介绍，为读者提供实用性强的建议。

　　上一期我们谈到 IT 即服务（ITaaS）转型能够帮助弥合由非服务化的 IT 造成的技术与业务间的鸿沟，并绘制了一张转型前后的 “ 效果图 ” 。在图中我们看到一套严密的服务交付系统有效地把业务流程各个环节与原先竖井化的 IT 运营资源联系起来，让企业各个利益相关方能够从提升最终业务成果的视角定量化地就 IT 服务的绩效、成本和未来 IT 能力规划进行充分沟通、达成共识，共同推进数字化转型的发展。从本期开始我们来看看这样的转型应当如何完成。

　　要设计一套联接业务和 IT 能力的服务交付系统，首先要进行端到端的服务分类和交付框架设计，然后制定和测量服务绩效、服务成本，并依据 ITaaS 模型框架实现服务价值和业务成果的关联，这个过程需要建设一支与原有组织架构并行的虚拟团队 —— IT 服务交付团队，并在他们的带领下，重塑一种以服务为中心的 IT 文化，比如业务成果驱动型的 IT，以服务使用者为中心的价值评估，以定量化指标作为策略参考等等。下面是思科自身 ITaaS 转型的大致时间表：

　

　　首先是 ITaaS 的启动和规划阶段，各方需清楚地了解 IT 服务交付的现状，规划出理想的目标转型模式。

　　ITaaS 转型阶段 1 则是整个转型工作最核心的设计阶段，该阶段需要设计出转型工作的主要工件，最终将工件组合成 “ 服务组合 ”（Service Portfolio），并完成与之相适配的服务交付团队的角色设定，具体包括企业技术能力映射图（ETC）和数据引擎设计，服务分类系统设计，服务组合设计，服务交付角色和职责设计等等，详细的设计方法、策略考量和最佳实践可参阅《ITaaS 框架完全指南》[1] 。下面我们简单地了解一下这些工件的设计为何能帮助我们构建一套 ITaaS 的服务交付系统。

　　首先需要明确所谓 IT 服务是指 IT 为支持业务成果和为企业创造价值而交付的技术能力或其对应技术成果的逻辑集合。而传统的 IT 能力之所以不是服务化的，就是它们往往是下图这样的供应模式：

　　

　　这种模式使得 IT 能力所服务的客户看到的是许多独立的技术 “ 竖井 ” ，而不是一个统一的服务提供者，一方面外界缺乏对技术架构如何支持业务成果或为企业创造价值的可见性，另一方面也没有可用的解决方案来全面衡量性能和成本，同时也无法评估 IT 支持工作的最终价值。

　　

　　客户看到的是针对特定业务目标的 IT 能力的逻辑抽象（即特定的 IT 服务），具备有机的层级结构，将业务对 IT 能力的需求与实际的 IT 服务功能（以及它们背后的 IT 资产）连接起来。抽象后的 IT 服务非常适合实现服务负责人制，该负责人具备业务利益相关方的业务流程、业务目标和发展优先级等业务知识，在服务交付中会依据之前的框架在整个 IT 组织中持续推动服务交付，维护多方交流的平台以实现服务绩效和成本评估，协调资源实现服务质量保证，担当业务发展的可信顾问。

　　这一抽象层的构建需要首先梳理出企业技术能力映射图（ETC），一般是通过高阶的 “ 三线 ” 梳理法形成技术基础类、企业用户类、业务运营类等不同类别的技术能力列表和相关的上下文数据集。整个过程可以清晰地记录和梳理出企业所需的所有技术能力，它们将构成 IT 服务和服务链的雏形。ETC 梳理还能对当前的运营模式做出优化甚至一些创新，获得行业内新的竞争优势；能够定位出那些由不同 IT 资产提供的重复 IT 能力，避免低效冗余的重复建设；同时还让 IT 服务转型团队从一开始就能与业务团队紧密合作，为将来成为业务部门的 “ 可信顾问 ” 打下基础。

　　ETC 的输出还不是 ITaaS 所定义的 IT 服务，而是要在 ETC 的基础上通过服务交付分类系统（Service Delivery Taxonomy）方法的梳理，形成具备丰富上下文的 IT 能力相关数据，一个 ITaaS 的服务才被初步确立。下面就是服务交付分类系统的定义和例子：

　　

　　

　　我们将 ETC 梳理出的 IT 能力向上按业务分类和企业战略进行聚合，一方面确保服务与企业业务和战略所需的技术能力相一致；另一方面为 IT 能力开辟出业务架构和企业战略层面的视角和基准点。我们还将 IT 能力向下梳理出不同类别或 “ 风味 ”（Service Offering），一方面便于把相应 IT 能力精确的定位到 IT 资产（Service Asset）；另一方面再次保证跨职能/组织的 IT 能力中那些重复或低效占用 IT 资产的现象能被发现并被优化。这种层级化的 IT 服务上下文为从不同利益相关方的不同战略高度看 IT 能力确立了相应的基准点，比如从各级业务领导/IT 经理的看板如何设计，业务开发部门、IT 架构师和运维工程师的看板如何设计，到不同级别的成本核算、服务绩效、服务价值和治理效果的评估等等都依托于这些有机的层次架构之上。

　　在完全梳理出这些 IT 能力的上下文之后，我们按企业战略，结合咨询团队的行业经验和最佳实践，自顶而下定义出该项服务与其他服务的关系，即所谓的 “ 服务链 ” ，最终将这些数据综合形成服务组合（Service Portfolio），这才是完整的服务设计。

　　下面所示的服务链中每一项服务都需要带有一套自身完整的服务组合。

　

　　每项服务都有一个虚拟的服务交付团队，人员可以和 IT 组织的现有职位重叠，团队不同角色在服务分类系统的不同级别发挥着相应层面的关键作用，如下图所示：

　　其中服务负责人是实现 ITaaS 服务与业务成果一致化的关键角色，他们要从业务视角了解技术能力如何影响业务成果，构建服务的总拥有成本评估体系并不断寻找降低总拥有成本的机会，确立技术指标与业务成果的关系并推动服务绩效达到目标，在整个跨部门服务图景中定位技术能力的可复用机会，维护技术能力未来发展路线，构建和呈现对服务的评审报告。这些都需要他们来协调各方资源坐在一起多次沟通，共同推进该项服务的交付和业务价值的体现。而在其中最关键的就是如何协调各方对服务的成本和绩效达成一致，并借此定位关键环节，推动一系列措施优化成本、改善绩效并最大化提升服务所关联的业务成果。在大型企业的复杂 IT 组织中多部门利益纠缠，对服务的成本绩效达成一致意见是非常困难的事情。但如果借助全栈可观察的工具（Full Stack Observability，FSO），IT 部门可以提供强大的数据依据和智能分析，让各利益相关方有一个公共认可的事实基础，从而可以更好地辅助发现这些关键点、形成关键措施，最终为服务交付系统的良性运转、业务成果的最大化创造条件。

　　下一期我们就将看到在服务转型下一阶段中，FSO 是如何在服务绩效成本评估、关键环节定位、改善措施发现上发挥决定作用，让阶段 2 的服务试点乃至阶段 3 的端到端 ITaaS 服务全面交付得以顺利开展。
　　作者：魏航 思科首席架构师