从调研数据到项目决策：把调查表变成实施方案
环境调查表采集的是"现状"，但它真正的价值在"决策"——每一张表都指向项目实施阶段的若干关键设计。本手册给出"表 → 决策"的转化路径，帮助甲乙双方从一堆调查数据里提炼出可执行的实施方案。
与《ITSM 现状调研手册（环境调查表）》配合阅读：那本讲"怎么填"，这本讲"填完怎么用"。
一、先定运维模式：项目的难易与定位
环境调查表①基本信息末尾的运维模式判定评分法，是项目定位的起点：
| 分值 | 模式 | 含义 | 项目定位 |
|---|---|---|---|
| 2 | 原始手工 | 纯手工运维，无工具 | 启蒙与体系化：重在搭骨架、立制度 |
| 4 | 有工具凑合 | 有简易运维工具凑合用 | 启蒙与体系化：补足工具化短板 |
| 6 | 工具运用较好 | 有运维工具且运用得比较好 | 深化与集成：流程精细化、监控告警联动 |
| 8 | 数字化萌芽 | 比较专业，数字化运维意识萌芽 | 深化与集成：补全数字化缺口 |
| 10 | 很专业 | 工具齐全、运用 水平高、战斗力强 | 优化与扩展：全链路自动化与二开 |
决策要义：≤4 分的组织，方案重点在"先立骨架"——组织、团队、流程、资产台账这些地基先夯起来，不要一上来就上复杂自动化；6~8 分侧重"深化集成"——把已有工具的数据接入 ITSM，监控告警与工单联动；10 分侧重"优化扩展"——引入高级流程、绩效考核与二开能力。
二、从①基本信息到规模基线
基本信息决定整个实施的"量级假设"：
| 调研项 | 决策落点 |
|---|---|
| 设备数量（网络/安全/服务器/数据库/中间件/存储/动环） | CMDB 分类导航、监控覆盖范围、巡检清单规模 |
| 业务系统数量 | 业务系统台账与业务拓扑的规模 |
| 服务用户数量（内/外） | 服务门户、自助服务台的并发与权限设计 |
| 工程师数量（内部/外部）、团队数量 | 组织树、人员角色组、三级支持体系、负载均衡 |
| 服务窗口时段、交付模式 | SLA 的 5*8 / 7*24 设计 |
| 业务/技术负责人、热线、邮箱、门户 | 服务台与服务门户的入口配置 |
三、从②⑥到服务目录与业务关联设计
- ② IT服务目录 → 服务目录树：按"服务包 → 服务 → SLA → 团队 → 分发 → 审批"组织。普通用户入口按"能听懂的语言"（如"电脑打不开了"），内部再按请求/事件/问题/变更细分；分发逻辑、审批逻辑按各服务实际管控需要配置。
- ⑥ 业务系统表 → 业务系统台账，作为 CMDB 核心关联单元，为每个业务系统指定默认运维支持团队与业务负责人，形成业务拓扑。有和业务系统关联的运维数据才有"共同语言"；若能再集成监控信息展示，就更有效。
服务目录是体系的核心：服务目录设计成功合理，ITSM 实施项目就成功了三分之一。详见《服务体系设计与运营》。
四、从 SLA 统计表到服务等级设计
SLA 统计表的每一条直接落到 ITSM 的 SLA 策略：
- SLA 名称：按"对象 + 等级"命名（终端/网络/业务/核心变更/VIP/财务/安全应急/外部用户）；
- 类型：
5*8/7*24决定服务窗口，对应值班排班； - 优先级：低/中/高，决定响应目标与告警 SLA 预警；
- 响应时间（分钟） 与 解决时限（小时）：分别落到响应与解决两级承诺，注意单位换算。
落地时把 SLA 关联到服务目录，作为工单时限计算与超时告警的依据。
五、从④⑤到团队与供应商体系
- ⑤ 团队信息表 → 团队台账与三级支持体系：一线/二线/三线/机动。一般团队管理者管 6~10 人，一个业务系统服务可由上限约 30 人的大团队支撑。
- ④ 供应商信息 → 供应商档案、合同管理与转派边界：按等级（一级/二级/三级/亲密伙伴/战略伙伴）分级管理，维护对象（硬件/软件/核心系统/安全/维保）决定工单转派外部供应商的范围。
注意：引入外部供应商不等于当甩手掌柜，制度、台账、工单记录仍要留在自己手里，否则等于把风险外包了一遍。
六、从⑨⑩到资产与 CMDB 底座
- ⑨ 资产表格 → CMDB 配置项与资产台账：资产分类、编码、名称、状态（使用中/已入库/维修中/借调中/已报废/待入库）、使用部门/人、维护团队/工程师、供应商/合同、位置（机房→机柜→U 位）、IP、序列号。位置信息支撑设备定位，状态与维护关系支撑资产与工单、巡检联动。
- ⑩ 配置资产统计 → 规模评估与分类导航设计：按机房统计的资产大类 数量决定 CMDB 分类导航、监控覆盖与资源投入。
CMDB 扩充认知：现代信息中心里，资产与配置树是融合的——既有配置变更，也有资产维修报废环节，是技术管理与行政管理的混合体。关键在关联视图与全局影响视图：以业务系统为单元关联各配置资源，画出业务拓扑，列出运维团队与最近工单。
七、从⑦⑧到工单流程与状态设计
- ⑦ 主要服务流程 → 工单状态机模板。七个环节（发起 → 前置审批 → 分发 → 处理 → 后置审批 → 评价 → 关闭）映射到通用工单主干节点——新建（权限审核）→ 审批 → 分发 → 处理（一线→二线→三线）→ 评价 → 关闭，再按各服务管控要求微调，不必每个服务单独设计状态机。
- ⑧ 历史工单样表 → 工单列表/详情字段设计与历史数据导入映射，支撑"先有记录、优先记录"的起步策略（事故驱动）。
流程要简化再简化：一般不超过 200 名工程师的运维环境，不需要刻意引入全功能流程引擎，简化的状态机封装即可胜任。每个服务满配"两重审批 + 三级支持体系 + 关闭控制"，6~7 个控制点即可覆盖 95% 以上的运维场景。
八、从12/13/14到运营指标与考核
- 12★ 运维统计（周工单量） → 运营中心报表口径与团队负载评估；
- 13★ 日报/周报/月报模板 → 运营报表配置；
- 14★ 绩效考核模板 → 工程师考核指标：SLA 达成率、响应时长等硬数据必须有，用户满意度等软反馈不能少，按服务特点自定义评分权重。
考核把"响应快不快、解决好不好"变成可度量、可激励的数据，支撑长期运营优化。
九、从15★到二开需求管理
二开需求表是功能差距分析的输入：逐条对照标准功能，判断"标准覆盖 / 需二开 / 后置或不做"，并据此控制项目范围与成本。二开清单不是越多越好——能通过配置（服务目录、SLA、审批流）满足的，优先用配置解决，避免为单一场景承担长期二开维护成本。
十、决策产出：一份可执行的 IT 服务战略
把上述转化结果整合成一份可执行的 IT 服务战略——落到组织、团队、流程、工具、SLA、考核六个维度的路线图，作为《ITSM 实施方法论》九环节（咨询准备 → 现状分析 → 体系规划 → 方案评审 → 实施准备 → 服务设计 → 服务实施 → 服务运营 → 服务优化）的输入。
小结：环境调查表的价值不在"填得满"，而在"能决策"。先定运维模式，再按"规模基线 → 服务目录 → SLA → 团队与供应商 → 资产底座 → 工单流程 → 运营考核 → 二开"八条主线逐表落地，全部走完，项目的施工图也就成形了。