云运营现代化之：云运营能力模型

术语

云运营 – 以业务价值输出为目标的云服务的全生命周期管理。其中包括云服务的构建、交付、运行、保障、支持以及服务的持续优化和提升。

能力模型 – 结构化的定义交付业务价值产出所需要的能力（知识、技能、经验、工具和方法），以及对这些能力的评估、分析、建设和优化的指引框架。

绩效管理 – 通过整合散落在不同地方的运行数据，对其中有效数据进行加工提炼，选择与目标相关的数据和信息，建立这些数据和信息与目标任务的映射或级联关系并设定对应的数据和信息健康范围。以此来衡量、洞察当前的运作情况，协助决策分析，辅助日常管理。

背景

在传统的IT组织架构中，IT部门主要以技术提供者身份出现，强调被动支持业务需求与运行保障。随着业务与科技的快速发展，云计算服务的不断纳入，架构层逐渐从本地化转向云化、虚拟化，应用层的应用数量激增，迭代速度加快，业务复杂度与系统架构越来越复杂，系统间关联度高，数据量呈指数级增长等变化，对现有的知识、技能和经验提出了新的挑战。

基于此，IT部门工作方式需由被动响应方式向主动运营方式转型，致力于主动利用数字化技术创造新的业务机会，从云服务的资源中寻求更多的业务突破，引领业务创新。这就要求IT部门不光要从技术提供者转变为服务提供者，还要进一步从服务提供者转变为价值中心，推动业务高质量的发展。重点是让企业更好的实现 “提升客户体验、加快业务创新交付、为运营提能增效、强化管控抑制风险” 这四个普遍被绝大多数企业认可的价值。

然而，如何把握好IT部门的运营转型，抓住关键要素，成功将企业IT引入数字化的进程又成为众多企业IT负责人的困惑。尤其是对于正在不断引入云计算来替代传统计算服务的企业，不光需要改变IT的运营模式来适应企业的数字化转型的需求，还需要在技术方案采纳，人员技能提升，企业IT文化建设，管理制度及绩效考核的设置等诸多管理和决策层面进行优化和调整。哪些需要改？有什么理由和依据？什么时候改？怎么改？有哪些依赖关系？有哪些风险和诀窍？这些疑问基本没有现成答案，甚至也缺乏国际的惯例和最佳实践。需要企业IT的核心决策团队和管理团队凭借经验和不断的试错，以业务风险为代价来趟出一条可行的路线图。

为了响应市场的这种对新形态下IT运营管理最佳实践的需求，AXELOS基于全球最佳实践ITIL V3，融入了近年来技术的发展和数字化转型以及敏捷理念的诸多特点，于2019年形成并发布了ITIL4 Foundation。目标成为新一代的IT运营国际规范。

自2019年至今，AXELOS又不断推出面向管理专业人士和战略引领者的若干最佳实践。其中包括：“创建、交付和支持”，“形成利益者价值”，“高速IT”，“引导、计划和提升”以及“数字化IT战略”五个系列的最佳实践。这些最佳实践宏观的讲述了如何有效运行新形态下的IT来满足企业内部和外部环境不断变化的要求。

另外，从ITIL4开始，ITIL提出了“服务价值系统”（SVS）这个概念。将所有企业IT看做是一个创造价值的“机器”通过“服务价值链”这个流水线形成价值流，为企业形成价值。价值链的外围通过“指导原则”，“治理管控”，“实践”和“持续提升”来赋能和支撑价值链。其中的“实践”是ITIL4最新推出的概念来取代盛行了多年的“流程”这个概念。

服务价值系统

虽然ITIL4很好的覆盖了新形势下IT在运营过程中需要关注和实操的关键要素，并且也提出了诸多的最佳实践和指导方法。但是，ITIL4在具体指导IT的运营和建设还是有一些领域无法全面满足企业IT对最佳实践的要求：

1. 全面掌握ITIL4的学习曲线高，学习成本高。多数IT从业人员没有机会完整学习ITIL4。
2. ITIL4在普适性强的同时，针对性相对较弱。宏观正确，微观缺少对实操的指导作用。
3. 针对云计算环境的运营特点谈的比较少，缺乏针对性的方案。
4. 工具和技术层面谈的少，这也是ITIL的一大“特色”。
5. 绩效管理，KPI定义覆盖不完整，向来不是ITIL的重点关注。
6. 管理是需要和文化结合的。ITIL或多或少和中国国情有偏离，重理论，轻实践。

