Last modified by superadmin on 2026/02/20, 07:02
Show last authors
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
21 ITIL 第5版把管理对象扩展到数字产品与数字服务，强调体验、治理、问责与全生命周期八个阶段活动。 放到关系管理实践上，它其实在强调：关系管理不是社交，是一种管理能力；BRM不是传话筒，而是把两套语言翻译成一套行动的人。 做得好，组织速度会更快，冲突会更少，信任会更稳。
22
23
24 == 一、为什么第5版更需要关系管理 ==
25
26
27 ITIL 第5版相对 ITIL 4 的核心升级要点如下：
28
29 • 管理对象从服务扩展到数字产品与数字服务
30
31 • 八个阶段活动的全生命周期：发现、设计、获取、构建、转换、运营、交付、支持
32
33 • 体验写入价值定义，强调可感知的结果与信任
34
35 • 治理强调授权、问责、可审计性与纠偏
36
37 • 人工智能与自动化纳入体系，变化更快、依赖更深
38
39 变化更快意味着沟通更密集；依赖更深意味着跨团队协作更多；体验更重要意味着信息透明、节奏可预测更关键。 你如果没有一套稳定的关系管理机制，组织就会在误解、冲突和反复中消耗掉所有敏捷性。
40
41
42 == 二、关系管理到底管什么：管“期望”，管“边界”，管“节奏” ==
43
44
45 (% style="text-align:center" %)
46 [[image:3.jpg||height="288" width="558"]]
47
48 关系管理实践不是维护感情，它至少要把三件事管住：
49
50 **• 客户期望（客户期望）**
51
52 客户真正期待的是什么？速度？稳定？可预测？透明？你得把期望讲清楚，否则后面全是抱怨。
53
54 **• 边界（边界）**
55
56 哪些是服务提供方能承诺的，哪些需要客户组织配合，哪些是第三方依赖。 边界不清，冲突必然发生。
57
58 **• 节奏（循环/终止）**
59
60 什么时候评审、什么时候沟通、什么时候调整优先级、什么时候对外发布变化。 节奏不稳，体验一定差。
61
62
63 BRM的价值，就在于把这三件事做成可持续的机制，而不是靠个人关系硬扛。
64
65
66 == 三、BRM的核心角色：翻译器 + 节奏管理者 ==
67
68
69 我更愿意把BRM理解成两种角色的结合。
70
71 1. (((
72 **翻译器：把业务语言翻译成可交付的承诺** 业务说“我要快”，IT要追问“快到什么程度、代价是什么”; 业务说“我要稳定”，IT要追问“稳定到什么程度、牺牲什么速度”；业务说“我要体验好”，IT要追问“哪些接触点最关键、如何度量”。
73 )))
74
75 BRM的工作不是“把话传过去”，而是把话翻译成双方都认可的协议（agreement）：可度量、可执行、可审计。
76
77 1. (((
78 **节奏管理者：让沟通和决策不靠临时会议** 很多组织的沟通节奏是事故驱动的：平时不说，一出事就开会。 BRM要做的是建立固定节奏：服务评审、需求评审、路线图评审、服务级别评审，让“保持一致”变成日常经营（BAU），而不是应急状态。
79 )))
80 1. (((
81
82 )))
83
84 == 四、把关系管理放进八个阶段活动：BRM不只活在“需求阶段” ==
85
86
87 很多人以为BRM只在发现阶段出现，其实第5版的全生命周期告诉你：BRM应该贯穿多段活动。
88
89
90
91 (% style="text-align:center" %)
92 [[image:24aedefb-807d-4428-a4dd-4896fcd694f9.jpg||height="126" width="541"]]
93
94
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
140 服务评审（service review）是关系管理实践里最容易被忽略、但最能建立信任的动作。 很多组织只在出问题时沟通，平时不沟通，这会让客户对服务的理解永远停留在情绪上。
141
142
143 一个有效的服务评审不需要很复杂，但要稳定：
144
145 •** 回顾**：上周期承诺兑现了吗
146
147 •** 解释**：指标变化背后的原因是什么
148
149 • **选择**：下周期优先级怎么调
150
151 • **风险**：哪些风险需要提前沟通
152
153 • **改进**：有哪些持续改进举措要落地
154
155 服务评审稳定了，客户期望会更可预测，冲突会更少。
156
157
158 == 六、关系管理与服务级别管理：SLA要讲人话，要能驱动行动 ==
159
160
161 关系管理实践和服务级别管理实践天然相连。 SLA写得再漂亮，如果客户听不懂、也感受不到，它就会变成扯皮工具。
162
163
164 BRM在这里要做的事要明明白白：
165
166 • 把SLA从“指标条款”翻译成“承诺”
167
168 • 把关键指标和客户体验接触点对齐
169
170 • 把偏差变成行动，而不是解释
171
172 • 把责任边界讲清楚，避免互相甩锅
173
174 • 让口径可审计，避免统计口径争论
175
176 SLA最终要落在工作流里：触发沟通、触发资源调整、触发改进举措。 否则它只是文件。
177
178
179 == 七、协作文化不是口号：要靠“共创”来建立 ==
180
181
182 co-create（共创）对关系管理特别重要。 共创不是组织活动，而是让双方共同参与关键决策：需求定义、优先级排序、验收标准、发布节奏、风险偏好。
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
207 但要记住，信任来自人对人的承诺兑现。 人工智能只能辅助信息流动，不能替代关系本身。
208
209
210 2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
211
212
213 欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。
深圳市艾拓先锋企业管理咨询有限公司