Wiki source code of 别把BRM当“传话筒”:ITIL v5 里关系管理的价值,是把误解成本降到最低
Last modified by superadmin on 2026/02/20, 07:02
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
| |
1.1 | 1 | 很多组织一听“关系管理”就容易走偏: |
| 2 | |||
| 3 | 要么觉得是搞人情、做润滑; | ||
| 4 | |||
| 5 | 要么把业务关系经理 (BRM) 当成传话筒——业务提需求,他转给IT;IT问问题,他再去追业务。最后BRM忙得要命,但双方还是互相抱怨:业务觉得IT慢,IT觉得业务不讲清楚。 | ||
| 6 | |||
| 7 | |||
| 8 | 可你仔细想想,真正让组织慢下来的,往往不是技术难度,而是误解成本: | ||
| 9 | |||
| 10 | • 业务需求没讲清,来回澄清一个月 | ||
| 11 | |||
| 12 | • 目标不一致,做出来又推翻重来 | ||
| 13 | |||
| 14 | • 优先级争夺,谁都觉得自己最急 | ||
| 15 | |||
| 16 | • 变更频繁,支持口径混乱,客户体验崩 | ||
| 17 | |||
| 18 | 这些成本不在代码里,在沟通里,在协作里,在对齐里。 | ||
| 19 | |||
| 20 | |||
| |
4.1 | 21 | ITIL 第5版把管理对象扩展到数字产品与数字服务,强调体验、治理、问责与全生命周期八个阶段活动。 放到关系管理实践上,它其实在强调:关系管理不是社交,是一种管理能力;BRM不是传话筒,而是把两套语言翻译成一套行动的人。 做得好,组织速度会更快,冲突会更少,信任会更稳。 |
| |
1.1 | 22 | |
| 23 | |||
| 24 | == 一、为什么第5版更需要关系管理 == | ||
| 25 | |||
| 26 | |||
| 27 | ITIL 第5版相对 ITIL 4 的核心升级要点如下: | ||
| 28 | |||
| 29 | • 管理对象从服务扩展到数字产品与数字服务 | ||
| 30 | |||
| 31 | • 八个阶段活动的全生命周期:发现、设计、获取、构建、转换、运营、交付、支持 | ||
| 32 | |||
| 33 | • 体验写入价值定义,强调可感知的结果与信任 | ||
| 34 | |||
| 35 | • 治理强调授权、问责、可审计性与纠偏 | ||
| 36 | |||
| 37 | • 人工智能与自动化纳入体系,变化更快、依赖更深 | ||
| 38 | |||
| |
4.1 | 39 | 变化更快意味着沟通更密集;依赖更深意味着跨团队协作更多;体验更重要意味着信息透明、节奏可预测更关键。 你如果没有一套稳定的关系管理机制,组织就会在误解、冲突和反复中消耗掉所有敏捷性。 |
| |
1.1 | 40 | |
| 41 | |||
| 42 | == 二、关系管理到底管什么:管“期望”,管“边界”,管“节奏” == | ||
| 43 | |||
| 44 | |||
| |
4.1 | 45 | (% style="text-align:center" %) |
| 46 | [[image:3.jpg||height="288" width="558"]] | ||
| |
1.1 | 47 | |
| 48 | 关系管理实践不是维护感情,它至少要把三件事管住: | ||
| 49 | |||
| 50 | **• 客户期望(客户期望)** | ||
| 51 | |||
| 52 | 客户真正期待的是什么?速度?稳定?可预测?透明?你得把期望讲清楚,否则后面全是抱怨。 | ||
| 53 | |||
| 54 | **• 边界(边界)** | ||
| 55 | |||
| |
4.1 | 56 | 哪些是服务提供方能承诺的,哪些需要客户组织配合,哪些是第三方依赖。 边界不清,冲突必然发生。 |
| |
1.1 | 57 | |
| 58 | **• 节奏(循环/终止)** | ||
| 59 | |||
| |
4.1 | 60 | 什么时候评审、什么时候沟通、什么时候调整优先级、什么时候对外发布变化。 节奏不稳,体验一定差。 |
| |
1.1 | 61 | |
| 62 | |||
| 63 | BRM的价值,就在于把这三件事做成可持续的机制,而不是靠个人关系硬扛。 | ||
| 64 | |||
| 65 | |||
| 66 | == 三、BRM的核心角色:翻译器 + 节奏管理者 == | ||
| 67 | |||
| 68 | |||
| 69 | 我更愿意把BRM理解成两种角色的结合。 | ||
| 70 | |||
| 71 | 1. ((( | ||
| |
4.1 | 72 | **翻译器:把业务语言翻译成可交付的承诺** 业务说“我要快”,IT要追问“快到什么程度、代价是什么”; 业务说“我要稳定”,IT要追问“稳定到什么程度、牺牲什么速度”;业务说“我要体验好”,IT要追问“哪些接触点最关键、如何度量”。 |
| |
1.1 | 73 | ))) |
| 74 | |||
| 75 | BRM的工作不是“把话传过去”,而是把话翻译成双方都认可的协议(agreement):可度量、可执行、可审计。 | ||
| 76 | |||
| 77 | 1. ((( | ||
| |
4.1 | 78 | **节奏管理者:让沟通和决策不靠临时会议** 很多组织的沟通节奏是事故驱动的:平时不说,一出事就开会。 BRM要做的是建立固定节奏:服务评审、需求评审、路线图评审、服务级别评审,让“保持一致”变成日常经营(BAU),而不是应急状态。 |
| |
1.1 | 79 | ))) |
| 80 | 1. ((( | ||
| 81 | |||
| 82 | ))) | ||
| 83 | |||
| 84 | == 四、把关系管理放进八个阶段活动:BRM不只活在“需求阶段” == | ||
| 85 | |||
| 86 | |||
| 87 | 很多人以为BRM只在发现阶段出现,其实第5版的全生命周期告诉你:BRM应该贯穿多段活动。 | ||
| 88 | |||
| 89 | |||
| |
4.1 | 90 | |
| 91 | (% style="text-align:center" %) | ||
| 92 | [[image:24aedefb-807d-4428-a4dd-4896fcd694f9.jpg||height="126" width="541"]] | ||
| 93 | |||
| 94 | |||
| |
1.1 | 95 | **发现:把“愿景是什么”说清楚** |
| 96 | |||
| 97 | • 业务目标与业务需求是否明确 | ||
| 98 | |||
| 99 | • 关键业务功能与关键成果(结果)是什么 | ||
| 100 | |||
| 101 | • 价值判断与优先级排序的规则是什么 | ||
| 102 | |||
| 103 | |||
| 104 | **设计:把“取舍”提前讲清楚** | ||
| 105 | |||
| 106 | • 体验优先还是速度优先 | ||
| 107 | |||
| 108 | • 风险偏好是什么 | ||
| 109 | |||
| 110 | • 验收标准怎么定 | ||
| 111 | |||
| 112 | BRM要把这些取舍讲清楚,否则后面就是不断返工。 | ||
| 113 | |||
| 114 | |||
| 115 | **构建与转换:把“变化”讲明白** | ||
| 116 | |||
| 117 | • 发布节奏与变更日程对齐 | ||
| 118 | |||
| 119 | • 影响说明、绕行方案、支持口径提前准备 | ||
| 120 | |||
| 121 | • 关键利益相关方参与到转换准备中 | ||
| 122 | |||
| 123 | 这一步做不好,用户体验最容易崩。 | ||
| 124 | |||
| 125 | |||
| 126 | **运营与支持:把“问题与改进”变成共同议题** | ||
| 127 | |||
| 128 | • 重大事件沟通节奏是否兑现承诺 | ||
| 129 | |||
| 130 | • 服务质量与客户满意度变化的原因是什么 | ||
| 131 | |||
| 132 | • 持续改进举措是否在推动真正变化 | ||
| 133 | |||
| 134 | 你会发现,BRM越往后介入,越容易做成“救火沟通”;越往前介入,越能减少误解成本。 | ||
| 135 | |||
| 136 | |||
| 137 | == 五、服务评审:关系管理最值钱的“固定动作” == | ||
| 138 | |||
| 139 | |||
| |
4.1 | 140 | 服务评审(service review)是关系管理实践里最容易被忽略、但最能建立信任的动作。 很多组织只在出问题时沟通,平时不沟通,这会让客户对服务的理解永远停留在情绪上。 |
| |
1.1 | 141 | |
| 142 | |||
| 143 | 一个有效的服务评审不需要很复杂,但要稳定: | ||
| 144 | |||
| |
4.1 | 145 | •** 回顾**:上周期承诺兑现了吗 |
| |
1.1 | 146 | |
| |
4.1 | 147 | •** 解释**:指标变化背后的原因是什么 |
| |
1.1 | 148 | |
| 149 | • **选择**:下周期优先级怎么调 | ||
| 150 | |||
| 151 | • **风险**:哪些风险需要提前沟通 | ||
| 152 | |||
| 153 | • **改进**:有哪些持续改进举措要落地 | ||
| 154 | |||
| 155 | 服务评审稳定了,客户期望会更可预测,冲突会更少。 | ||
| 156 | |||
| 157 | |||
| 158 | == 六、关系管理与服务级别管理:SLA要讲人话,要能驱动行动 == | ||
| 159 | |||
| 160 | |||
| |
4.1 | 161 | 关系管理实践和服务级别管理实践天然相连。 SLA写得再漂亮,如果客户听不懂、也感受不到,它就会变成扯皮工具。 |
| |
1.1 | 162 | |
| 163 | |||
| 164 | BRM在这里要做的事要明明白白: | ||
| 165 | |||
| 166 | • 把SLA从“指标条款”翻译成“承诺” | ||
| 167 | |||
| 168 | • 把关键指标和客户体验接触点对齐 | ||
| 169 | |||
| 170 | • 把偏差变成行动,而不是解释 | ||
| 171 | |||
| 172 | • 把责任边界讲清楚,避免互相甩锅 | ||
| 173 | |||
| 174 | • 让口径可审计,避免统计口径争论 | ||
| 175 | |||
| |
4.1 | 176 | SLA最终要落在工作流里:触发沟通、触发资源调整、触发改进举措。 否则它只是文件。 |
| |
1.1 | 177 | |
| 178 | |||
| 179 | == 七、协作文化不是口号:要靠“共创”来建立 == | ||
| 180 | |||
| 181 | |||
| |
4.1 | 182 | co-create(共创)对关系管理特别重要。 共创不是组织活动,而是让双方共同参与关键决策:需求定义、优先级排序、验收标准、发布节奏、风险偏好。 |
| |
1.1 | 183 | |
| 184 | |||
| 185 | 当客户组织参与共创时,发生两件事: | ||
| 186 | |||
| 187 | • 业务更理解IT的约束 | ||
| 188 | |||
| 189 | • IT更理解业务的后果 | ||
| 190 | |||
| 191 | 理解一旦建立,误解成本就会下降,冲突也会少很多。 | ||
| 192 | |||
| 193 | |||
| 194 | == 八、人工智能能帮关系管理什么:让信息更透明,让对齐更容易 == | ||
| 195 | |||
| 196 | |||
| 197 | 人工智能在关系管理里最有价值的地方,不是替你沟通,而是让信息更透明、更一致: | ||
| 198 | |||
| 199 | • 整理客户申告与投诉,提炼真实痛点 | ||
| 200 | |||
| 201 | • 生成服务评审材料草稿,保持口径一致 | ||
| 202 | |||
| 203 | • 归纳反馈回路中的高频问题,推动持续改进举措 | ||
| 204 | |||
| 205 | • 辅助预测需求峰值与风险,提前沟通 | ||
| 206 | |||
| |
4.1 | 207 | 但要记住,信任来自人对人的承诺兑现。 人工智能只能辅助信息流动,不能替代关系本身。 |
| |
1.1 | 208 | |
| 209 | |||
| 210 | 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 | ||
| 211 | |||
| 212 | |||
| 213 | 欢迎加长河老师微信achotsao,深入交流ITIL 第5版最新资讯。 |