简介：这份数字化医院后勤一站式服务中心方案PPT共33页，面向医院后勤管理者、信息科人员及智慧医院建设规划方，聚焦传统后勤经验管理、信息不透明、缺乏统一调度和服务满意度低等痛点，提出一体化服务与信息化转型路径。资源为单一PPT文件，压缩包6.88MB，内部结构完整，依次覆盖医院后勤管理现状、一站式服务流程、业务与管理PDCA闭环、维修系统功能、移动报修渠道、专业维修知识库及维修过程监控等模块。已有245人浏览学习，适合作为医院后勤数字化升级的参考样例，也可用于项目汇报与内部培训。方案融入智慧医疗信息化、大数据可视化、应急管理提升与人工智能应用等理念，展示从故障报修、派工、完工、回访到绩效分析的闭环流程，并涵盖数据中台与智慧医院建设框架，能帮助读者快速形成从现状剖析到落地改进的整体方案思路。
1. 后勤报修不是没人管，是入口太散
护士站报修天花板漏水，先打电话给物业，物业说要找设备科，设备科说保洁先扫水、维修要排单，电话转了三个人，最后问题还挂在一个没人认领的“待处理”里。这是医院后勤最常见的真实状态：报修、保洁、运送、安保、膳食、设备巡检各自一套台账，电话、微信、纸质单混着走，信息断在部门边界上。数字化医院后勤一站式服务中心，本质上不是上一个新系统，而是把散落的入口收敛成一个工单池、一套调度规则和一条考核闭环——让“谁报修、谁接单、谁处理、干完没有”全程可查。对于信息科和后勤保障处来说，这套方案的核心价值不在那 33 页 PPT 的排版，而在工单数据怎么流、人员怎么派、超时怎么升级。适合正在做智慧医院评级、后勤提质增效，或者准备替换老旧报修系统的团队参考。
2. 一站式服务中心的总体布局：入口、工单流和数据流
2.1 先分清四类服务对象和三类接入渠道
设计后勤一站式服务中心，第一步不是画架构图，而是把“谁找谁干什么”理顺。医院后勤的服务对象可以分为四类：临床科室（护士站、医生办公室）、医技科室（检验科、放射科）、患者公共区域（门诊大厅、候诊区）、行政办公区。每类对象的报修习惯和响应要求不一样，临床科室要的是“快”，患者区域要的是“不吵”，行政办公区要的是“有反馈”。我一般会先按这句话做一张服务域清单，再决定系统要接哪些渠道。
| 服务域 | 典型事件 | 常见现状 | 关键对接点 |
|---|---|---|---|
| 维修类 | 漏水、断电、门锁、空调不制冷 | 电话打到物业或值班室 | 电工、水暖工排班表 |
| 运送类 | 标本转运、患者陪检、物资配送 | 微信群里喊人 | 运送员定位、任务量 |
| 保洁类 | 地面污渍、垃圾清运、终末消毒 | 保洁主管分派 | 楼层网格、排班 |
| 安保类 | 通道门异常、纠纷协助、停车场调度 | 对讲机调度 | 监控中心、巡更点 |
| 膳食类 | 病区订餐、送餐延迟、餐量异常 | 电话订餐 | 订餐系统、病区楼层 |
| 设备类 | 生命支持设备报警、巡检到期 | 设备科单独台账 | 设备档案、保养计划 |
接入渠道可以分三类：电话（人工坐席转工单）、移动端（扫码报修、小程序拍照上报）、系统对接（HIS、设备监控平台自动生成工单）。设计原则是“多入口进、单通道流”——所有渠道进来的请求都转成统一格式的工单对象，后续派单、跟踪、回访全部基于工单，而不是基于电话记录或微信群消息。这样后勤一站式服务中心才能从“接电话的地方”变成“管流程的地方”。
2.2 工单状态机：用 6 个状态卡住全过程
工单系统能不能落地，关键看状态机定义得清不清楚。很多项目失败不是因为没系统，而是状态随意：有人把“处理中”当“已完成”，有人接了单不点开始，后台统计永远不准。做后勤一站式服务中心，我建议只用 6 个状态，每个状态有明确的进入条件和退出动作：
| 状态 | 含义 | 触发动作 | 责任角色 |
|---|---|---|---|
| 已创建 | 报修请求已录入系统 | 电话接听、扫码、接口自动生成 | 坐席/系统 |
| 待派工 | 等待指派给具体执行人 | 客服主管或算法派单 | 调度员 |
| 已接单 | 执行人确认接收 | 移动端点击接单 | 维修工/运送员 |
| 处理中 | 到达现场开始作业 | 移动端点击开始 | 执行人 |
| 待验收 | 作业完成，等待报修人确认 | 提交完成并拍照上传 | 执行人、报修人 |
| 已关闭 | 验收通过，工单归档 | 报修人确认或超时自动关闭 | 系统 |
每个状态要记录时间戳，特别是“已创建”到“已接单”的间隔，这是 SLA 考核的核心字段。如果超过设定阈值（比如普通维修 10 分钟没人接单），工单自动进入“超时池”，同时给调度员和后勤科长推送提醒。这个机制比人工催单可靠得多——它不是事后看报表，而是在现场进行时就把问题暴露出来。
-- 基础工单表（MySQL 示例，字段按生产需要可扩展） CREATE TABLE wo_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, wo_no VARCHAR(32) NOT NULL COMMENT '工单号，规则：日期+序列', scene_id INT NOT NULL COMMENT '来源场景：1扫码 2电话 3系统接口', service_type INT NOT NULL COMMENT '服务域：1维修 2运送 3保洁 4安保 5膳食 6设备', location_code VARCHAR(64) COMMENT '位置编码，对应楼层网格', reporter VARCHAR(32) COMMENT '报修人姓名', reporter_phone VARCHAR(20), priority TINYINT DEFAULT 3 COMMENT '优先级：1紧急 2高 3普通 4低', status TINYINT DEFAULT 0 COMMENT '0已创建 1待派工 2已接单 3处理中 4待验收 5已关闭', assignee VARCHAR(32) COMMENT '执行人ID', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, accepted_at DATETIME NULL COMMENT '接单时间', finished_at DATETIME NULL COMMENT '完成时间', closed_at DATETIME NULL COMMENT '关闭时间', is_timeout TINYINT DEFAULT 0 COMMENT '是否超时', KEY idx_status_created (status, created_at), KEY idx_assignee_status (assignee, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='后勤工单主表';这张表的设计要点有三个：第一，wo_no必须有规则且全局唯一，后续所有系统交互都拿它当关联键；第二，scene_id区分来源渠道，用于统计不同入口的工单量和转化率；第三，状态和时间戳字段分开存，不搞“用一个字段既表示状态又记录时间”的小聪明，否则后续做 SLA 报表时会发现历史时间点丢失，根本算不出“平均接单时长”。
2.3 数据流：从报修到归档的完整链路
数据流设计要回答一个核心问题：一个工单从产生到归档，经过了哪些系统、产生了哪些关键数据、谁在哪个节点做了什么事。常见做法是划分为五段：接入层、解析层、调度层、执行层、评价层。接入层负责把电话语音、微信图文、扫码信息转成结构化数据；解析层做服务分类和优先级判断（比如“漏水”“漏电”自动升为高优先级）；调度层按排班和技能标签分配执行人；执行层记录到达时间、作业内容和耗材使用；评价层让报修人确认并打分。
{ "wo_no": "20250617001", "scene_id": 2, "service_type": 1, "location": {"building": "住院部A栋", "floor": 5, "room": "502护士站"}, "description": "水龙头关不住，漏水到地面", "priority": 2, "attachments": ["photo_001.jpg"], "timeline": [ {"event": "CREATED", "time": "2025-06-17 09:12:00", "operator": "system"}, {"event": "DISPATCHED", "time": "2025-06-17 09:13:05", "operator": "dispatcher"}, {"event": "ACCEPTED", "time": "2025-06-17 09:15:40", "operator": "zhang_wei"} ] }这一段 JSON 是工单对象在系统中的流转形态。location建议用结构化字段而不是纯文本，因为后续按楼层统计故障密度、生成维修热力图都要依赖它。timeline数组记录每个事件的产生时间和操作人，只追加不修改，这比在工单表里反复 update 一个时间字段更利于追溯——万一出现“接单 5 分钟后报修人投诉没人来”，可以准确看到执行人在哪个环节耽误了。
3. 把工单转起来：派单规则、优先级矩阵和移动端闭环
3.1 三种派单策略：抢单、轮询、按积压量分配
工单创建之后，下一步是派人。常见做法有三种：抢单模式（执行人在 App 里主动抢）、轮询模式（系统按固定顺序轮流派）、按积压量分配（计算每个执行人当前待处理工单数和预估工时，派给最空闲的人）。三种模式适用阶段不同，我一般建议刚上线时用轮询或抢单，跑通一个月后换按积压量分配——这个策略最接近调度员的人工判断，也最容易让执行人接受。
| 派单模式 | 适用阶段 | 优点 | 风险 |
|---|---|---|---|
| 抢单 | 上线初期、工时统计不完善 | 执行人积极性高 | 热门工单被抢、冷门工单没人接 |
| 轮询 | 人员技能差异小、任务均匀 | 公平、规则简单 | 不区分技能，维修单派给运送员 |
| 按积压量分配 | 数据积累 1 个月以上 | 负载均衡、响应快 | 依赖预估工时准确性 |
按积压量分配的算法不复杂，核心是给每个执行人算一个“当前负载分”。负载分 = 待处理工单数 × 2 + 处理中工单预估剩余小时数 × 3 + 当日已完成工单数 × 0.5。得分最低的人优先接新单。这个公式里权重需要按实际场景调：如果运送类工单很快（平均 15 分钟一个），倍率要调低；维修类工单耗时长，倍率调高。
# 按积压量分配的简化实现（Python） import heapq from datetime import datetime def score_worker(w): # 负载分越低越优先 pending_weight = 2.0 # 待处理工单权重 ongoing_weight = 3.0 # 处理中预估剩余时间权重 done_weight = 0.5 # 当日已完成工单权重 return (w['pending_count'] * pending_weight + w['ongoing_hours'] * ongoing_weight + w['done_count'] * done_weight) def dispatch(workers, new_order): # 只考虑在岗且技能匹配的执行人 candidates = [w for w in workers if w['is_on_duty'] and new_order['skill'] in w['skills']] if not candidates: return None heap = [] for w in candidates: s = score_worker(w) # 用最新接单时间做次级排序，避免永远派给同一个人 heapq.heappush(heap, (s, w['last_order_time'], w['id'])) # 弹出负载分最低的执行人 _, _, worker_id = heapq.heappop(heap) return worker_id # 调用示例 # workers = [{'id': 'zhang', 'pending_count': 3, 'ongoing_hours': 1.5, 'done_count': 8, 'is_on_duty': True, 'skills': ['维修'], 'last_order_time': datetime.now()}] # order = {'skill': '维修', 'priority': 2} # print(dispatch(workers, order))这段代码的设计要点在最后一行注释里——用last_order_time做次级排序，是为了防止负载分相同的时候系统总派给同一个人。实际项目中还要考虑两个边界条件：一是“技能匹配”不能只匹配大领域（维修），要细到子技能（电路维修、水路维修、门窗维修），否则派错人后执行人到了现场发现不会修，工单又被退回调度池，浪费时间；二是节假日排班表要提前导入系统，不要在派单时才去问“今天谁值班”，否则调度逻辑就断了。
3.2 事件优先级矩阵：什么事件必须先干活
优先级定不好，调度就是空转。很多医院后勤团队的痛点是“所有工单都急”，最终导致没有一个工单真正被快速处理。我的建议是建立一个四级优先级矩阵，定义清楚每类服务域在什么场景下对应什么级别：
| 优先级 | 定义 | 典型场景 | 响应目标 | 完成目标 |
|---|---|---|---|---|
| P1 紧急 | 影响患者安全或核心业务中断 | 漏电、氧气压力异常、供水主管爆裂 | 立即响应，5 分钟内到达 | 持续处理至恢复 |
| P2 高 | 影响临床科室正常运作 | 空调停摆、门禁失灵、设备故障停机 | 10 分钟内接单 | 4 小时内解决 |
| P3 普通 | 不影响医疗业务但影响体验 | 窗户关不上、椅子损坏、墙面污渍 | 20 分钟内接单 | 24 小时内解决 |
| P4 低 | 计划性维护、非紧急需求 | 巡检发现隐患、办公家具更换 | 1 小时内确认 | 约定时间完成 |
优先级矩阵要写进系统规则，而不是靠调度员人脑判断。医院后勤的值班场景里，一线报修人往往会把所有问题都说成“很急”，坐席需要按矩阵逐项对照归类。P1 级别必须触发电话加短信双重通知，而不是只在 App 里弹一条消息——执行人如果没看手机，延误的每一分钟都是风险。
3.3 移动端闭环：接单、打卡、拍照、耗材、回单
移动端是执行人的主要工作界面，设计上要克制：界面可以做简单，但流程必须闭环。一个标准的工单执行流程是：收到派单通知→点击接单→查看位置和故障描述→到达现场点击“开始处理”→处理完成后拍照上传→填写耗材使用→提交验收。每一步操作都要产生时间戳，因为考核“平均到场时长”和“平均处理时长”依赖这些数据。
{ "action": "COMPLETE_ORDER", "wo_no": "20250617001", "executor": "zhang_wei", "arrive_time": "2025-06-17 09:28:10", "complete_time": "2025-06-17 09:52:33", "photos": ["before.jpg", "after.jpg"], "material_used": [ {"code": "M001", "name": "三角阀", "qty": 1}, {"code": "M005", "name": "生料带", "qty": 2} ], "result": "已更换三角阀，现场测试无漏水", "need_follow_up": false }arrive_time是执行人第一次点击“到达现场”的时间，与接单时间之间的差值对应“赶往现场时长”。photos至少需要两张：处理前和处理后，这两张照片既是验收依据，也是后续处理投诉时的证据。material_used走耗材库编码，不走文本描述，这样月底可以自动汇总耗材成本，和采购系统对账——很多医院后勤耗材浪费的漏洞，就是从这个字段的规范化开始堵住的。
4. 33 页方案的落地节奏：从现状盘点、上线到运营
4.1 方案为什么是 33 页，以及怎么用
一份 33 页交流版方案，通常不是按功能模块写，而是按决策逻辑写：第 1~5 页讲现状痛点（后勤分散管理、数据统计难、响应无考核）；第 6~12 页讲总体设计（服务中心定位、组织架构、系统架构）；第 13~25 页讲分场景流程（报修、运送、保洁、设备巡检各画一张流程图）；第 26~30 页讲实施计划与组织保障；第 31~33 页讲投资估算与预期效益。所以看方案时不用逐页细读，先翻到流程图和流程说明部分，确认工单在各科室之间怎么流转、谁审批、谁验收。最怕的是方案里写得通顺，到了 HIS、设备科、物业外包商三方的数据接口才发现没人愿意配合，那落地就卡死了。
4.2 第一步：现状盘点必须先做，别急着选型
我见过最快失败的案例是上线第一天就发现“系统里的执行人名单是旧的”——外包保洁公司换了人，但组织架构图没更新。所以落地的第一步是现状盘点：把所有报修渠道列出来，电话记录、微信群、纸质单逐项登记数量；把后勤人员的排班表、技能标签、外包合同的服务范围拉齐；把常用耗材的品类和单价整理成编码表。这一步可以输出两张核心文档：服务目录（含 SLA 目标）和人员技能矩阵，后续系统配置全部以这两份文档为准。
4.3 运营报表：用 SQL 直接查超时工单和响应时长
系统上线后，真正值钱的是运营数据。建议每天固定时间跑三张报表：今日工单量（按服务域统计、按来源渠道统计）、超时未接单列表、平均响应时长（从创建到接单）。这些报表不要依赖厂商定制开发，信息科自己写 SQL 就能完成。
-- 查询最近7天超时未接单的工单（假设普通工单10分钟内必须接单） SELECT wo_no, service_type, location_code, reporter, created_at, TIMESTAMPDIFF(MINUTE, created_at, NOW()) AS waiting_minutes FROM wo_order WHERE status IN (0, 1) AND priority <> 1 -- P1 有更严格的要求，单独看 AND created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY) AND TIMESTAMPDIFF(MINUTE, created_at, NOW()) > 10 ORDER BY waiting_minutes DESC;这条 SQL 的结果就是当天调度会上的“考勤表”。status IN (0, 1)的意思是工单还停在已创建或待派工状态没有进入执行环节；TIMESTAMPDIFF计算等待分钟数并过滤出超过 10 分钟的单。如果这个查询每天都有大量返回，说明不是执行人不干活，而是派单规则有问题、或者人员排班不足，需要在调度层调参数，而不是天天催一线。
4.4 上线节奏：先跑 1 个服务域，再横向扩展
后勤一站式服务中心不建议一次性全面上线。常见做法是分四个阶段：第一周只跑维修类工单，把电话接听、创建工单、派单、接单、完成、验收这条链路打通；第二周增加移动端扫码报修，让护士站开始用起来；第三周纳入运送和保洁；第四周再把安保、膳食和设备巡检接进来。每加一个服务域，都要单独跑一周观察数据。最稳妥的判断标准是“平均接单时长稳定在目标值以内、超时工单占比低于 5%”，达到这个标准才做下一个服务域的扩展。
5. 把服务中心跑稳的验证方法：闭环率、SLA 统计和升级机制
5.1 三个核心指标：闭环率、平均接单时长、满意度
系统上线后，怎么判断它“真的在起作用”？我认同比起复杂的 KPI 体系，先用三个指标做体检。第一是工单闭环率：已关闭工单数除以总工单数，低于 90% 说明有工单卡在某个状态出不来，需要查状态机异常。第二是平均接单时长：从工单创建到执行人点击“接单”的平均分钟数，这个指标直接反映调度效率——如果它不降，说明派单规则或排班配置有问题。第三是报修人满意度：完成后推送评价请求，统计满意和基本满意的比例，低于 85% 时需要关注服务态度和完成质量，而不只是速度。
# SLA 剩余时间计算函数：按工作日时间计算，跳过午休和夜班 from datetime import datetime, timedelta def sla_deadline(created_at, sla_minutes, work_start="08:00", work_end="18:00"): current = created_at minutes_left = sla_minutes while minutes_left > 0: day_start = current.replace(hour=int(work_start.split(":")[0]), minute=int(work_start.split(":")[1]), second=0, microsecond=0) day_end = current.replace(hour=int(work_end.split(":")[0]), minute=int(work_end.split(":")[1]), second=0, microsecond=0) # 超过下班时间，跳到下一个工作日早上 if current >= day_end or current < day_start: current = day_start + timedelta(days=1) continue # 当天可用的剩余工作分钟数 available = min(day_end, current + timedelta(minutes=minutes_left)) - current minutes_left -= available.total_seconds() / 60 current += timedelta(minutes=max(available.total_seconds() / 60, 0)) return current # 示例：上午9点创建工单，SLA 4小时，预计在当天14:00前完成 # print(sla_deadline(datetime(2025, 6, 17, 9, 0), 240))这段代码的核心是“工作时间内计时”的逻辑：医院后勤夜间虽然有人值班，但行政验收往往在白天，所以系统不能让 SLA 在凌晨也滴答走。work_start和work_end是全局参数，按各医院实际排班调整；如果执行人跨午休，还需要把 12:00-13:30 的午休区间也排除掉。这里的关键是 deadline 的计算要展示给坐席看，让他能直接告诉报修人“预计在下午两点前解决”，而不是让报修人去猜。
5.2 一个进阶技巧：把工单号变成全院通用的“追踪主键”
最后分享一个让系统越跑越顺的技巧：让工单号成为全链路唯一的追踪主键。理想状态是，科室扫码报修后短信自动回复工单号；患者或护士打电话追问时，坐席第一句话就是“请问工单号是多少”；执行人完成回单后，工单号回写 HIS 的维修记录字段；月底后勤例会，直接按工单号关联投诉记录、耗材出库和满意度评分。做到这一步，一站式服务中心就不再只是一个接电话的班组，而是医院后勤数据的主干道——后续设备维保到期提醒、能耗异常告警、耗材成本分析都可以通过工单号串起来跑。这是投入产出比最高的一步，也是从“有系统”走向“智慧医院后勤”最实在的台阶。
本文还有配套的精品资源，点击获取
的底层链路解析)
