由 superadmin 于 2026/02/20, 07:15 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 | ||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 | |||
| 6 | (% style="text-align:center" %) | ||
| 7 | [[image:1.png||height="209" width="345"]] | ||
| 8 | |||
| 9 | |||
| 10 | ITIL 第5版正式发布,这是继2019年ITIL 4之后又一次重要的框架演进。作为全球最广泛采用的IT管理框架,ITIL目前服务于超过300万持证专业人士,被82%的财富世界500强企业所采用。 | ||
| 11 | |||
| 12 | |||
| 13 | 这次升级的核心方向非常明确:AI原生、以人为本、数字产品与服务管理。 官方已经公布了完整的过渡路径:2月12日商业订购开放,2月26日Foundation Bridge接课程上线(专为ITIL 4 Foundation持证者或ITIL v3专家设计),3月至4月核心进阶模块陆续发布,预计3月中下旬完成汉化工作,第二季度AI治理深度认证课程全面上线。 | ||
| 14 | |||
| 15 | |||
| 16 | 从框架内容看,ITIL 第5版包含九个核心模块和一个AI扩展,形成了完整的认证体系。 新版本引入了全新的产品与服务生命周期模型(涵盖发现、设计、获取、构建、转换、运营、交付、支持八个活动),强化了价值系统的核心地位(包括指导原则、治理、价值链、实践、持续改进五大组件),并将AI治理、用户体验、价值流管理等现代议题从边缘提升到核心。 | ||
| 17 | |||
| 18 | |||
| 19 | 但在所有这些变化中,有一个容易被忽视却极其关键的升级:ITIL 第5版在组织和人员维度明确提出了“安全文化”的概念,并把文化和领导力的讨论提升到前所未有的高度。 今天我想跟你深入聊聊,为什么在一个讲技术和流程的管理框架中,文化和领导力变得如此重要。 | ||
| 20 | |||
| 21 | |||
| 22 | |||
| 23 | == 一个让人深思的管理困境 == | ||
| 24 | |||
| 25 | |||
| 26 | 我见过一家科技公司,他们投入巨资引入了先进的AIOps平台,能够自动监控系统状态、预测潜在故障、智能分派事件、推荐解决方案。 从技术角度看,这个平台非常优秀,在演示环境中表现完美。 | ||
| 27 | |||
| 28 | |||
| 29 | 但系统上线后,运维团队的使用率极低。 平台推荐的解决方案经常被忽略,自动分派的事件被手动改派,预警信息被当成噪音屏蔽。 管理层很困惑:明明技术这么好,为什么团队不用? | ||
| 30 | |||
| 31 | 深入调查后才发现问题的根源。 原来这个公司长期以来形成了一种“责备文化”:出了问题首先追究谁犯错就考核谁。 在这种文化下,团队成员学会了自我保护:不主动暴露问题,不轻易尝试新方法,不敢承认自己不懂。 | ||
| 32 | |||
| 33 | |||
| 34 | AIOps平台要求的是什么?是团队主动报告异常、坦诚记录失败、分享问题解决经验、持续反馈系统表现。 但在责备文化下,这些都成了“给自己找麻烦”。 如果我主动报告一个潜在风险,万一真的出问题,责任算谁的?如果我按照AI的建议操作但失败了,会不会被质疑专业能力?如果我承认某个问题我不会解决,会不会影响绩效考核? | ||
| 35 | |||
| 36 | 结果就是,技术再先进,在错误的文化土壤中也长不出好的管理实践。 这个案例深刻说明了一个道理:技术、流程、工具都是表层的,文化才是决定管理成败的深层因素。 | ||
| 37 | |||
| 38 | |||
| 39 | ITIL 第5版正是认识到了这一点,所以把文化和领导力的讨论从边缘位置提升到核心框架。 | ||
| 40 | |||
| 41 | |||
| 42 | |||
| 43 | == 安全文化:不是信息安全,而是心理安全 == | ||
| 44 | |||
| 45 | |||
| 46 | ITIL 第5版在组织和人员维度特别强调了“安全文化”,但这里的安全不是指信息安全或网络安全,而是指心理安全。 | ||
| 47 | |||
| 48 | 什么是心理安全?哈佛商学院教授艾米·埃德蒙森给出的定义是:团队成员相信在这个团队中,不会因为提出问题、承认错误、寻求帮助而受到惩罚或羞辱。 | ||
| 49 | |||
| 50 | |||
| 51 | (% style="text-align:center" %) | ||
| 52 | [[image:4.jpg||height="326" width="423"]] | ||
| 53 | |||
| 54 | 听起来很简单,但在很多组织中,心理安全是严重缺失的。 人们不敢说真话,因为害怕被批评;不敢提质疑,因为害怕被孤立;不敢承认不懂,因为害怕被看轻;不敢尝试新方法,因为害怕失败后被追责。 | ||
| 55 | |||
| 56 | |||
| 57 | 为什么ITIL 第5版要强调心理安全?因为数字化时代的工作特点决定了心理安全是管理成功的前提条件。 | ||
| 58 | |||
| 59 | **第一个原因是复杂性和不确定性大幅增加。** | ||
| 60 | |||
| 61 | **传统IT**环境相对简单,很多问题有标准答案,遵循流程就能解决。 但在数字化环境中,系统越来越复杂,技术栈越来越多样,变化越来越快,很多问题没有标准答案,需要团队协作探索、快速试错、持续学习。 如果没有心理安全,人们就不敢暴露不确定性,不敢提出不成熟的想法,不敢承认自己不知道答案。 | ||
| 62 | |||
| 63 | |||
| 64 | **第二个原因是跨职能协作成为常态。** | ||
| 65 | |||
| 66 | **过去IT**工作相对独立,开发归开发,运维归运维,各司其职。但在DevOps、敏捷、产品化的工作方式下,需要开发、运维、测试、产品、安全等多个职能紧密协作。 跨职能协作的前提是什么?是相互信任、坦诚沟通、共担风险。 如果没有心理安全,不同职能之间就会互相推诿、互相指责、互相防备。 | ||
| 67 | |||
| 68 | |||
| 69 | **第三个原因是持续改进需要主动暴露问题。** | ||
| 70 | |||
| 71 | **ITIL**第5版把持续改进作为价值系统的核心组件,但持续改进的起点是什么?是发现问题、承认问题、分析问题。 如果团队文化是“报喜不报忧”“多一事不如少一事”“出了问题找替罪羊”,持续改进就无从谈起。 | ||
| 72 | |||
| 73 | |||
| 74 | **第四个原因是AI应用需要高质量的反馈数据。** | ||
| 75 | |||
| 76 | **ITIL** 第5版强调AI原生,但AI的效果取决于什么?取决于训练数据的质量。 如果团队因为害怕被追责而隐瞒问题、美化记录、选择性报告,AI学到的就是扭曲的模式,给出的建议自然不可靠。 | ||
| 77 | |||
| 78 | 所以ITIL 第5版明确指出,建立安全文化不是软性要进、流程再完善,也很难发挥应有的效果。 | ||
| 79 | |||
| 80 | |||
| 81 | |||
| 82 | == 如何建立安全文化:从领导者的行为开始 == | ||
| 83 | |||
| 84 | |||
| 85 | 说到这里,你可能会问:道理我都懂,但怎么建立安全文化?这是不是需要很长时间的文化变革? | ||
| 86 | |||
| 87 | ITIL 第5版给出的答案是:建立安全文化确实需要时间,但起点在领导者的行为,而不是制度文件。 | ||
| 88 | |||
| 89 | |||
| 90 | **第一个关键行为是领导者如何对待错误。** | ||
| 91 | |||
| 92 | 如果一线员工犯了错误,领导者的第一反应是追究责任还是分析原因?是惩罚当事人还是改进系统?这个反应会向整个团队传递明确的信号。 | ||
| 93 | |||
| 94 | Google的SRE团队有一个著名的实践:无责事后回顾。 当发生生产事故后,团队会组织事后回顾会议,但会议的目标不是找出谁的责任,而是理解为什么会发生、如何避免再次发生。 会议记录会公开分享,让其他团队也能从中学习。 这个实践的核心理念是:系统性问题比个人错误更重要,组织学习比个人问责更有价值。 | ||
| 95 | |||
| 96 | (% style="text-align:center" %) | ||
| 97 | [[image:3.jpg||height="289" width="561"]] | ||
| 98 | |||
| 99 | ITIL 第5版建议,领导者应该把错误分为两类:系统性错误和个人疏忽。 大部分错误其实是系统性的:流程设计不合理、工具不好用、培训不充分、压力过大、信息不清晰。 对于系统性错误,应该聚焦改进系统,而不是惩罚个人。 只有极少数明显的个人疏忽(比如明知故犯、重复犯错、隐瞒问题),才需要个人问责。 | ||
| 100 | |||
| 101 | |||
| 102 | **第二个关键行为是领导者如何对待质疑。** | ||
| 103 | |||
| 104 | 当下属对决策提出质疑时,领导者是欢迎还是排斥?是认真倾听还是敷衍应对?这个反应会决定团队成员是否愿意说真话。 | ||
| 105 | |||
| 106 | 亚马逊有一个著名的领导力原则:有骨气; 坚持己见; 不同意也要执行)。 这个原则的前半句是“坚持己见”,意思是鼓励团队成员表达不同意见,即使这个意见和上级或多数人不一致。 领导者应该创造环境,让不同声音能同意见,特别是在做重大决策之前。 可以采用一些具体做法:在会议中设置“魔鬼代言人”角色,专门提出反对意见;给团队成员匿名反馈的渠道;对于提出建设性质疑的人给予认可和奖励。 | ||
| 107 | |||
| 108 | |||
| 109 | **第三个关键行为是领导者如何对待失败。** | ||
| 110 | |||
| 111 | 在创新和改进过程中,失败是不可避免的。 如果团队尝试新方法但失败了,领导者是批评“为什么不按老办法做”,还是鼓励“至少我们学到了什么”? | ||
| 112 | |||
| 113 | Netflix有一个著名的文化理念:我们鼓励快速试错,但要求从失败中学习。 他们有一个“失败庆祝”的传统:当一个实验失败了,团队会组织分享会,讲述这个实验的假设、过程、结果、教训。 这不是嘲讽失败,而是提取价值,让失败变成组织的学习资产。 | ||
| 114 | |||
| 115 | ITIL 第5版建议,领导者应该区分“好的失败”和“坏的失败”。 好的失败是基于合理假设、充分准备、快速验证的尝试;坏的失败是盲目行动、重复犯错、拒绝学习。 对于好的失败,应该鼓励和奖励;对于坏的失败,应该分析和改进。 | ||
| 116 | |||
| 117 | |||
| 118 | **第四个关键行为是领导者如何以身作则。** | ||
| 119 | |||
| 120 | 领导者自己是否愿意承认不足、寻求帮助、分享失败?这会直接影响团队的行为模式。 | ||
| 121 | |||
| 122 | 我见过一个优秀的IT总监,他在团队会议上主动分享自己犯过的错误,讲述自己不懂的技术,请教年轻工程师的建议。 最开始很惊讶,但慢慢地大家发现,原来承认不懂不是丢脸的事,请教他人是正常的事,犯错是可以被接受的。 这种行为示范比任何制度宣讲都有效。 | ||
| 123 | |||
| 124 | ITIL 第5版明确指出,安全文化的建立必须自上而下。 如果高层领导不改变行为模式,再多的文化宣传都是空谈。 | ||
| 125 | |||
| 126 | |||
| 127 | |||
| 128 | == 领导力的新内涵:从控制到赋能 == | ||
| 129 | |||
| 130 | |||
| 131 | ITIL 第5版在讨论领导力时,特别强调了一个转变:从控制型领导到赋能型领导。 | ||
| 132 | |||
| 133 | 传统的控制型领导是什么样的?领导者掌握信息、做出决策、下达指令、监督执行、检查结果。 这种领导方式的前提是领导者最懂、环境可控、变化缓慢。 | ||
| 134 | |||
| 135 | 但在数字化时代,这些前提都不成立了。 技术变化太快,领导者不可能懂所有新技术;环境充满不确定性,很多决策没有标准答案;一线团队最接近实际问题,往往比领导更清楚该怎么做。 | ||
| 136 | |||
| 137 | |||
| 138 | ITIL 第5版倡导的赋能型领导是什么样的?领导者明确目标、提供资源、授权决策、营造环境、移除障碍、促进学习。 这种领导方式的核心是激发团队的主动性和创造力,而不是控制团队的每个行动。 | ||
| 139 | |||
| 140 | |||
| 141 | 具体来说,赋能型领导有几个关键特征。 | ||
| 142 | |||
| 143 | **第一是明确目标而不是规定路径。** | ||
| 144 | |||
| 145 | 领导者应该清晰地传达要达成什么目标、为什么重要、成功的标准是什么,但给团队足够的自主权决定如何达成目标。 这种方式既保证了方向一致,又激发了团队的创造力。 | ||
| 146 | |||
| 147 | |||
| 148 | **第二是提供资源而不是微观管理。** | ||
| 149 | |||
| 150 | 领导者应该确保团队有足够的人力、工具、培训、时间来完成工作,但不要干预团队的具体工作方式。 比如,领导者可以批准培训预算、购买工具、调配人手,但不要规定团队必须用什么具体方法。 | ||
| 151 | |||
| 152 | |||
| 153 | **第三是授权决策而不是事事请示。** | ||
| 154 | |||
| 155 | 领导者应该明确团队的决策边界,在边界内充分授权。 比如,对于日常的技术选型、流程调整、问题解决,团队可以自主决策;对于涉及战略方向、重大投资、风险承担的事项,需要向上汇报。 这种分层授权既保证了效率,又控制了风险。 | ||
| 156 | |||
| 157 | |||
| 158 | **第四是营造环境而不是施加压力。** | ||
| 159 | |||
| 160 | 领导者应该建立安全文化、鼓励协作、促进学习、认可贡献,让团队在良好的环境中发挥最佳表现。 简单粗暴的压力(比如加班文化、末位淘汰)在短期可能有效,但长期会摧毁团队的创造力和士气。 | ||
| 161 | |||
| 162 | |||
| 163 | **第五是移除障碍而不是增加限制。** | ||
| 164 | |||
| 165 | 领导者应该主动发现团队面临的障碍(比如流程繁琐、工具落后、跨部门协作困难、资源不足),然后想办法移除这些障碍。 很多时候,领导者最大的价值不是告诉团队怎么做,而是帮团队扫清障碍。 | ||
| 166 | |||
| 167 | |||
| 168 | **第六是促进学习而不是惩罚失败。** | ||
| 169 | |||
| 170 | 领导者应该鼓励实验、容忍失败、提取教训、分享经验,让组织成为学习型组织。 在快速变化的环境中,学习速度往往决定竞争力。 | ||
| 171 | |||
| 172 | |||
| 173 | ITIL 第5版明确指出,赋能型领导不是放任不管,而是更高层次的领导。 它要求领导者从“控制行为”转向“影响文化”,从“管理事务”转向“培养能力”,从“个人英雄”转向“团队成功”。 | ||
| 174 | |||
| 175 | |||
| 176 | |||
| 177 | == 组织结构的适配:没有一种结构适合所有情况 == | ||
| 178 | |||
| 179 | |||
| 180 | ITIL 第5版在讨论组织和人员维度时,还特别强调了组织结构的适配性。 它明确指出,没有一种组织结构适合所有情况,关键是根据组织的战略、业务特点、发展阶段选择合适的结构。 | ||
| 181 | |||
| 182 | |||
| 183 | **职能型组织的优点是专业深度**,不同职能可以建立专业能力、积累最佳实践、形成规模效应。 但缺点是容易形成孤岛,跨职能协作困难,端到端响应慢。 | ||
| 184 | |||
| 185 | |||
| 186 | **产品型组织的优点是端到端责任**,产品团队对整个产品生命周期负责,能够快速响应市场变化。 但缺点是专业能力可能分散,不同产品团队可能重复建设,规模效应难以发挥。 | ||
| 187 | |||
| 188 | |||
| 189 | **矩阵型组织试图平衡两者**,团队成员既属于职能部门(负责专业能力建设),也属于产品团队或项目团队(负责端到端交付)。 但矩阵型组织的挑战是权责可能不清晰,员工可能面临多头领导。 | ||
| 190 | |||
| 191 | |||
| 192 | ITIL 第5版建议,组织结构应该根据情况灵活调整。 对于成熟的、标准化的业务,职能型组织可能更合适。 对于创新的、快速变化的业务,产品型组织可能更合适。 对于复杂的、多元化的组织,矩阵型结构可能是必要的权衡。 | ||
| 193 | |||
| 194 | |||
| 195 | 更重要的是,组织结构不是一成不变的。 随着业务发展、技术演进、市场变化,组织结构应该持续调整。 ITIL 第5版强调,领导者应该定期评估组织结构的有效性,识别结构性障碍,进行必要的调整。 | ||
| 196 | |||
| 197 | |||
| 198 | |||
| 199 | == 技能与能力:从个人到团队再到组织 == | ||
| 200 | |||
| 201 | |||
| 202 | ITIL 第5版在讨论技能与能力时,提出了一个三层视角:个人能力、团队能力、组织能力。 | ||
| 203 | |||
| 204 | **个人能力是基础。** | ||
| 205 | |||
| 206 | 数字化时代需要的能力越来越多元:技术能力(编程、架构、运维、安全等)、业务能力(需求理解、流程分析、价值评估等)、管理能力(项目管理、风险管理、变更管理等)、软技能(沟通、协作、问题解决、持续学习等)。 ITIL 第5版建议,组织应该建立能力模型,明确不同角色需要的能力,评估当前能力差距,制定培养计划。 | ||
| 207 | |||
| 208 | |||
| 209 | **但个人能力强不等于团队能力强。** | ||
| 210 | |||
| 211 | 团队能力取决于成员之间的协作、信任、互补。 一个由明星个人组成但缺乏协作的团队,往往不如一个成员能力中等但协作良好的团队。 ITIL 第5版建议,组织应该重视团队建设,包括明确团队目标、建立协作规范、促进信任关系、培养团队学习能力。 | ||
| 212 | |||
| 213 | |||
| 214 | **团队能力强也不等于组织能力强。** | ||
| 215 | |||
| 216 | 组织能力取决于知识如何沉淀、经验如何传承、能力如何复制。 如果关键能力只掌握在个别人手中,这些人离职后组织能力就会严重受损。 ITIL 第5版建议,组织应该建立知识管理机制,包括知识库建设、最佳实践总结、师徒传承、轮岗培养等。 | ||
| 217 | |||
| 218 | |||
| 219 | ITIL 第5版特别强调,在AI时代,组织需要培养的不只是技术能力,还包括AI协作能力:如何有效使用AI工具、如何评估AI输出质量、如何在人机协作中发挥各自优势、如何应对AI带来的工作方式变化。 这些能力将成为数字化组织的核心竞争力。 | ||
| 220 | |||
| 221 | |||
| 222 | 我最后再总结一句:ITIL 第5版把文化和领导力提升到如此重要的位置,不是为了追赶管理时尚,而是基于一个深刻的认知——在复杂多变、高度协作、持续创新的数字化时代,技术和流程只是表层工具,文化和领导力才是决定管理成败的深层因素。 建立心理安全的文化,让团队敢于暴露问题、勇于尝试创新、持续学习成长;发展赋能型的领导力,激发团队的主动性和创造力;这些才是组织长期竞争力的真正来源。 | ||
| 223 | |||
| 224 | |||
| 225 | 欢迎加长河老师微信achotsao,深入交流ITIL 第5版最新资讯。 |