由此，我们希望有一套运营管理的模型能够有效的指导大多数已经采纳公有云的企业来不断的优化和完善云端、或者是基于混合云环境的IT运营。这样的一套具备较强的实战性质的运营模型应具备如下特点：

1. 基于最佳实践，以确保模型能被大家认可，历久常青，而非少数人在局部环境的的经验总结。
2. 不需要目标用户花费太多的时间来学习和掌握这套方法和过程。
3. 内容支持迭代和完善，以适应不断变化的内外部环境。
4. 即拿即用，快速上手，支持裁剪。可以根据实际需要选择采纳部分或全部内容。
5. 支持全生命周期的过程管理。包括现状分析、评估、建议、方案、实现、实施后评价、验证checklist以及考核体系等。确保运营能力提升的过程完整。

云运营能力模型就是基于上述要求打造的一套面向提升云运营能力的体系化方案。

能力模型简述

云运营能力模型旨在提升云运营能力。这里涉及云运营的目标用户既包括All-In类型的云用户；也包括部分使用云技术，部分本地化计算的混合形态；还包括正在对云计算的可行性进行评估，未来计划上云的企业。为了有效完成企业IT部门的价值转换，充分实现云计算的价值，企业IT需要具备的诸多云运营能力可以归纳为以下6项云运营能力域：

管控治理能力 域： 提供利益相关者所需要的指南。帮助利益相关者了解如何制定合规要求、考核方式和管理流程。这是确保公司治理所必需的管理手段用来衡量云投资，以评估其业务成果；

运行操作能力 域： 帮助利益相关者了解如何更新必要的员工技能和组织流程，以确保在将运行迁移到云的过程中系统的健康和可靠性。使用敏捷、持续的云计算最佳实践进行运行。；

业务关系能力 域： 帮助决策者了解如何将云的运营与企业业务诉求达成一致，形成一致的价值流，以便在他们将运行迁移到云端时优化业务价值。；

平台工具能力 域： 帮助干系人了解如何更新交付和优化云解决方案和服务所需的技术手段和管理工具，使得云运营在效率和有效性两个方面都能达到预期的要求。；

安全合规能力 域： 帮忙利益相关者了解如何更新必要的员工技能和组织流程，以确保部署在云中的架构符合组织的安全控制要求、弹性和法规遵从性要求。

人员组织能力 域：提供人员发展、培训和沟通相关任务的指南。帮助利益相关者了解如何更新员工技能和组织流程，以优化和维护员工队伍，并确保在适当的时候具备相应的能力。

上述6大运营能力域的建设，需要从组织文化、流程机制、技术平台三个角度制定相应措施，比如在组织文化方面，在合规风控基础上推行敏捷文化，增加扁平化、柔性化、网格化的敏捷组织架构，打造快速响应能力；在流程机制方面，以数字化协同、数据智能、敏捷交付等数字化思维，重塑协同机制等；在技术平台方面，推动基础设施即代码、自动化运维、集中告警处理等共享能力中心的技术架构转型，建立云运营中心，一体化运维平台等技术平台。

以上6大运运营能力是云运营能力的6个领域。在实际的能力提升过程中，需要把这6项能力领域进行细化，分解到具体的能力项。在能力项这个颗粒度，就可以将能力项归属至具体的角色和工作职责，并且赋予特定的考核指标和运行指南来对该项能力进行具体的管控、指引和管理。

6大运营能力域的定义是为了更好的理解云运营能力的构成，以及将不同的管理者角色与运营能力进行关联。比如：

“管控治理”对应的主要角色包括：CIO、项目经理、企业架构师、云运营负责人；

“运行操作”对应的主要角色包括：云运行负责人，运行支持团队；

“业务关系” 对应的主要角色包括：业务经理、财务经理和投资决策团队；

“平台工具” 对应的主要角色包括：CTO、IT经理和解决方案架构师；

“安全合规” 对应的主要角色包括：CISO、信息安全经理和信息安全分析员；

“人员组织” 对应的主要角色包括：部门负责人，人力资源，核心员工

6大运运营能力域中的每项领域还可以分解为两个子域，总共12个子域。最终分解为70+个具体的能力项。能力子域在能力模型中的作用主要是起颗粒化过渡的作用，可以忽略。

云运营能力域及能力子域

70+个能力项归属与不同的能力域和能力子域，代表任何IT机构，尤其是上云的企业应该具备的IT运营能力。这70+个云运营能力的选择和定义采纳了一下几项原则，目的是为了尽可能保障覆盖的完整性和内容的权威性：

