基于医院信息系统范围管理的研究与实践

洪 丹

(北京世纪坛医院 计算机中心，北京 100038)



基于医院信息系统范围管理的研究与实践

洪 丹*

(北京世纪坛医院 计算机中心，北京 100038)

针对当前医院信息系统的特点以及建设过程中范围管理方面薄弱的现状，本文以信息系统项目管理为理论基础，把过程化的思想引入到范围管理中，将整个范围管理分为4个阶段:收集需求，定义范围，编制WBS以及控制范围。以此作为构建医院信息系统项目范围管理模式的基础，并提出了干系人分析法，分解子项目法，制定变更控制流程以及运用变更分析软件的指导方法，从而有效管理和控制了项目范围，确保项目如期按质量完成。

医院信息系统；范围管理；收集需求

随着信息技术的飞速发展，信息化项目在各行各业都有了非常广泛的应用。在关系到民众健康的医疗行业，用现代化的信息技术为广大民众提供优质、高效的服务显得尤为重要。

医院信息化建设在中国已有20余年的历史,医院管理者越来越深刻的意识到项目的成败不仅仅由技术因素决定,很大程度上取决于是否以科学的项目管理方法来实现。1987年由美国项目管理协会PMI推出的项目管理知识体系指南中，首次提出了项目管理知识领域的概念。经过不断地修订，该体系更加成熟和完整。其中“范围、时间、成本”被称为“等边平衡三角形”,即项目范围扩大,时间和成本必定增加。Standish Group公司曾对23 000个项目进行回顾性调查,发现《财富》500强企业中,由于控制了项目范围,按时、按预算交付项目由1994年的9%提高到了 1998年的24%,项目平均成本从230万元降到120万美元。可见，范围管理能对项目进行更好的控制和优化,提高项目实施成功率。

1 医院信息系统范围管理的问题分析

由于医院信息系统的复杂性,范围变化难以避免,建设过程中项目边界模糊、预算欠合理、工作量缺乏科学评估等问题屡见不鲜，更有一些项目甚至出现“抢时间建设”的情况，导致建设周期与实际情况脱节,最终造成范围失控，难以验收。种种问题无不困扰着信息管理者和实施者。

究其原因主要可以表现为以下几点：一是行业特点决定，医院信息化项目实施周期长、涉及部门众多，相对其他行业的信息化进程而言，具有较大的复杂度。系统建设之初通常不能确定最终解决方案的全部功能和系统架构。二是IT技术发展快,因为项目具有周期性,很可能项目还未结束,新的技术和标准已经产生。三是开发过程中没有规范化的变更管理流程，用户对信息系统缺乏全面地了解，再加上信息部门需求获取和分析工作不够细致，从而导致边界模糊、项目范围的蔓延或用户的不满意。

因此如何管理好项目的范围，已成为医院信息化建设走向深入的重点工作。下面分别从收集需求，范围定义，制定WBS以及范围控制这几方面来讨论如何对项目范围进行有效管理。

2 收集需求

医院信息系统的范围与需求紧密相关，需求收集和分析不到位会直接导致项目执行过程中范围的不断蔓延。因此在需求收集阶段，首先应减少沟通语义障碍，提高需求分析速度和准确率。应组织院方代表、项目组成员、信息部门进行充分沟通，从而使项目团队能够在短时间内熟悉医院的业务特点和行业术语，做好需求分析之前的准备工作。

为减少需求遗漏的可能性，项目经理应召集项目组以及与业务相关的部门负责人一起参加需求范围研讨会。可采用头脑暴风的方法，首先将干系人进行分组，进行多轮次探讨。经过数次筛选，项目组要逐步细化出对项目有效的需求，以及用户潜在的需求，从而使项目范围边界不断清晰。由于用户对软件系统的特点(如易用性和兼容性)缺乏全面的了解，这部分需求往往无法在初期确定，因此在开发中尽量采用原型法，先制作出一个实用模型让用户有一个直观印象。以此降低需求不明确的风险。

3 采用干系人分析的方法，进行范围定义工作

范围定义是制定详细项目范围说明书的过程，项目范围说明书详细描述了项目的可交付物和产生这些可交付物所必须做的工作。为了做好范围定义工作，项目组可以采用干系人分析的方法。首先识别出与医院相关的所有干系人。如院级领导、职能处处长、各业务科室主任以及各业务系统的具体操作人员等，再根据干系人的权利大小以及对项目结果的影响程度进行分组。利用权利/影响方格，对其需求进行管理。如图1是一个权利/影响方格矩阵的例子，用A～H代表干系人的位置。

