那天的场景，我到现在都记得。
季度经营会上，业务总监突然抛出一个问题：

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

那一刻，会议室空气凝固。
没人能立刻回答。
运维主管低着头翻报告，开发经理解释说“我们保证系统稳定”，但业务总监打断他：“稳定是你们的职责，不是服务！”
会议结束后，我在电梯里听到那位总监对别人说——
“IT就像空气，花钱多，却看不见。”
那句话，像针一样扎进我心里。

---

一、冲突：当IT部门成了“隐形人”
那家公司并不差，IT预算在行业内属于中上水平。
他们有完善的机房、有监控系统、有工单平台、有流程制度——
唯一没有的，就是“服务目录”。
业务不知道IT能提供什么，
IT也不知道自己该被如何衡量。
每当出现问题，IT总在被动应付：“你们不是该负责这个吗？”
但没人说得清，“这个”是什么。
我后来统计了一下，他们的IT部门一年内处理的业务需求超过一千条，
其中有40%其实不属于IT职责范畴：
市场部让IT做表单、HR要做培训打卡系统、财务要求开发汇率脚本……
每个部门都把IT当万能接口用。
ITSS标准里有一句话我特别认同：

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

但在没有服务目录的组织里，IT只能永远待在暗处，
做再多，也没人知道他们到底创造了什么。

---

二、剖析：缺服务目录的三个“隐性成本”
我后来做了一次内部复盘，把问题拆成三个层面。

• 价值感缺失 业务方看不见IT的成果，只能凭印象判断“效率低”“不懂业务”。 这就像餐厅没菜单，顾客永远觉得菜贵。
• 资源失衡 因为没有统一服务定义，资源被各种临时需求分散。 研发在做报表脚本，运维在帮市场部修打印机。 真正战略性的IT建设项目反而没人推进。
• 沟通断层 没有服务边界，沟通永远陷入扯皮。 业务认为“我提了需求你就该做”， IT认为“你没走流程我就不能动”。 久而久之，双方都开始失望。
  

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

---

三、建设：让IT的价值一目了然
我决定亲自带团队重建他们的服务目录体系。
这次不请外包顾问，也不先写标准文档，
我们从“人”和“业务语言”出发。
1.梳理“我们到底在干什么” 我让每个小组列出自己过去三个月的所有工作项—— 不论是维护、支持、开发、优化，全部列出来。 一共收上来642条记录。 我们发现80%的工作都属于“无名劳动”， 比如“系统优化”“配置调整”“临时支持”。 没人知道这些活对应哪项服务，更谈不上评估价值。
2.重新定义服务项 我们按ITSS框架将所有工作项重新归类为两层：

• 业务服务层：电商平台运维、营销系统支持、数据分析服务；
• 支撑服务层：服务器管理、账户权限、备份与恢复、网络安全。 每个服务项都必须具备四个要素： 目标、范围、负责人、绩效指标。
  

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

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

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

• 对齐业务语言 在定义服务时，我们不再使用“重启、备份、运维优化”这类内部术语， 而是用业务语言描述： “网站可用性管理”“交易订单系统支持”“营销活动上线服务”。 这让业务听得懂，也愿意买单。
• 嵌入度量体系 每个服务项都绑定了指标： 请求量、响应时长、满意度、事件率。 这样月度汇报不再只是“我们干了多少事”， 而是“我们服务了多少价值”。
  

---

四、反转：当业务第一次说“谢谢”
服务目录上线三个月后，我们开了一个联席复盘会。
以往那种互相抱怨的场面不见了。
业务部门第一次拿着SLA报表讨论：“能不能再缩短一级支持时间？”
那一刻，我感到真正的转变——
业务开始“谈合作”，不再“发指令”。
三个月后，我们做了满意度调查，结果显示：

• 业务部门对IT满意度从62%上升到88%；
• 平均需求响应时间缩短了36%；
• 非计划性请求减少了40%。
  

更重要的是，管理层第一次在公司年会上表扬IT部门，
把他们列入“业务支持体系”的重要组成。
那位曾经质问我们的业务总监说：

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

我当时笑了。
因为这就是我想要的——
IT不再是隐形人，而是被看见的合作伙伴。

---

尾声：服务看得见，IT才有存在感
建设服务目录的过程，不是填模板，而是让组织重新认识IT。
它让团队有边界、有语言、有价值；
让业务能看到、能理解、能信任。
我经常在项目收尾会上说：

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

现在我每次回看那张服务目录图，都觉得它不像管理工具，
更像一面镜子。
镜子里映出的，是一个从“隐形”到“清晰”的IT团队。
服务看得见，IT才有存在感。