1. 能力项的数量是活动的，会根据新的发现和理解进行扩展。例如，未来必然会在平台工具领域增加新的技术环境的能力项。
2. 不同能力域中的能力项内容会有重叠，无法做到完全独立。例如，“运行操作”能力域中的“告警及监控”与“平台工具”中的“可观察能力”在概念上是有重叠的。但侧重不同。在“运行操作”域中侧重日常运行的操作过程，不涉及工具；而“可观察能力”主要体现告警和监控的现代化工具能力。因此需要在不同能力域中分别体现。
3. 能力项的选择和命名参考了ITIL4中的IT服务管理实践，参考了Cobit2019中的管理目标（MO）以及AWS的CAF模型。最终也结合了工作实践和经验分析，使得整个能力模型的结构和内容能有全球最佳实践为依据，符合公有云权威厂商的对云端运营的实践总结，还能贴合国内实际用户的现况和要求。

云运营能力项

云运营能力项按能力域及子域进行分类，罗列如下。

【管控治理能力域】

能力子域	能力项	说明
过程管控	上云策略和决策	客户选择上云的论证方法和规划。
	云运营模型优化	定义适用于业务运营模式的云运营模型。综合考虑敏态和稳态运行的双重、共存要求，稳中求敏，敏中求快。
	发布管理	有单独的流程定义，满足对软件版本的生命周期管理，包括软件质量管控，软件发布周期，软件正式公布的管理。 有单独的流程负责软件应用的正式投产，跟踪投产后软件应用的使用情况。 有适用的版本管理工具；
	变更管理	变更流程的定义和有效执行。变更的覆盖范围，变更的自动化程度。
	企业IT治理和绩效管理	具备企业IT的绩效考核机制
	持续完善机制	企业需要形成持续完善的机制，来完善和提升企业的不同层面和不同领域的能力。IT也如此。
	AWS账户策略（Account ）	如果需要多个AWS帐户，则存在一个已定义的AWS帐户策略并实施该策略。这将使AWS帐户及其结构与业务需求保持一致。
	项目管理	项目管理的目的是确保组织中的所有项目都成功交付。这是通过计划、授权、监控和保持对项目各个方面的控制，并保持相关人员的积极性来实现的。
资源管控	运行支持内部协议（OLA）	关于服务实体提供的服务水平的内部协议。
	架构管理（EA）	架构管理实践的主要目的是提升业务应用的非功能属性的质量，提升业务应用与业务需求以及技术支撑的适用性，长期有效性以及合规性。
	服务外包和供应商管理	企业服务外包的管理和对供应商的考核
	知识管理	知识管理的目的是维护和改进整个组织中信息和知识的有效、高效和方便的使用。
	许可证管理	系统及软件许可证的使用和管理
	资源/资产/配置管理	IT资产管理实践的目的是规划和管理所有IT资产的整个生命周期，以帮助组织： 最大化价值 控制成本 管理风险 辅助决策资产的购买、再利用和报废 满足法规和合同要求。
	可用性管理	可用性管理的目的是确保服务提供商定的可用性级别，以满足客户和客户的需求。
	容量和性能管理	容量和性能管理的目的是云运营团队在适当的成本控制下满足业务对IT资源容量和性能的动态需求。
	运维数据治理	解决云维数据的若干问题，包括：信息孤岛，数据私有化，有数据不能用；数据质量低，有数据不好用；数据不知道有没有，在哪里，有数据不会用；缺少技术和服务手段，获取的过程曲折，有数据不能用；

【运行操作能力域】

能力子域	能力项	说明
日常运行	运维自动化	云端的运维自动化依赖Operation as COD 代码和脚本驱动的日常运维：资源部署，自动化事件响应，etc.
	运行指南（Playbook）	面向业务的帮助指南和有用的提示，提供告诉人们如何使用服务/解决方案的信息对服务的描述，哪些团队负责支持和交付服务，以及到其他支持文档的链接
	操作指南（Runbook）	记录操作任务和程序，以使所有需要这样做的团队能够有效地支持系统。
	服务请求响应	最终用户可以请求的项目，作为整个服务请求履行过程的一部分，应该发布并提供。 应定义目录项并将其添加到相应的工具集，并定义其供应工作流。
	资源交付和回收	云资源交付包括通过系统console手工完成AWS资源的启停和交付，也包括以IaC的方式自动化按预定义的模版完成交付。
	补丁管理	针对系统，业务应用和云端各类需要自主维护的各项服务和平台的的补丁集中下载，分发，安装，升级，补丁版本跟踪以及补丁相关故障的处理。
	镜像管理	明确定义的镜像管理办法，包括镜像的版本管理，镜像分发，镜像更新和检查等
	备份和恢复	完成数据、系统和应用级的备份和恢复。