图1 权利/影响方格矩阵Fig 1 Right/Influence square matrix

如院级领导组属于权利大，对项目结果影响程度高的组，可先将其需求重点管理，尽量满足院领导期望的各类数据，如各类财务报表，各科室医生用药情况以及各时段门诊量统计等。图中B、H、F代表院级领导组。而对于业务操作员组，虽然权利相对较小，但其需求是整个系统数据准确性和完整性的关键。为此，项目组也需要花大量精力对其需求和兴趣予以考虑，并及时将项目最新的情况与之沟通。图中C、E代表业务操作员组。尽量把干系人的负面影响降到最低。经过对各种需求和期望的几次筛选排序后，项目经理和项目组成员可以共同规定详细的范围说明书，此项目范围说明书是进行工作分解结构(WBS)的前提，所以必须得到医院所有干系人的一致认可。

4 采用分解技术，创建详细的WBS

创建工作分解结构(WBS)是把项目的可交付物和项目工作逐步分层分解为更小的、更易于管理的组成部分，工作分解结构是以可交付成果为导向的工作层级的分解，详细描述了项目所要完成的工作。

项目组成员应充分讨论，针对自身医院信息系统的特点，采用合理的分解技术，对WBS进行详细分解。如可以把子项目安排在工作分解结构的第一层，再分解子项目的WBS。以医院信息管理系统为例，其包含众多子系统，如住院管理子系统、中西药房管理子系统以及业务管理子系统等。其中中西药房子系统又包括入库管理模块，出库管理模块，调价计费模块和库存查询模块(图2)。

在工作分解结构WBS中必须设定范围基线， 每次到达基线时不仅要对基线进行评审和确认，还要对基线处的可交付成果进行评审和确认，并在确认时请院方代表进行签字确认，向院方代表讲述此时项目进行的状况和工作。这样有利于客户方对项目进展的了解。从而使客户对项目的工作进展有一个清晰的认识，为客户正确评价项目绩效提供依据和保证 。

5 制定完善的变更控制流程，做好范围控制工作

范围控制是控制范围变更的过程，是指在项目生命周期内对项目变更进行识别、评价和管理的工作，这也是项目团队的一项重要工作。医院信息系统HIS被业内公认为最复杂的信息系统之一，其复杂性表现之一就是需求的不断变化，导致变更的频繁发生。

5.1 制定完善的变更控制流程

针对医院信息系统项目规模较大以及可能出现的频繁变更，项目经理必须成立变更控制委员会CCB。(CCB的成员包括：项目总负责人、开发经理、医院相关部门负责人，质量管理员和配置管理员等)并制定严格的变更控制流程(图3)。项目实施过程必须按照此流程执行，确保所有变更请求都要以书面的形式提交到项目组。

首先各相关科室需要选定一名该科室的需求变更收集人，负责收集整理该科室医生提出的各项需求变更。项目经理对其进行评估，如需要将其转交给CCB讨论这些需求，并将需求按照对业务的影响程度，分出优先级，包括立即执行、推迟执行、拒绝，并给予回复。以项目核心模块——医生工作站模块为例，有些医生可能提出不在医生站打印处方，改为病人缴费后，直接到药房取药时打印处方，并提出这样做的好处(可以减少医生打印处方的环节、节省打印机的投入、防止“跑方”等等)。

图2 医院信息系统的工作分解结构示意图Fig 2 Work breakdown structure diagram of hospital information system

图3 变更控制流程图Fig 3 Change control flow chart

在接到书面变更申请后，项目经理需要对该申请进行详细的评估，并将其呈交给变更控制委员会(CCB)，经委员会成员全面分析，最后达成了一致意见。即在医生站取消处方的打印，首先不符合卫生部处方管理规定中要求的必须存有纸质处方，并且医生必须在处方上确认盖章。同时病人在取药时才见到处方， 在一定程度上侵犯了病人的去医院外的药店买药的权力。经过上述分析，虽然医生站取消处方打印对医院有不少好处，但为了保障病人的权力和方便就医，同时也为了严格遵守卫生部的处方管理规定，决定不进行本次需求的变更。会后，项目经理需要把本次评审的结果和理由以书面的形式通知了相关的科室和医生，并与之进行面对面的沟通，使申请者顺利接受评审的结果，同时也避免了盲目变更造成的负面影响。

