Last modified by superadmin on 2025/12/04, 17:31
From version < 2.1
edited by superadmin
on 2025/12/04, 17:31
To version 1.1 >
edited by superadmin
on 2025/12/04, 17:31
Change comment: Uploaded new attachment "微信图片_20251129143019_158_5.png", version {1}

Summary

Details

Icon Page properties
Title
... ... @@ -1,1 +1,0 @@
1 -ITSS服务目录建设实战：让IT不再是隐形部门
Parent
... ... @@ -1,1 +1,0 @@
1 -长河 ITIL 4 专栏文章.长河 ITIL 4 理论学习与实战训练营.WebHome
Content
... ... @@ -1,173 +1,0 @@
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才有存在感。
深圳市艾拓先锋企业管理咨询有限公司