【e医疗原创】如何梳理业务流程才能管理好信息中心？
想说点儿什么？欢迎点击文章下方“写评论”留下您的精彩观点。
文
青岛大学附属医院
信息管理部
辛海燕
☞ 从2000年起，青大附院信息管理部开始探索适用的运维管理方式。2001年，我们自主开发了基于事件管理的运维平台，所有日常产生的维修事件都由工程师在系统中填好工单，便于日后统计和监管。信息管理部门内部设置服务台岗位和外服岗位，分工合作。服务台岗位主要负责接听电话、远程处理和调度，外服岗位根据服务台安排去故障现场解决问题。这样的模式解决了来电不接互相推诿的现象，是后来服务台模式的雏形。
从2012年开始，医院的HIS系统全面升级，HIS系统的模块由原来的几十个增加到上百个，机房设备全面升级，网络规模由两个院区扩大到四个院区，网络设备及各种计算机终端设备增至4000多台。
软件需要管理，硬件需要维修，服务器需要监管，网络需要维护，如何合理分配技术人员，如何管理信息资源，如何让信息系统平稳运行，面对这一个接一个的问题，青大附院信息部开始探寻一套高效的信息管理和运维方法。
引入ITIL理念，保证管理可持续发展
图1：事态显示今日事态、事态积压、当前工作情况
图2：事态显示今日事件、事件积压、事件剩余时间安排
信息管理的目的不仅仅是保障系统正常运行，还要关注运维人员能力持续提高、典型工作的流程化和改进以及系统的持续优化。这就需要技术与管理的并重，打造内部文化，提高人员的凝聚力和认同感。
目前医院信息管理部有三个业务科室，分别负责桌面运维、项目实施和开发管理及网络服务器维护。科室间各司其职，又相互依存，形成一个良好的信息运维体系。2013年起，青大附院开始关注国际标准的管理体系，引入ITIL的管理理念。经过了两年摸索和实践后，逐步建立了基于数据流的配置管理库，实现了配置管理、事态管理、事件管理、服务目录管理的流程和管理机制，实现了信息项目全生命周期的管理。
日常维护工作由计算机中心负责，主要承担桌面硬件维修及软件维护。由服务台接听电话并创建工单，需要派单去现场的，由服务台安排工程师去现场处理，工程师填写处理结果，由服务台根据处理结果关闭工单，超期未处理的工单系统会特殊显示，整个过程是闭环管理。
软件的开发和管理由项目开发中心负责，主要承担软件的实施、需求变更管理及日常维护。项目开发中心的每人都作为项目负责人，具体分管几个软件项目。项目负责人的工作重点在于沟通，在使用科室和软件开发商之间起到桥梁作用。通过和使用科室间的沟通，充分理解科室的需求，并将业务需求转化为信息语言传递给软件开发商，同时也将软件的流程及操作传达给科室用户。项目开发中心的工作流程有需求管理和任务管理两大部分。需求管理的流程是项目负责人在系统中填写科室的软件需求，提交给科室主任审批，通过后提交软件开发经理。需求处理完毕后由项目负责人关闭。任务管理由项目负责人自行创建并管理和项目相关的工作内容。
服务器及网络设备由网络管理中心负责，主要承担机房所有设备的监控和维护。在网络管理中心安装三个监控大屏，动态显示服务器及网络设备的运行状态及报警信息。网络中心工程师负责巡检机房及主要设备间，填写巡检记录。
针对各部门工作完成情况，系统自动进行分析，包含事件、需求和研发三个方面。主要对工作量、积压事件、聚集事件、完成与超时及需求现状与聚集等方面做了分析（见图1）。通过分析，科室负责人可以清晰地看到信息运维的现状、瓶颈及存在问题，便于及时调整（见图2）。
摸清家底，建立配置管理库
图3：CMDB讨论会
配置管理库即基础信息资料库，也就是业界定义的CMDB。它是信息系统的家底，包含了软件和硬件的基本属性记录、运维的历史档案及软件和硬件之间既定的支撑关系。例如，某个应用系统必须“依赖于”某个数据库和中间件，这个“依赖”就是支撑关系。整理CMDB是件艰苦的工作，信息部门为此召开了多次讨论会（见图3）。针对系统的每个软件模块，认真梳理了数据流分析、业务流程解剖、角色分配、服务器及网络依存关系等。其中，有两类关系进行了重点管理，一类是横向关系，是由于医院的业务流运作而衍生的业务数据流，以及相应产生在各个应用系统之间的数据访问，数据交互关系，这个视角是理解信息系统配置构成的主线；另一类是纵向的“依存性关系”，代表了一个应用系统自身能够存活的纵向依存关系，即每个应用系统与其支撑软件及硬件之间的依存关系。
1.横向关系：桥梁与桥墩
业务数据流是伴随着医院的日常业务产生的，业务数据流是医院日常业务的衍生物。换句话说，业务数据流是从信息化的角度去理解医院的日常业务。业务数据流的顺畅流通必须依赖于每一个应用系统的稳定运行。从依存性上来说，只有每一个应用系统都良好运转，数据流才能舒畅流通。如果说业务数据流是一座桥梁，那么，每一个应用系统就是一个桥墩。
理清业务流及业务岗位的关系，在系统中做好备注，当一个业务数据出现问题，是体现为前后的哪一个业务环节，应如何处置。对软件和硬件资源，业务数据流理清了，当数据无法正确传递的时候，需要检查哪些软件和硬件之间的关系，这样一来，维护工作就会变得容易多了。
2.纵向关系：梳理逻辑模型
表1：整体信息系统纵向管理梳理
在设计配置模型的时候，首先要界定管理对象的范围，有重点地管理核心对象，避免失去重点。
从纵向的支撑关系来说，我们将整体信息系统划分为纵向的八个层次（见表１），即业务角色层（医护岗位），业务数据层（医嘱等记录），应用系统层（HIS等应用系统），支撑软件层（数据库和中间件），服务器系统层（服务器系统），虚拟化层（虚拟化平台），硬件层（服务器硬件），基础设施层（网络和存储）。
梳理逻辑模型的意义有二。
第一，通过梳理信息系统的配置构成，使得信息化团队中的每个人重新梳理了自己所管理的领域，同时也形成了一个整体化的认识。使得每一个人都可以站在全局的角度思考问题，这是团队成员之间相互协作的基础。
第二，无论是事前设置预案、事中定位故障，还是事后分析根源，都需要依靠对信息系统配置构成的了解。因此，掌控信息系统的配置构成，是一个关乎业务长期稳定运营的重要事情。对于信息系统的构成，就不能仅依赖于个人的记忆，而要使信息系统的“配置图”成为可保存的重要资料。
涵盖流程，建立全生命周期管理体系
配置管理仅仅是一个基础性工作，而信息部门的三个主要职责是需求与建设，信息系统的运维管理，日常的使用服务。信息管理要从系统的全生命周期管理出发，形成一个涵盖“建、管、用”的连续管理体系。
1.运维管理
信息系统的重要性众所周知，但信息部门的工作压力却不是每个外行人能体会和理解的。不断网、不宕机，是信息部门运维工作的理想目标。为此，青大附院信息部门一直都在努力。
对于医院信息系统的运维管理，我们采取技术与管理并重的思路。
一方面需要采用技术手段，对网络、服务器、数据库、中间件、存储这五类重要资源进行集中监测，使信息部门具有对信息系统的完整巡视能力。
另一方面建立相应的管理机制，对于事前、事中、事后进行连续管理机制，做到在“事前”对潜在隐患有预案，对系统容量的态势有把控。在“事中”做到及早发现异常，工单自动派发，有人督促处置结果的闭环管理。在“事后”能够对异常情况有分析。
举例来说，我们的运维管理岗位，每个星期需要提交两个报表，异常情况的处置报表和业务系统的容量态势报表。异常情况的处置报表主要包含本周是否有异常出现，是谁处置的，处置结果是什么。例如，本周出现了几台交换机过热现象，虽然没有超过告警阈值，但说明这几台交换机所处的环境是潜在的隐患。根据这个信息建立预案，在该区域预备交换机备用。业务系统的容量态势报表包含当该业务系统的访问量在多少的情况下，数据库的性能表现（例如连接数），服务器系统的资源现状（例如CPU和内存），存储的性能现状（例如I/O数），网络的容量（例如带宽的占用）。通过这些数据来分析谁是瓶颈，何时需要我们补充多少资源。
2.服务响应
在保障信息系统稳定运行的同时，信息部门的另一个重要职责是辅助医护人员顺畅地使用信息系统。
我们对日常“服务请求”进行了梳理，定义了一系列“典型服务”，并据此形成“服务目录”。
同时，保持原有的“服务台”机制，集中受理来自医护人员的日常服务请求，并且依据这些“典型服务”的性质，梳理了对应的服务流程，形成闭环的管理机制。避免一些“服务请求”的丢单、漏单、错单现象，让信息部门内部的工作流程化，闭环管理，通过对“服务请求”的统计，逐渐量化工作，识别大量重复出现的工作，管控服务的完成质量，识别低效环节，成为改进的依据。
3.需求与改进
表2：对信息化进行服务管理前后对比
信息系统在运行期间，不断会产生一些需要改进和优化的地方，很多都是来自用户的口头反映。如何记录这些零碎的反映，并将其转化可管控需求，需要建立一个规范的管理流程。首先将需求分类，主要有优化、新建、预防、排错四类，并且赋予每一个需求优先级，对每一类设置相应处理流程，并设置管控环节，便于统计分析和后续跟进。
通过对信息化服务管理的实践，和以前的模式相比，有了明显改善（见表２）。
以上来源：e医疗2015年10月刊
点击查看“‘互联网+’时代的青大附院”专题往期精彩内容：
【e医疗原创】青大附院徐浩：走到“互联网+”之前，我们走了多少路
请继续关注该专题更多相关文章
“互联网+”的机遇
移动医疗及互联网应用
挖掘医疗数据价值，建设临床科研数据管理系统
十月阅读
您可点击订阅号下方菜单栏阅读“推荐”、“特别报道”中的往期精彩内容。
重要行业资讯
刊首语
推荐关注
e医疗2015年10月刊
“e医疗”原创文章，转载请注明来源。
▶e医疗
医疗卫生信息化资讯平台
微博 | @ e医疗
微信 | e-healthcare
杂志 | e医疗