IT服务模式的探索

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
▪ 记录对象: 记录患者从入院到出院所有医疗数据,一旦出现差错,有可能导致医疗记 录的失真,甚至威胁患者生命安全。
▪ 集成范围: 是临床信息化的平台,涉及到众多外周系统的集成,出现问题的可能性较 大。
▪ 数据用途: 除用于病历记录外,还是统计数据以及科研数据的重要来源。
9
应用的瓶颈
▪ 建设过程中协调问题 – 需求都具有较高优先级 – 干系人多,协调难度大 – 涉及临床原有流程的重新规划,容易产生冲突
–若项目启动九周后再出现的与此项目有关的事件,不再算做考核,按照 新事件进行处理。
事件级别
事件描述
事件处理
一-三级事件
指显示问题、界面问题、或仅影响 部分用户使用方便性的事故。
IT服务模式的探索
赵韡 2011.12
1.1 新医改方案中的信息化地位
在我国医疗卫生行业,信息系统首次与公共卫生体系、医疗服务体 系、医疗保障体系、药品供应体系以及医疗管理机制、运行机制、投入机 制、价格形成机制、监管机制、科技和人才保障、法律制度并列,被称之
为“新医改的四梁八柱”。
2
IT管理模式的变更
时间 第一周 第二周 第三周 第四周
第五-Байду номын сангаас周
项目周期 研发期 测试期 试用期 发布期
运维期
责任部门 技术组 测试组 项目组 项目组
运维组
工作内容 技术组完成程序变更修改; 测试组完成测试计划。
测试组完成程序测试。
程序试运行。
最迟第五周全面发布程序。
记录和统计程序运维事件; 若出现五级事件,立即回滚或更新; 第八周结束进行项目总结。
▪ 不太注重运维事件的处理过程,事件处理质量和用户满意度难以控制; ▪ 在事件/服务请求处理过程中难以形成闭环管理; ▪ 事件产生后不能明确唯一责任人,缺乏有效的监控和跟踪机制; ▪ 开发业务需求紧迫,测试不严格; ▪ 同样的事件重复发生,缺乏排除同类事件再次发生的保障体系; ▪ 设备及文档记录很多,但无法查找,尤其急用时;
应用程序错误 40%
其他 20%
操作错误 40%
• 硬件/平台 • 网络故障 • 电力、灾难事故
– 80%的IT意外故障时间由 人员和流程造成的;
– 60%多的时间用于解决重
复故障。
4
1.2 面临的问题
▪ 人员(People) ▪ 流程(Process) ▪ 技术(Technology)
5
人员(People)
7
技术(Technology)
▪ 信息技术 ▪ 运维管理技术
8
1.3 以电子病历为核心的信息系统应用特点
▪ 应用范围: 全院范围,涉及临床从管理到执行的各个环节,涵盖临床核心业务流程, 出现问题影响全院正常业务开展。
▪ 干系人: 使用人员多为临床一线医师及职能部门,是医院核心人员,话语权极大, 一旦出现问题,影响极坏。
优化运维管理流程
• 合理分配、部署运维事件 • 避免运维事件大量挤压 • 确保临床业务的有序开展
优化程序修改流程
• 确保程序修改质量 • 提高需求响应速度
事件管理 变更管理
建立长效保障机制 • 应用PDCA保障机制
PDCA
13
戴明循环 Deming cycle
连续的质量控制 和增强
成熟度
Plan, Do, Check, Act
安全管理
配置管理
17
组织结构配套
信息中心
研技测项运网 发术试目维络 组组组组组组
研变问项事安 发更题目件全 管管管管知管 理理理理识理
18
五大流程向结合
事件管理
问题管理
变更管理
配置管理 知识库
发布管理
19
2.4 完善管理制度
▪ 各部门工作职能 ▪ 工作流程 ▪ 岗位描述 ▪ 规章制度配套
20
考核标准 - 进度
【标准】:未能按照计划在四周内结束项目的,即该项目考核不合格; 【责任】:由哪个环节出现了拖延情况,则该环节的负责人负全责。
21
考核标准 - 质量
【标准】
–以项目进入运维阶段后(即项目启动后的第五至八周)出现的与此项目 有关的事件的紧急重要程序及数量作为考核标准;
–项目运维阶段允许出现1个四级事件和2个三级以下(含三级)事件,事 件总数不得超过3个,否则该项目考核不合格;
▪ 服务过程中的管理问题 – 需求多,要求响应时间短 – 系统中断或出现问题代价较高 – 对系统效率要求高 – 使用后,修改要求依然频繁,系统的滚动更新导致系统稳定差
10
1.4 用户需求是什么
技术先进 按需定制 系统稳定 人员技术能力强 项目管理到位 用户参与 顶层设计 用户满意
11
2.1 如何提高用户满意度
▪ 信息化趋势: 技术驱动-业务驱动-决策驱动
▪ 管理要求: 维修-建设-保障
▪ IT部门的定位: 信息技术提供者 -信息工程的组织者 -信息服务供应者
3
IT服务管理模式需要改变
▪ Gartner对宕机原因分析:
• 未测试程序 • 变更异常 • 系统过载
运维
• 遗漏 • 流程缺失 • 备份错误 /不安全操作
▪ 工作量激增,人员数量质量难以短期内改善的情况下,如何应对? ▪ 涉及专业庞杂,如何统一管理? ▪ 工作分配不完全合理,没有量化数据来反应工作成绩,打消员工积极性? ▪ 人员专业技能如何提高? ▪ 技能不同,经验不一,如何合理分配? ▪ 专业要求高,新员工培养周期长。 ▪ 员工离职带来的问题。
6
流程(Process)
运维方面问题 程序修改问题
• 提高事件响应速度 • 提高事件的解决效率 • 降低事故发生后的损失
• 提高需求修改速度 • 确保系统修改质量 • 减少错误发布带来的额外损失
建立长效保障机制 • 避免事件重复发生
12
2.2 ISO 20000
▪ 定义
ISO20000标准是一部针对信息技术服务管理领域的国际标准,它规定了IT服务管理行业 向企业及其用户提供服务、一体化的管理过程以及过程建立的相关要求,帮助识别和管理IT服 务的关键过程,保证提供有效的IT服务以满足用户和业务的需求。主要包括:事件管理、问题 管理、变更管理、发布管理、配置管理等五大部分。
(Project plan, Project, Audit, New actions)
业务和IT的整合
AP CD
有效的质量改进
增强(ISO 20000)
时间刻度
14
ITIL的提出
15
2.3 需要解决的首要问题
16
改进的管理模型
事件管理
知识管理
测试管理 研发管理
问题管理 变更管理
项目管理
发布管理
相关文档
最新文档