Last modified by superadmin on 2025/12/04, 17:31
Hide last authors
superadmin 2.1 1 那天的场景，我到现在都记得。
2
3 季度经营会上，业务总监突然抛出一个问题：
4
5 >“你们IT到底提供了哪些服务？我们花了几百万，到底买到了什么价值？”
6
7 那一刻，会议室空气凝固。
8
9 没人能立刻回答。
10
11 运维主管低着头翻报告，开发经理解释说“我们保证系统稳定”，但业务总监打断他：“稳定是你们的职责，不是服务！”
12
13 会议结束后，我在电梯里听到那位总监对别人说——
14
15 “IT就像空气，花钱多，却看不见。”
16
17 那句话，像针一样扎进我心里。
18
19
20 [[image:微信图片_20251129143019_158_5.png]]
21
22 ----
23
24 ==== 一、冲突：当IT部门成了“隐形人” ====
25
26 那家公司并不差，IT预算在行业内属于中上水平。
27
28 他们有完善的机房、有监控系统、有工单平台、有流程制度——
29
30 唯一没有的，就是“服务目录”。
31
32 业务不知道IT能提供什么，
33
34 IT也不知道自己该被如何衡量。
35
36 每当出现问题，IT总在被动应付：“你们不是该负责这个吗？”
37
38 但没人说得清，“这个”是什么。
39
40 我后来统计了一下，他们的IT部门一年内处理的业务需求超过一千条，
41
42 其中有40%其实不属于IT职责范畴：
43
44 市场部让IT做表单、HR要做培训打卡系统、财务要求开发汇率脚本......
45
46 每个部门都把IT当万能接口用。
47
48 ITSS标准里有一句话我特别认同：
49
50 >“服务目录的建设，是IT部门从‘执行型’向‘服务型’转变的起点。”
51
52 但在没有服务目录的组织里，IT只能永远待在暗处，
53
54 做再多，也没人知道他们到底创造了什么。
55
56 ----
57
58 ==== 二、剖析：缺服务目录的三个“隐性成本” ====
59
60 我后来做了一次内部复盘，把问题拆成三个层面。
61
62 1. (((
63 **价值感缺失** 业务方看不见IT的成果，只能凭印象判断“效率低”“不懂业务”。这就像餐厅没菜单，顾客永远觉得菜贵。
64 )))
65 1. (((
66 **资源失衡** 因为没有统一服务定义，资源被各种临时需求分散。研发在做报表脚本，运维在帮市场部修打印机。真正战略性的IT建设项目反而没人推进。
67 )))
68 1. (((
69 **沟通断层** 没有服务边界，沟通永远陷入扯皮。业务认为“我提了需求你就该做”， IT认为“你没走流程我就不能动”。久而久之，双方都开始失望。
70 )))
71
72 那时候我突然明白，ITSS里看似“抽象”的服务目录，其实是**解决信任问题的武器**。只有让服务看得见、说得清、可计量， IT才配被称作“服务组织”。
73
74 ----
75
76 ==== 三、建设：让IT的价值一目了然 ====
77
78 我决定亲自带团队重建他们的服务目录体系。
79
80 这次不请外包顾问，也不先写标准文档，
81
82 我们从“人”和“业务语言”出发。
83
84 1. (((
85 **梳理“我们到底在干什么”** 我让每个小组列出自己过去三个月的所有工作项—— 不论是维护、支持、开发、优化，全部列出来。一共收上来642条记录。我们发现80%的工作都属于“无名劳动”， 比如“系统优化”“配置调整”“临时支持”。没人知道这些活对应哪项服务，更谈不上评估价值。
86 )))
87 1. (((
88 **重新定义服务项** 我们按ITSS框架将所有工作项重新归类为两层：
89 )))
90
91 * (((
92 **业务服务层**：电商平台运维、营销系统支持、数据分析服务；
93 )))
94 * (((
95 **支撑服务层**：服务器管理、账户权限、备份与恢复、网络安全。每个服务项都必须具备四个要素： 目标、范围、负责人、绩效指标。
96 )))
97
98 1. (((
99 **建立服务目录门户** 我们用现有的服务台系统搭建了一个在线“IT服务目录门户”。所有业务人员都能在上面看到“能申请哪些服务”“如何申请”“预期时效”。我们还把SLA写成普通人能看懂的话，比如：
100 )))
101
102 >“账号申请将在1个工作日内完成。” “紧急系统中断将在30分钟内响应。”
103
104 艾拓先锋组织ITSS服务项目经理培训，大家可以来课堂上跟我就这个问题深入探讨。我经常让学员们亲自体验“服务目录演练”： 让他们把自己团队的工作写成一张目录表， 结果很多人到第三行就卡住了。不是他们不会写，而是从来没认真想过—— **IT到底在服务谁？**
105
106 1. (((
107 **对齐业务语言** 在定义服务时，我们不再使用“重启、备份、运维优化”这类内部术语， 而是用业务语言描述： “网站可用性管理”“交易订单系统支持”“营销活动上线服务”。这让业务听得懂，也愿意买单。
108 )))
109 1. (((
110 **嵌入度量体系** 每个服务项都绑定了指标： 请求量、响应时长、满意度、事件率。这样月度汇报不再只是“我们干了多少事”， 而是“我们服务了多少价值”。
111 )))
112
113 ----
114
115 ==== 四、反转：当业务第一次说“谢谢” ====
116
117 服务目录上线三个月后，我们开了一个联席复盘会。
118
119 以往那种互相抱怨的场面不见了。
120
121 业务部门第一次拿着SLA报表讨论：“能不能再缩短一级支持时间？”
122
123 那一刻，我感到真正的转变——
124
125 业务开始“谈合作”，不再“发指令”。
126
127 三个月后，我们做了满意度调查，结果显示：
128
129 * (((
130 业务部门对IT满意度从62%上升到88%；
131 )))
132 * (((
133 平均需求响应时间缩短了36%；
134 )))
135 * (((
136 非计划性请求减少了40%。
137 )))
138
139 更重要的是，管理层第一次在公司年会上表扬IT部门，
140
141 把他们列入“业务支持体系”的重要组成。
142
143 那位曾经质问我们的业务总监说：
144
145 >“现在IT像一面镜子，我们能看清自己依赖了多少技术。”
146
147 我当时笑了。
148
149 因为这就是我想要的——
150
151 IT不再是隐形人，而是被看见的合作伙伴。
152
153 ----
154
155 ==== 尾声：服务看得见，IT才有存在感 ====
156
157 建设服务目录的过程，不是填模板，而是让组织重新认识IT。
158
159 它让团队有边界、有语言、有价值；
160
161 让业务能看到、能理解、能信任。
162
163 我经常在项目收尾会上说：
164
165 >“如果一个部门的价值要靠解释才能被理解，那说明它的服务不可见。“ 而服务不可见，IT就永远是幕后。
166
167 现在我每次回看那张服务目录图，都觉得它不像管理工具，
168
169 更像一面镜子。
170
171 镜子里映出的，是一个从“隐形”到“清晰”的IT团队。
172
173 服务看得见，IT才有存在感。
深圳市艾拓先锋企业管理咨询有限公司