医疗健康与教育行业 ITSM 案例分析
医疗与教育是两个「用户不是 IT 人」的典型行业：医生在门诊、学生在教室，他们没有耐心填标准化工单表单，也看不懂技术术语。这两个行业的 ITSM 成败，基本不取决于流程有多完备，而取决于入口够不够近、目录说不说人话。
一、医疗健康行业
1.1 行业特点与典型痛点
医院信息中心和一般企业信息中心最大的不同：核心系统中断的代价是患者安全。HIS（医院信息系统）停了，挂号收费停摆、医嘱开不出去、药房发不了药，门诊直接瘫痪；急诊、手术场景下，系统中断可能直接影响救治。这不是员工体验问题，是医疗安全问题。
除此之外，医疗行业还有四个特征：
- 数据敏感度最高一档。 病历、检验结果、影像、患者身份信息，受《网络安全法》《数据安全法》《个人信息保护法》约束，三甲医院普遍按等级保护三级建设。运维系统本身也在监管范围内——工单里如果贴了患者信息，运维人员越权查看，同样是事件。
- 一线医护没时间提工单。 医生在诊室一坐一上午，护士在病房连轴转，让他们详细填写故障描述、选择服务分类，现实中行不通。IT 支持必须主动嵌入他们的工作流。
- 资产谱系超出传统 IT 范围。 除了服务器、网络、终端，还有 CT、核磁、监护仪等医疗设备的网络接入与维保，信息中心和设备科的分工常年模糊。
- 请求有强烈潮汐。 上午门诊高峰（8 点到 11 点）是故障影响面最大的时段，这个时段的值班力量必须最强；深夜反而是做变更的唯一窗口。
| 痛点 | 具体表现 |
|---|---|
| 核心系统风险不可见 | 只监控服务器存活，HIS 页面卡顿、医保接口超时发现不及时 |
| 故障上报靠口头 | 护士站电话打到信息中心，同时打五六个，接不过来也无记录 |
| 业务连续性无预案 | HIS 真挂了，才临时商量转手工流程，混乱且无据可查 |
| 多厂商踢皮球 | HIS 厂商、医保厂商、设备厂商各管一段，故障定位互相推 |
| 工单内容泄露隐私 | 工单描述里贴病历、贴患者身份证号，权限又没分级 |
1.2 适配的 ITSM 方案设计要点
服务目录按业务场景命名，不按技术模块命名。 目录里应当是「挂号收费系统故障」「医生工作站卡顿」「护士站移动终端连不上」「医保结算接口异常」——医护看得懂、点得准，选完直接派到对应支持组。千万不要把目录做成「数据库故障」「网络中断」「中间件异常」，那是工程师的语言，不是用户的语言。
入口必须到手机里。 医护通过企业微信/钉钉扫码报修，拍照上传故障现象，紧急故障一键呼叫值班工程师、跳过逐级派单。电话报修仍然保留——老年医生、急诊场景下电话就是最快的通道，电话进来后由服务台代录工单。
CMDB 要画出业务拓扑。 ECMDB 把 HIS、EMR（电子病历）、LIS（检验）、PACS（影像）、医保接口、电子票据、服务器、数据库、链路串成一张图。医保接口、电子票据这类对外接口单独标记——它们一断，门诊收费直接 停摆，优先级高于一般办公系统。
监控盯业务不盯机器。 RadarDesk 对核心系统做业务级可用性探测：不只是服务器 CPU 正常，而是 HIS 页面能否打开、医保接口能否应答。门诊高峰时段告警阈值收紧、值班加人；夜间窗口放松，用于做变更。告警自动转 P1 工单并通知值班。
SLA 按临床影响分级。 核心临床系统（HIS/EMR/医保）P1：分钟级响应、30 分钟内恢复或切换手工应急预案；行政办公、会议室音视频类 P3：工作时间处理。分级写进服务目录，医护也能预期「这个故障该有多急」。
自助能力服务高频小问题。 密码重置、CA 证书过期、打印机脱机、教室/诊室网络排查这类高频低难度问题，做成知识库自助指引和自动处置脚本，把服务台人力让给真正的临床故障。
1.3 补充案例：某中西医结合医院的实践
某三甲中西医结合医院（集医疗、教学、科研于一体）近年做了一轮运维服务升级，几个做法有参考价值：
- 统一门户，信息前置。 把公告、FAQ、热门服务目录、知识库检索集中到一个入口，医护自行查询解决了大量重复咨询，服务台来电量明显下降。核心是把常见问题答案放在工单之前，而不是让人先填表再排队。
- 工单全生命周期闭环。 设备报修、咨询请求一键触达工程师，移动端拍照上传、进度实时可查，完工后由报修人在手机上做满意度 评价；未及时评价的工单系统自动提醒，确保用户声音不遗漏。
- 知识与工单联动。 工程师处理工单时自动带出相似历史案例，新解决的问题经审核后沉淀为知识条目；知识条目带有用/无用反馈，长期无人认可的条目定期清理，知识库不腐烂。
- 数据看板支撑管理。 按服务、团队、业务系统出多维报表，管理者不再凭印象判断哪个组忙、哪类故障多，运维例会的数据有据可依。
这个案例的关键不在用了什么高级功能，而在「服务找人」的思路：把信息前置、把入口放低、把评价闭环，让医护在最短路径上解决问题。
1.4 落地启示与注意点
- 变更窗口是铁律。 核心系统升级、变更一律排在深夜停机窗口，提前书面公告门诊科室；工作日上午动 HIS 就是制造事故。
- 应急预案要做成工单模板。 HIS 中断后的手工收费、手写处方流程，不是出事时现场商量的，而是平时就在 ITSM 里建好的任务单模板——触发条件一满足，按预案逐项执行、逐项确认。
- 隐私边界写进流程。 工单描述规范里明确：禁止粘贴病历、患者身份证号、检验明细；工单系统账号分级，运维实习生看不到含敏感描述的工单。
- 厂商纳入同一工单体系。 HIS 厂商、医保厂商、设备厂商的驻场和远程支持，其处理过程也要进工单，否则故障期间三家互相踢皮球，信息中心两头受气。
二、高校教育行业
2.1 行业特点与典型痛点
高校信息中心面对的是几万名师生，请求量级和潮汐特征都很鲜明：开学季、选课周、考试周是洪峰，其余时间相对平缓。师生的技术水平参差——教授的问题和新生的问题不是一个难度量级，但走的是同一个服务台。
这个行业的运维特征：
- 请求谱系极宽。 从密码重置、校园网认证、VPN、邮箱、教务系统，到多媒体教室设备、实验室终端软件安装——一条服务台流要接住所有类型的请求。
- 资产遍布全校。 教室多媒体、实验室仪器、宿舍网络、办公电脑，物理位置分散，维保责任还常跨信息中心、教务处、后勤资产处。
- 用户会公开评价。 师生有校长信箱、社交平台等公开吐槽渠道，服务口碑直接影响信息中心在校内的地位和预算话语权——这是高校独有的约束。
- 学期节律分明。 寒暑假是集中变更和设备更新窗口，开学前必须全部就位，容不得「开学后再调」。
2.2 适配的 ITSM 方案设计要点
服务目录按师生语言贴身打造。 目录条目应当是「校园网连不上」「VPN 怎么连」「教务系统密码找回」「多媒体教室设备报修」「实验室电脑装软件」——直接对应师生真实的说法，而不是「网络接入服务」「账号管理服务」这类技术分类。目录设计阶段，把信息中心一线客服拉进来逐条目过一遍，他们每天接的电话就是最好的目录素材。
多渠道接入，移动端优先。 PC 服务门户、微信/钉钉/企业微信移动端并行：扫码报修、进度推送、完工评价都在手机端完成。高校用户的请求绝大多数来自手机，只做 PC 门户等于把入口关了一半。
自助优先，把服务台解放出来。 密码重置、校园网认证故障自查、VPN 使用手册、选课系统常见问题——高频简单问题全部前置到知识库和自助工具，能在线解决的不进工单。高校 ITSM 第一阶段的 KPI 不是工单处理多快，而是多少比例的请求根本没变成工单。
CMDB 按位置建模。 ECMDB 管理楼宇—教室—机位的资产关系，多媒体设备、机房终端挂到具体位置，报修工单带上位置后自动派到对应校区/楼层的维护组。校园网、教务系统、一卡通、统一身份认证之间的依赖关系画成拓扑，变更前先评估影响面——选课周动统一认证，全校瘫痪。
多维度分析应对潮汐。 按服务、团队、业务系统出分析报表，识别开学季、选课周哪些请求类型暴涨，提前排值班、提前做系统压测。数据看板同时是信息中心向学校要编制、要预算的材料。
2.3 落地启示与注意点
- 上线时间避开开学季。 选课、四六级报名、抢课时段系统并发暴涨，ITSM 自身也要扛得住工单洪峰；新版本、新流程上线排在学期初前的窗口期，开学第一周只观察不改动。
- 账号生命周期与统一身份认证联动。 新生入学开通、毕业离校回收、教职工调动权限调整，全部由身份认证系统驱动，否则几年下来僵尸账号、离职账号堆积成安全隐患。
- 满意度评价是硬抓手。 师生评价结果与部门考核挂钩，是高校信息中心少有的、自上而下推得动的服务质量机制，别把评价做成走形式的五星。
- 跨部门边界提前划。 教务系统归教务处、一卡通归财务处、教室多媒体归教务处资产科——ITSM 工单体系要把这些部门的接口人接进来，明确「谁的系统谁兜底」，避免师生报修后在部门之间被转来转去。
小结：医疗行业 ITSM 的底线是「临床系统不停」，教育行业的底线是「师生诉求有人接、接得快」。两个行业的共同点是用户都不是 IT 人——服务目录必须说人话，入口必须到手机里，自助能解决的不要麻烦工程师。功能清单再长，这三条做不到，系统上线也就是个流程记录工具。