故障响应	日志管理	完成日志和运行数据的“采、存、管、算、用”。 通过日志和运行数据实现运维层面的业务感知，主动提升业务应用的健康。
	告警及监控	系统运行以及应用和接口的告警及监控（Event and Monitoring） 工具集用于处理/分析和显示监控数据，并从日志数据中触发或捕获事件或警报，以供进一步操作或审查。
	告警处理	对已知系统事件进行自动检测和响应，或者在响应需要手动干预的情况下，存在工作说明/运行手册。 系统具有基于告警的自愈能力
	突发事件管理	对运行环境各种类型故障的受理和处理。目标是尽快恢复由于IT故障导致的业务中断或业务性能和用户体验的影响。
	问题管理	问题管理实践的目的是通过识别事件的实际和潜在原因来降低事件发生的可能性和影响。 问题管理也可以被理解为：技术债管理，已知错误管理，不要犯同样错误。

【业务关系能力域】

能力子域	能力项	说明
规划创新	服务目标建立	确定了IT基础设施和服务的不同业务涉众，包括客户和用户，并在IT和这些涉众之间建立了关系。
	服务组合及服务目录	可以提供的服务及其所有属性已定义并更新到服务组合/目录中
	技术创新	IT被明确赋予创新的驱动力，为企业的敏捷化，企业的洞察能力，企业的数字化转型赋能。
价值交付	IT服务价值流管理	IT管理层牵头定义IT的服务价值流。分析价值流上的活动和资源，主动发现IT部门提升业务价值的机会，并向业务部门提出适当的建议，完成对IT服务的精益化管理；
	IT财务整体管理	企业IT的整体财务管理模式和规范，包括成本管理、预算管理以及收费管理。
	用户（客户）体验管理	主动化用户体验，建立与用户的各种连接，从用户故事分析、客户感知、客户沟通、服务设计等维度提升用户（客户）体验。
	服务报告	有定期阶段性的面向业务的服务报告机制
	内部收费/分摊	建立了内部收费机制；根据业务模式按比例分摊服务成本。
	总拥有成本TCO	企业对IT整体成本的计划、对比、核算和回顾。

【平台工具能力域】

能力子域	能力项	说明
展示沟通	可观察能力Observability	深入了解系统运行状况，包含监控，跟踪，指标分析等手段
	日志管理平台	集中式的日志管理，完成对所有应用和系统日志的汇总，聚合和梳理。
	服务台/呼叫中心	面向云服务消费者的集中响应和服务中心
	运行仪表盘/驾驶舱	可视化日常运行情况，洞察运行的异常，辅助故障根源的分析
	ITSM工具配置和实施	这应包括但不限于： -新服务详细信息 -配置项目 -服务级别 -所有者/解析程序组和人员
	基于服务目录的自服务管理	资源可用性通过服务目录在需要的帐户中进行控制。如果需要，可提供新的/修改的系统/服务的任何新资源或配置。门户的设置，使系统/服务的客户/消费者/用户具有自助服务功能。
	CMDB能力	具有工具层面的CMDB，支持变更管理，资源管理，故障根源分析，自动化，ROI/TCO分析
技术环境	标签管理Tagging	在编排脚本中定义和传达或建立标签标准，以确保AWS资源的标签一致。
	AIOps	云运行结合人工智能，大量替代一线运维人员的工作。通过大数据，机器学习，自动化操作等手段，持续完成对故障的监控，分析，预测、防范和自动修复。
	动态伸缩（Autoscale）	云环境资源根据预测的模型或者实际的消费增长，动态扩展资源容量。
	负载均衡	基于业务应用或者网络协议的云端负载均衡，提高容错能力。
	自动化云资源交付工具（Auto Provision/Landing Zone）	云资源交付包括通过系统console手工完成AWS资源的启停和交付，也包括以基础设施即代码（IaC）的方式自动化按预定义的模版完成交付。
	基础架构	基础设施和平台管理确保组织拥有高质量的IT基础设施，有效地满足其当前和预期的需求。“IT基础设施”作为一个概念，包括开发、测试、交付、监控、管理和支持IT服务所需的所有服务、资源、软件、网络和设施。

