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