5.2 借助软件工具，可以对需求变更的影响进行分析

在分析变更影响时，可以运用需求数据库软件，对需求的变化做出完善的记录。需求数据库可以显示需求的层次性，因此便于追溯。经过一段时间的积累和总结，可以从变更类型、变更原因和变更者三个方面来分析需求变更。变更类型包括 ：增加功能、改进功能和错误改正。变更原因可分为：需求增加、缺陷修复、程序运行错误、业务流程变更、遗漏需求、模块改进、产品策略、设计改进、范围缩减、错误的需求和解决冲突等。变更者是变更的发起人，包括：项目经理、市场部门、开发人员、系统需求分析员、院方领导、测试工程师和科室使用人反馈(图4)。

某医院电子病历系统试运行阶段(2012年5月～2013年3月)采集到的需求变更数据， 按照上面的变更分类，可以得到表1的数据，在这一阶段内处理的160次的需求变更中， 有31次(19%)变更是因为新增需求，针对这种情况需要及时与相关部门沟通，仔细评估新增需求对项目可能造成的各种影响及后果，并严格遵循先前制定的变更控制流程，确保所有新增加的需求都在可控的范围之内。有 51 次(32%)变更是因为程序运行错误，针对这种情况应当提高软件的质量，加强测试的力度，并对开发人员进行相关的专业培训。有 39次(24%)是系统设计改进方面的问题，针对这一原因应当增加与使用人员的沟通，对其需求进行分析，细化改进等。这种方法可以使项目组能够有效地定位变更的原因，有的放矢地减少需求变更所带来的负面影响。

图4 变更分类分析Fig 4 Change classification analysis

变更原因新增需求业务流程变更程序运行错误严重错误次要错误程序运行错误系统设计改进其他总计数量31158433924160

6 问题和展望

医院信息系统建设对所有参与者都是一个反复学习、迭代开发的过程。在系统实际开发中，范围管理贯穿于项目生命周期各个阶段。由于医院信息系统自身复杂性的特点,范围变更在所难免，任何一个细小的需求都会引起项目范围的变化。例如在程序界面设计上，如果没有做好与用户的沟通，在试运行阶段，用户极有可能对操作界面提出很多异议，导致界面设计工作范围变化，甚至返工。但是无论怎样，作为项目负责人，必须确保项目按照范围管理的方法来执行，尽可能减少由于范围问题给项目的质量、时间、成本带来巨大的风险。因此，如何更好的把范围管理的精髓运用到实际项目中去，还有待研究、探索和总结。

[1] 张友生. 信息系统项目管理师考试辅导教程[M].3版 北京:电子工业出版社,2012:372- 384.

[2]白岩，李婧，张红，等.移动护理系统的设计与应用[J].中国数字医学，2013,8：28- 29.

[3] 邬静艳，王平，陈雯，等. 临床路径信息系统的设计与初步探索[J].医院管理论坛,2012,29：60- 61.

[4] Project Management institute 项目管理知识体系指南[M].5版.许江林，译。北京：电子工业出版社，2013:105- 107.

[5] 罗晶，王海威，陈永鹏，等.拉美四国医院信息化建设启示[J].中国数字医学, 2012,7：33- 35.

[6] 王飞，韩金淑. 信息系统项目中的范围管理研究[J].电脑知识与技术, 2014,10：56- 57.

[7] 胡芳，沈绍武. 中医医院药事管理信息系统的需求分析与构建[J].中国药房, 2014,25：37- 38.

Research and practice of scope management of hospital information system

HONG Dan*

(Computer Net Center, Beijing Shijitan Hospital, Beijing 100038, China)

Reviewed current hospital information system especially the characteristics and construction process of weakness management，in this paper, based an the theory of project management, the strategy of process controls is introduced into the scope management.The whole scope management process is divided into four stages: requirements collection scope definition, draft WBS and control scope. The key points are construction of hospital information system project scope management model,and then intreduced the stakeholder analysis, the decomposition sub project concept, the formulation of the change control process and the use of analysis software.Thus the effective management and control of project scope, to ensure the project on schedule meets the need of quality of control.

hospital information system；scope management；collect requirements

2015- 07- 17

2015- 09- 26

1001-6325(2015)11-1586-05

医学教育

TP3

A

*通信作者(corresponding author)：chenglu138@sina.coom