【安全合规能力域】

能力子域	能力项	说明
方针指引	访问控制IAM	在AWS云环境中，按照AWS的最佳实践，利用AWS IAM完成对用户账户认证和授权的管理。
	DevSecOps	“DevSecOps”是指将与安全相关的活动集成到应用程序开发和IT操作的日常工作中。安全性被构建到整个DevOps过程中，跨越文化、自动化、度量和共享（CAMS或CALMS加上Lean）四大支柱。
	漏洞及安全事件管理	可以检测应用程序和基础架构级别的漏洞（通过检测工具集扫描组件），在需要时发出警报，并进行缓解。
	安全风险管理	风险管理目的是确保企业了解并有效地处理风险。管理风险对于确保企业的可持续性和为客户共同创造价值至关重要。风险管理是所有组织活动不可分割的一部分。
	安全制度	安全制度覆盖整个企业，而不局限于IT部门。企业通过文档化的方式正式记录和发行安全政策
	企业信息安全管理	信息安全管理是在企业安全政策指导下的，针对企业信息系统的安全管理，确保信息的保密性，一致性和可访问。
	秘钥管理	针对程序级的访问，通过设置Access Key和Security Key来授权，并且利用角色Role来赋予临时的权限。
	安全补丁	对安全类补丁有单独的管理办法和流程，确保安全漏洞能通过安全补丁得到及时修复。
	日常安全操作	信息安全管理的日常执行措施和手段
	安全故障响应	突发事件响应和处理的一种类型。目标应对信息安全相关的突发事件的处理流程。
工具技术	防火墙	基于业务应用的或网络的防火墙
	IDS/IPS	入侵检测和入侵防御策略
	防病毒	系统病毒防范和病毒扫描
	操作审计	对系统及操作和访问的记录，包括人员角操作和系统调用API的操作
	多因子认证MFA	以多种方式进行身份验证，加强对登录访问人员的验证识别能力

【人员组织能力域】

能力子域	能力项	说明
岗位技能	角色和职责描述	角色和工作描述被记录在案，其中包括谁做什么和组织结构图。
	工作岗位的描述和能力矩阵	为云运营定义所需要的管理和技术岗位，包括对应的技能要求矩阵。
	员工成长和技能培训	企业内部有预定的预算和员工成长及技能培训计划
组织文化	创新和学习	企业所具备的不断吸收新技术，敢于和鼓励试错的文化。 员工普遍积极学习，掌握新技术的氛围，建立学习型组织。
	团队建设	一个正式的运营团队结构（目标云团队或CCoE）。 有效配置内部资源、托管服务提供商、外包、第三方员工扩充或基于项目的采购的计划已经确定并正在执行。
	文化建设	企业重视文化建设，有富有竞争力的企业文化和激励形成文化的机制。

【云运营能力模型体系】

云运营能力模型通过将云运营能力进行领域的划分和能力项的分解，将云运营能力分解为可以单个单位，可以独立建立、运作、交付业务价值以及完善和提升的最小单位。

为了指导这些能力的建设，需要围绕每一个能力项定义出它们的建设要素：

1. 能力基线
2. 能力评分
3. 能力绩效指标
4. 能力深探问题
5. 能力提升方案
6. 能力运行指南

以此，形成云运营能力模型的建设体系。通过体系的建立，协助云用户对当前云运营的整体能力进行全方位的评估，从而了解当前云运营能力的水平。

同时本方案还提供针对不同用户类型的建议云运营能力的目标能力基线。用户可以借助该基线和评估结果，快速获取目标基线的差距，并对照提升方案，了解需要采取的行动和需要厂商支持的内容。

自上而下的规划，自下而上的落实！

以下就能力建设要素进行说明：

【能力基线】

能力基线指企业为了满足正常的云运营所需要的基本能力水平。不同能力基线的定义就可以区别出不同规模，行业，业务模式等属性的企业应该具备的不同能力水平。

能力基线可以看做是企业提升云运营能力的首个milestone，给潜在客户一个明确的提升目标。

【能力评分】

能力评分是在建设初期或前期对企业当前云运营能力进行粗略的打分，给企业的管理者一个云能力的全局图。大致了解当前企业的云运营能力现状和短板。

打分以主观为主，参考客观数据。就像对人的能力进行评估，会参考客观数据，结合个人判断进行打分。因此，这个评分非常依赖评分人的经验和知识，有一定的宽容度。