那天的场景，我到现在都记得。
季度经营会上，业务总监突然抛出一个问题：

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

那一刻，会议室空气凝固。
没人能立刻回答。
运维主管低着头翻报告，开发经理解释说“我们保证系统稳定”，但业务总监打断他：“稳定是你们的职责，不是服务！”
会议结束后，我在电梯里听到那位总监对别人说——
“IT就像空气，花钱多，却看不见。”
那句话，像针一样扎进我心里。

---

一、冲突：当IT部门成了“隐形人”
那家公司并不差，IT预算在行业内属于中上水平。
他们有完善的机房、有监控系统、有工单平台、有流程制度——
唯一没有的，就是“服务目录”。
业务不知道IT能提供什么，
IT也不知道自己该被如何衡量。
每当出现问题，IT总在被动应付：“你们不是该负责这个吗？”
但没人说得清，“这个”是什么。
我后来统计了一下，他们的IT部门一年内处理的业务需求超过一千条，
其中有40%其实不属于IT职责范畴：
市场部让IT做表单、HR要做培训打卡系统、财务要求开发汇率脚本……
每个部门都把IT当万能接口用。
ITSS标准里有一句话我特别认同：

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

但在没有服务目录的组织里，IT只能永远待在暗处，
做再多，也没人知道他们到底创造了什么。

---

二、剖析：缺服务目录的三个“隐性成本”
我后来做了一次内部复盘，把问题拆成三个层面。

• 价值感缺失 业务方看不见IT的成果，只能凭印象判断“效率低”“不懂业务”。 这就像餐厅没菜单，顾客永远觉得菜贵。
• 资源失衡 因为没有统一服务定义，资源被各种临时需求分散。 研发在做报表脚本，运维在帮市场部修打印机。 真正战略性的IT建设项目反而没人推进。
• 沟通断层 没有服务边界，沟通永远陷入扯皮。 业务认为“我提了需求你就该做”， IT认为“你没走流程我就不能动”。 久而久之，双方都开始失望。
  

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

---

三、建设：让IT的价值一目了然
我决定亲自带团队重建他们的服务目录体系。
这次不请外包顾问，也不先写标准文档，
我们从“人”和“业务语言”出发。
1.梳理“我们到底在干什么” 我让每个小组列出自己过去三个月的所有工作项—— 不论是维护、支持、开发、优化，全部列出来。 一共收上来642条记录。 我们发现80%的工作都属于“无名劳动”， 比如“系统优化”“配置调整”“临时支持”。 没人知道这些活对应哪项服务，更谈不上评估价值。
2.重新定义服务项 我们按ITSS框架将所有工作项重新归类为两层：

• 业务服务层：电商平台运维、营销系统支持、数据分析服务；
• 支撑服务层：服务器管理、账户权限、备份与恢复、网络安全。 每个服务项都必须具备四个要素： 目标、范围、负责人、绩效指标。
  

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

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

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

• 对齐业务语言 在定义服务时，我们不再使用“重启、备份、运维优化”这类内部术语， 而是用业务语言描述： “网站可用性管理”“交易订单系统支持”“营销活动上线服务”。 这让业务听得懂，也愿意买单。
• 嵌入度量体系 每个服务项都绑定了指标： 请求量、响应时长、满意度、事件率。 这样月度汇报不再只是“我们干了多少事”， 而是“我们服务了多少价值”。
  

---

四、反转：当业务第一次说“谢谢”
服务目录上线三个月后，我们开了一个联席复盘会。
以往那种互相抱怨的场面不见了。
业务部门第一次拿着SLA报表讨论：“能不能再缩短一级支持时间？”
那一刻，我感到真正的转变——
业务开始“谈合作”，不再“发指令”。
三个月后，我们做了满意度调查，结果显示：

• 业务部门对IT满意度从62%上升到88%；
• 平均需求响应时间缩短了36%；
• 非计划性请求减少了40%。
  

更重要的是，管理层第一次在公司年会上表扬IT部门，
把他们列入“业务支持体系”的重要组成。
那位曾经质问我们的业务总监说：

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

我当时笑了。
因为这就是我想要的——
IT不再是隐形人，而是被看见的合作伙伴。

---

尾声：服务看得见，IT才有存在感
建设服务目录的过程，不是填模板，而是让组织重新认识IT。
它让团队有边界、有语言、有价值；
让业务能看到、能理解、能信任。
我经常在项目收尾会上说：

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

现在我每次回看那张服务目录图，都觉得它不像管理工具，
更像一面镜子。
镜子里映出的，是一个从“隐形”到“清晰”的IT团队。
服务看得见，IT才有存在感。