# ITSS服务目录建设实战：让IT不再是隐形部门

Last modified by superadmin on 2025/12/04, 17:31
Export
Office Formats
Export as PDF Export as ODT Export as RTF
Other Formats

Select the pages to export:

select all/ none

Legend:
  Created Page
  Modified Extension Page
  Clean Extension Page

Export as HTML

那天的场景，我到现在都记得。

季度经营会上，业务总监突然抛出一个问题：

> “你们IT到底提供了哪些服务？我们花了几百万，到底买到了什么价值？”

那一刻，会议室空气凝固。

没人能立刻回答。

运维主管低着头翻报告，开发经理解释说“我们保证系统稳定”，但业务总监打断他：“稳定是你们的职责，不是服务！”

会议结束后，我在电梯里听到那位总监对别人说——

“IT就像空气，花钱多，却看不见。”

那句话，像针一样扎进我心里。

#### 一、冲突：当IT部门成了“隐形人”

那家公司并不差，IT预算在行业内属于中上水平。

他们有完善的机房、有监控系统、有工单平台、有流程制度——

唯一没有的，就是“服务目录”。

业务不知道IT能提供什么，

IT也不知道自己该被如何衡量。

每当出现问题，IT总在被动应付：“你们不是该负责这个吗？”

但没人说得清，“这个”是什么。

我后来统计了一下，他们的IT部门一年内处理的业务需求超过一千条，

其中有40%其实不属于IT职责范畴：

市场部让IT做表单、HR要做培训打卡系统、财务要求开发汇率脚本......

每个部门都把IT当万能接口用。

ITSS标准里有一句话我特别认同：

> “服务目录的建设，是IT部门从‘执行型’向‘服务型’转变的起点。”

但在没有服务目录的组织里，IT只能永远待在暗处，

做再多，也没人知道他们到底创造了什么。

#### 二、剖析：缺服务目录的三个“隐性成本”

我后来做了一次内部复盘，把问题拆成三个层面。

1. 价值感缺失 业务方看不见IT的成果，只能凭印象判断“效率低”“不懂业务”。这就像餐厅没菜单，顾客永远觉得菜贵。

2. 资源失衡 因为没有统一服务定义，资源被各种临时需求分散。研发在做报表脚本，运维在帮市场部修打印机。真正战略性的IT建设项目反而没人推进。

3. 沟通断层 没有服务边界，沟通永远陷入扯皮。业务认为“我提了需求你就该做”， IT认为“你没走流程我就不能动”。久而久之，双方都开始失望。

那时候我突然明白，ITSS里看似“抽象”的服务目录，其实是解决信任问题的武器。只有让服务看得见、说得清、可计量， IT才配被称作“服务组织”。

#### 三、建设：让IT的价值一目了然

我决定亲自带团队重建他们的服务目录体系。

这次不请外包顾问，也不先写标准文档，

我们从“人”和“业务语言”出发。

1. 梳理“我们到底在干什么” 我让每个小组列出自己过去三个月的所有工作项—— 不论是维护、支持、开发、优化，全部列出来。一共收上来642条记录。我们发现80%的工作都属于“无名劳动”， 比如“系统优化”“配置调整”“临时支持”。没人知道这些活对应哪项服务，更谈不上评估价值。

2. 重新定义服务项 我们按ITSS框架将所有工作项重新归类为两层：

- 业务服务层：电商平台运维、营销系统支持、数据分析服务；

- 支撑服务层：服务器管理、账户权限、备份与恢复、网络安全。每个服务项都必须具备四个要素： 目标、范围、负责人、绩效指标。

1. 建立服务目录门户 我们用现有的服务台系统搭建了一个在线“IT服务目录门户”。所有业务人员都能在上面看到“能申请哪些服务”“如何申请”“预期时效”。我们还把SLA写成普通人能看懂的话，比如：

> “账号申请将在1个工作日内完成。” “紧急系统中断将在30分钟内响应。”

艾拓先锋组织ITSS服务项目经理培训，大家可以来课堂上跟我就这个问题深入探讨。我经常让学员们亲自体验“服务目录演练”： 让他们把自己团队的工作写成一张目录表， 结果很多人到第三行就卡住了。不是他们不会写，而是从来没认真想过—— IT到底在服务谁？

1. 对齐业务语言 在定义服务时，我们不再使用“重启、备份、运维优化”这类内部术语， 而是用业务语言描述： “网站可用性管理”“交易订单系统支持”“营销活动上线服务”。这让业务听得懂，也愿意买单。

2. 嵌入度量体系 每个服务项都绑定了指标： 请求量、响应时长、满意度、事件率。这样月度汇报不再只是“我们干了多少事”， 而是“我们服务了多少价值”。

#### 四、反转：当业务第一次说“谢谢”

服务目录上线三个月后，我们开了一个联席复盘会。

以往那种互相抱怨的场面不见了。

业务部门第一次拿着SLA报表讨论：“能不能再缩短一级支持时间？”

那一刻，我感到真正的转变——

业务开始“谈合作”，不再“发指令”。

三个月后，我们做了满意度调查，结果显示：

- 业务部门对IT满意度从62%上升到88%；

- 平均需求响应时间缩短了36%；

- 非计划性请求减少了40%。

更重要的是，管理层第一次在公司年会上表扬IT部门，

把他们列入“业务支持体系”的重要组成。

那位曾经质问我们的业务总监说：

> “现在IT像一面镜子，我们能看清自己依赖了多少技术。”

我当时笑了。

因为这就是我想要的——

IT不再是隐形人，而是被看见的合作伙伴。

#### 尾声：服务看得见，IT才有存在感

建设服务目录的过程，不是填模板，而是让组织重新认识IT。

它让团队有边界、有语言、有价值；

让业务能看到、能理解、能信任。

我经常在项目收尾会上说：

> “如果一个部门的价值要靠解释才能被理解，那说明它的服务不可见。“ 而服务不可见，IT就永远是幕后。

现在我每次回看那张服务目录图，都觉得它不像管理工具，

更像一面镜子。

镜子里映出的，是一个从“隐形”到“清晰”的IT团队。

服务看得见，IT才有存在感。

Tags:
Created by superadmin on 2025/12/04, 17:31

- Comments (0)
- Annotations (0)
- Attachments (1)
- History
- Information

粤ICP备17056641号
深圳市艾拓先锋企业管理咨询有限公司