为了减少不同评分人的打分差异，尽量以客观的方式引导打分，能力项的评分将借用CMM的成熟度模型， 基于能力的三个维度打分 ：

1. 规范：能力的完善程度和覆盖范围（覆盖人、工具、流程），也可以被看作为成熟度。

2. 效率：能力的执行顺畅度、有没有简化的空间，有没有尽可能利用工具和自动化。检验单位成本的output，对应“敏捷”和“精益”。

3. 效果：结果是否达成产出的要求，是否也业务的诉求达成一致。检验单位成本的business outcome。

如果用户对评分的准确度要求高，可以加上用户自我评分 ，结合AWS顾问的评分进行综合。

【能力绩效指标】

能力绩效指标，俗称KPI指标，可以帮助客户：

1.辅助工作任务和目标的设定，明确工作要求和检验方法，上下一心。

2.验证某项工作或决策的执行结果和效果，杜绝形式主义。

3.监督与衡量当前工作的健康度和趋势，便于及时矫正，持续改进。

4.为决策提供客观的数字作为依据，减少错误决策。

【能力深探问题】

等同于Deep Dive questionnaire，通过深探问题在访谈中作为提纲和思路，深入挖掘用户的现状和痛点。深探问题只是给AWS顾问作为参考，需要Aws顾问提前准备和加工，甚至预演。

【能力提升方案】

现有的，针对某项具体能力细分项的技术和非技术解决方案的描述。

【能力运行指南】

针对某项具体能力细分项的日常运作最佳实践指南（prescriptive guidance）

云运营能力模型的应用

云运营能力模型的定义最终目的是用之于事件，帮助企业提升云运营能力。

云运营能力的实际应用将借助服务持续提升的基本原理，通过迭代的方式，持续推进。

云运营能绩效管理指标集

企业IT的云运营是需要大量的资金投入和与业务息息相关的产出的。并且，整个运营过程充满着各种变化和决策点。因此，云运营的绩效管理不不是一个可选项，而是必须要具备的一项任务。以下我们就有效进行企业云运营绩效管理的需求、相应的绩效衡量方法和最佳实践进行介绍。希望能获得读者的共鸣并提出更多不同意见和好的建议。

除了介绍企业云运营最佳实践，在下面的章节里，我们也会列举一些具体的KPI映射至我们的云运营能力项。这些KPI可以看做是样例和参考。不同企业的不同特点必然会导致对绩效管理的不同侧重。因此，个体企业根据自身的实际情况和目标要求，独立建造符合企业自身和当前需求的KPI是必要的。在绩效管理体系建设初期，可以先参考本模型的样本KPI作为初始KPI，对某项能力进行基本的衡量。在后续的能力提升迭代过程中，需要结合企业的目标、干系人的关注、IT的任务和使命、当前指标数据的获取能力等因素对KPI指标集进行调整。包括删减、修改和增加。

首先，我们来分析企业的云运营，或者任何一项关键业务或服务的运营为什么需要进行绩效管理。绩效管理可以帮助企业：

1. 掌握当前出现的管理问题
2. 进行横向和纵向对比，了解差距
3. 获取持续完善的切入点
4. 验证工作成就
5. 加强团队协作
6. 明确并统一目标，确保步调一致
7. 具象化管理意图，减少沟通成本

然而，对绩效管理不当的使用，会适得其反。因此，基于数据的绩效管理也需要结合人工的干预，包括主动观察、定期回访、数据的横向比对、趋势分析等手段来验证绩效考核方法的合理性，并及时修正。举例说明，如果给一线技术支持人员设定故障解决的时长，一但超过特定的解决时长就作为考核一线员工的负面数据。员工一旦得知，可能会在未来处理故障的过程中想方设法提前将故障状态设置为已解决。如果考核的内容是故障出现次数，并将该指标与员工的奖惩挂钩。每次用户上报故障，员工可能在后台默默将故障解决但确在工单系统中将故障的性质设为用户误报。这些都是笔者在真实世界遇见过的情况。因此，指标不应该作为最终目标，而是对目标诸多衡量因子的其中一项而已。

另外，受到传统IT以求稳为主，“安全生产高于一切”的思维模式影响下，大多数企业IT在设计KPI指标的过程中，都以过程的规范作为考核重点。但在新IT形态下，在企业纷纷接纳敏捷方法，采用云计算来替代本地环境的过程中，规范不再是唯一的焦点。运行的效率（单位产出比），效果（业务价值输出）变得同等重要，甚至更被看重。

