ITSS资质申报中，组织架构图不是“画个框就完事”！

申请ITSS信息技术服务标准资质，很多企业卡在第一关——组织架构图。别小看这张图，它可不是HR做PPT时随手拉的部门树，而是评审老师打开材料后最先盯住的“关键证据页”。为什么？因为ITSS要验证的，不是你“有没有人”，而是“有没有能打仗的服务治理能力”。

这张图，得让评审一眼看懂“谁在管服务、谁在保质量”

ITSS强调“过程+人员+技术+资源”的四维协同。组织架构图必须清晰映射出服务战略层（如IT服务管理委员会）、执行层（如服务台、运维中心、知识管理组）和支撑层（如培训岗、度量分析岗）。特别注意：不能只写“技术部”“运维部”这种泛称，要体现ITSS要求的职能角色，比如“服务级别经理”“问题管理负责人”——哪怕这个人是兼任的，也得标出来。

职责不写实，等于埋雷

我们见过太多企业把架构图画得漂亮，但一问“变更管理流程谁审批？”“SLA达成率由哪个岗位统计分析？”答不上来。评审老师会顺着架构图往下挖：每个关键岗位是否明确服务生命周期中的职责？有没有跨部门协作接口？比如配置管理员既要对接运维工程师，也要向服务改进组输出CMDB数据——这些协作关系，建议用虚线+简短标注在图上呈现，比干巴巴列一堆岗位名更有说服力。

小心！三个常见“减分坑”

• ❌ 只有行政汇报线，没有服务治理线（比如缺了服务改进小组向管理层的独立汇报路径）；
• ❌ 把外包人员全画成“外部合作方”，却没说明其在服务链中的具体权责（ITSS允许外包，但必须可控可追溯）；
• ❌ 岗位名称高大上，实际无人专职——评审会查劳动合同、岗位说明书、近半年工作记录，图和实际对不上，直接质疑体系运行真实性。

在九蚂蚁，我们帮上百家企业打磨过ITSS申报材料。真正过关的架构图，从来不是“画出来”的，而是“跑出来”的——它源于你日常服务会议的纪要、流程RACI表、甚至一次重大故障复盘的责任分工。如果你还在纠结“怎么画才像样”，不如先问问自己：今天的服务改进，到底是谁在推？

毕竟，ITSS认证要的不是一张漂亮的组织图，而是一个真实运转、责任落地的服务引擎。