指标最终是给人看的。因此，每一个指标都应该有明确的受众（用户角色）。一个指标可以被多个受众所关注；一个受众当然需要关心多个指标。因此，传统的指标体系是一个矩阵：

	受众A	受众B	受众C	受众E
指标1	X
指标2	X		X
指标3		X	X
指标4	X	X		X

指标和受众映射图

通过这个图，可以将受众和指标建立多对多的关系。 这也是业界绝大多数企业采用的指标定义方法，甚至也是大量全球最佳实践的建议。

但我们认为，这样的定义过于简单粗暴，没有也无法反映出另外一个指标的重要维度：指标和企业目标，和受众关注维度的关联。由于这个维度的缺失，将导致受众面向一堆指标，困惑于这些指标对他们到底意味着什么？这些与他们各自的工作任务有哪些必然的关联？这是企业管理层经常遇到的问题，也是很多企业在进行绩效管理的推进过程中经常遇到的阻力。

有鉴于此，我们需要对绩效管理指标集中的KPI指标设计定义一些原则，来确保指标的设计科学、合理。跟重要的是，这些指标能真正派上用场。

• 指标需要反映：规范，效率，效果的其中一项或多项。

规范体现的是稳定、合规、低风险。是所有具备一定业务规模的企业都看重的运行要素。规范也可以认为是成熟度的一种。

效率体现的是敏捷、精益、快速响应。

效果体现的是运营产出物和消费者、用户的需求贴合度、对业务的促进作用。

这三者应该是指标必须能反映的，通过一组指标能均衡反映运营的总体情况。

• 指标要包含内部指标也需要包含外部指标

这里的内部指标指内部运行指标。衡量的是内部运作的健康状况。

这里的外部指标指的是从业务视角开衡量IT运行的指标。包括业务用户的体验、用户的的感受、业务的产出等。

内部指标和外部指标共同反映IT的成效。

• 指标的定义过程中需要考虑指标的可采集度，满足SMART原则。

指标最终需要通过运行数据来反映。个别指标可以通过人工的方式，以问卷、主观判断、人为推导等方法来获取。但绩效指标应该更多是以客观的数据来衡量。

因此，在设计指标的时候要同时考虑数据从哪里获取？能否获取？是否涉敏？保密性要求？是否需要建立一套流程或平台来获取数据？

• KPI指标是来验证判断和掌握基本情况的，如果作为目标要求需要谨慎。

KPI指标的本意是用来对某项既定目标的达成情况，过程情况进行衡量，从而对工作起到辅助指导的作用。KPI的达成不能等同于目标达成。因此，KPI不能成为工作的目标，而是对工作目标的多种客观和主观衡量方式的一部分。

• 如果拿KPI指标来考核人员绩效并与奖惩挂钩，需要额外慎重，并且不能依赖个别指标。建议采纳平衡记分卡的方式来综合考核。

更多建议用KPI来衡量工作任务的达成情况，并通过人员和工作任务的关联来间接反映人员的绩效。因为工作的主动性、责任心、协作精神、复杂度和难度、工作风险等，是很难通过KPI指标来衡量的。

• KPI指标，顾名思义，为核心绩效参数，应该直接反应目标的达成，数量不宜多。

严格意义上，KPI和指标是不同的两样东西。KPI是Key Performance Indicator（关键绩效标志），指标对应的是Metrics。KPI不一定是一个数字，但必须直接反映目标的达成情况。Metrics通常是数字，用来作为KPI的支撑依据。

• 任何KPI，必须有对应的关注群体（受众角色）

KPI是给人看的。没有人看的KPI就等同于KPI不存在。因此，在设计和定义KPI的时候要指定对应的关注群体。

• 任何KPI，必须有间接对应的企业目标（受众角色的关注维度）

KPI反映的是目标的达成。这里的目标可以是业务目标或IT目标。但无论是业务目标或是IT目标，最终必须映射到企业目标。因此，设计KPI的时候要能明确将KPI直接或间接映射（级联）至企业目标（企业的KPI）。

云运营能力的指标集设计，我们纳入了以下几个设计元素：

【受众角色】

绩效管理指标集设计的初衷是定义一套指标框架，并非包罗万象，尽善尽美的完整工具。因此，在内容方面尽可能的简明、通用、便于理解。因此，在指标的受众方面，我们定义了以下五种角色：

• CIO – I
• 产品经理 – P
• 研发VP – D
• 运行VP – O
• 云运营总监 – C

每个角色的职责不在这里赘述。角色后面的字母代表角色的缩写，方便在后面的表格中组合。

【关注维度】

每个受众角色有各自的关注维度，即这个角色的使命和工作要求。不同的企业，不同的个体，不同阶段。哪怕担当同样的岗位和角色，关注维度也会不同，关注的具体内容更加会林林总总。但这并不妨碍我们借用BSC-平衡计分卡的原则对普遍的关注维度进行归纳，来定义不同受众角色“应该关心什么”。（实际工作中，不同企业完全可根据自身情况进行小范围调整。）

这里罗列的五个受众角色皆为IT部门的角色。IT部门服务于业务部门。因此，IT部门的受众角色的关注维度应该源于业务的关注维度。

参考Cobit2019对业务目标的定义，我们可以将企业业务目标归纳为以下几项核心：

1. 有竞争力的产品和服务组合
2. 产品和业务的创新
3. 业务服务连续性和可用性
4. 业务流程成本的优化
5. 数字化转型的计划和执行
6. 以客户为中心的企业文化
7. 业务风险的管控

显然，这些目标对于结构化的梳理企业绩效稍显细碎。我们可以先依据BSC的分类法，将业务部门的目标简化浓缩为四项关注维度：

1. 用户体验 – 企业赖以生存的产品或服务的市场接受度
2. 增长创新 – 企业长期增长的能力
3. 提能增效 – 企业的节能增产，生产效率
4. 规范约束 – 企业合规和抗风险能力

这四项关注维度也基本覆盖了前面7项业务目标。

基于这四项业务的核心关注，我们可以推导出IT部门不同受众角色的关注维度如下：

• CIO – I：

I1 – IT目标与业务价值的一致

I2 – IT能力的持续提升

I3 – IT业务价值的展现

I4 – 交付质量及风险控制

• 产品经理 – P：

P1- 产品的市场成效

P2 – 产品的快速迭代

P3 – 产品的业务收益

P4 – 产品投产效率

• 研发VP – D：

D1 – 业务需求和排序

D2 – 软件开发周期

D3 – 产品研发效率（时间，成本）

D4 – 软件产品质量

• 运行VP – O：

O1 – 业务和用户满意度

O2 – 服务的持续完善

O3 –  IT资源的有效利用

O4 – 运行的合规和质量达标

• 云运营总监 – C：

C1 – 云资源和服务的快速交付

C2 – 新技术的了解和掌握

C3 –  云资源的耗费和收益

C4 – 高效运行和风险防范

以此，总共形成5X4,从I1-I4,P1-P4，D1-D4，O1-O4，C1-C4，20个关注维度，与受众角色关联，与四个业务关注维度级联。 然后，针对70+中的每一项能力定义KPI指标。每一个指标与这里的20个关注维度进行关联。 由此，就将能力模型中的能力所定义的KPI指标与不同受众及他们各自的关注维度建立了映射，也与企业业务的关注通过级联建立了关系。明确了KPI的最终价值诉求。

在定义KPI指标时，我们还考虑到KPI指标反映的情况分为两种，过去式和将来式：

• 过程（Leading ）指标：

反映某项能力的执行过程绩效，通常与该能力的目标和业务价值没有直接关系，但可以影响最终能力输出。极端情况下，指标可以很低，但实际能力确很高。衡量相对困难，但容易被影响。

• 结果（Lagging ）指标 – 评价过去：

直接反映该能力的实际效能和产出，指标直接和能力目标挂钩。容易衡量，但无法被影响。

这两种指标原则上应该同时具备，过程指标的目的是通过修正当前做法来“改变未来”；结果指标的目的是通过得知结果来“评价过去”。

下图为指标集定义的部分内容截图。

云运营能力指标集

云运营能力方案的交付

云运营能力现代化服务基于上述的企业转型需求，结合云运营模型和整合的解决方案，为客户提供服务咨询和系统化的解决方案的落地，加速客户的云运营现代化进程。

基于云运营能力模型的现代化包含以下服务包：

1. 运营能力整体评分
2. 运营能力单项分析
3. 目标运营模型设计和实施规划
4. 运营能力基线定义
5. 运营能力就绪度Checklist定义
6. 运营能力绩效管理体系设计和KPI指标设计
7. 个性花化运营能力项实施指南交付