《信息系统项目管理师-范围管理论文》由会员分享，可在线阅读，更多相关《信息系统项目管理师-范围管理论文（3页珍藏版）》请在金锄头文库上搜索。
1、信息系统项目范围管理摘要2012 年 5 月，我参加了某三甲医院电子病历及移动医疗项目的实施工作，该项目以软 件项目为主，主要包括医生电子病历、护理电子病历、CDR 数据集成平台和电子病历上传接口、移动护理和移动医疗在此项目中我作为项目经理全面负责此项目的管理工作。由于电子病历系统(EMR) 是近几年逐步在卫生系统试点、实施的信息系统，行政主管部门只对其功能有框架要求，对系统架构、数据集标准、知识库的标准都没有做具体要求，同时该系统本身与医院信息管理系统（HIS）边界模糊、与LIS 系统、 PACS 系统等系统又有较多的数据互换和交集。为使项目有序实施，项目的范围管理在此项目中显得由为重要。在
2、本项目范围管理过程中我通过范围计划编制、范围定义、范围分解和编制范围分解字典、范围确认以及通过变更控制系统控制范围变更，在项目实施过程中有效防止了范围蔓延，使项目按期、保质通过了用户验收，获得了医院认可和公司领导的认同。正文2012 年 5 月，我公司承建某医院电子病历及移动医疗项目建设，由于我有较丰富的电子病历实施经验和一定的项目管理经验，公司委派我为此项目的项目经理。该项目涉及软件和硬件的综合项目，软件项目主要包括：医生的电子病历，护理电子病历、CDR 数据中心及电子病历上传接口、移动医疗、移动护理。该项目于2011 年 5 月启动，根据公司与医院的合同规定项目工期为1 年，要求在2013
3、 年 5 年完工。该项目涉及到软件和硬件，项目组成员由软件开发开发部、项目实施不、系统集成部及移动事业部等多个部门组成。项目管理过程是定义范围，确定范围和控制范围的过程，项目范围在项目初期开始确定，在项目过程中不断完善和渐进明显。项目范围说明书则是项目范围的主要依据，其内容主要包括： （1） 项目目标， 主要有成果性目标和约束项目目标，是项目成功与否的主要评价依据；（2）项目需求，项目干系人对项目的期望和要求；(3)项目边界 ,鉴定项目包括什么，不包括什么； （4）产品范围说明、项目可接受标准、项目的约束条件、项目的假设条件、初始项目组织、 初始风险、 项目预算、 资金限制、 进度的里程碑、
4、项目规范、 配置管理、 变更需求等。项目范围说明书是项目分解结构的主要依据，依据项目范围说明书进行项目范围分解。主要步骤有：范围结构的识别，方位由于电子病历系统(EMR) 是近几年逐步在卫生系统试点、实施的信息系统。虽然卫计委在2010 年出台了电子病历系统功能规范（试点） ，对系统功能规范有框架式的要求，对其系统架构、 数据集标准、 知识库的标准都没有做具体要求。同时该系统是直接提供医院医疗服务的辅助工具， 在医院各系统中处于中心地位，理论上将医院的所有系统都应该以电子病历为中心， 是医院数据共享度和集中度最高的系统。而事实并非如此，医院的往往有不同时期，不同软件商开发的应用系统，有些功能交
5、叉从属，很难鉴定。如在通常意义上病历中医生的医嘱是病历中不可或缺的重要部分，手工模式下只要将医嘱和病程记录的内容装订在一起就是一份完整的病历，但在信息系统中这往往是边界最模糊的一部分，从数据结构和关系而言，医嘱最主要的是药品内容，药品库是HIS 系统中的内容，但在医生的眼中这就是病历的内容，应该在电子病历中实现。为使项目有序实施，项目的范围管理在此项目中显得由为重要，在此项目中我运行项目管理的项目知识，理论联系实际。1.范围计划的编制范围管理计划是对项目范围定义、确认和控制方法的描述和用什么方法进行项目范围的分解。我依据本项目的项目章程、初步的项目范围说明书、项目管理计划， 并参照公司在201
6、1 年 11 月在江苏某三甲医院实施的电子病历项目的项目资料。同时由于我没有参与过移动护理项目的实施经验，在项目计划的编制过程中我请教了公司移动事业部的同仁， 给予了很多有建设性的建议，如他提出移动网络的建设虽不包括在内，但系统上线时不能缺少网络环境测试这一环节，在后续的实施中确实发现客户的网络环境存在诸多问题，由于我们增加的测试，使项目在上线前得到解决。而WBS 的分解涉及内容多，又有交叉从属，我采用先将项目分解成电子病历、移动医疗和CDR 集成三个小项，每个小项目内用生命周期的方式来进行分解。2.范围定义范围定义的过程是对项目的范围和需求明晰化的过程，由此制定出详细的范围说明书， 为后续的
7、决策提供依据。首先我对此项目的初步范围说明书进行认真研究，对项目的范围有了初步了解。其次，我在销售经理叶经理处拿到了改项目的用户项目干系人名单，在叶经理的引荐下在项目启动之初拜访了项目的主要干系人，在拜访中我发现本项目的主要干系人之间对项目范围的界定有较大的差异，如医院的信息中心主任由于是该项目的主要负责人和我公司沟通比较到位对项目范围的界定和公司的初步范围说明书中基本一致，而医院与本项目相关度最高的2 个部分医教科和护理部的领导则有不同的意见，如在医嘱部分最初的模式是医嘱在HIS 的住院医生工作站开嘱，电子病历系统取HIS 生成的医嘱表，医教科认为开医嘱是医生使用最频繁的部分，分别在 2 个
8、系统中实现， 带来工作上。 为此我们评估技术方案后将代界面集成纳到了本此项目的项目范围。同时由医教科、 护理部根据现有的手工护理的模式，提供了此次项目需要完成的表单。3.WBS 分解和 WBS 字典WBS 使项目分解成颗粒度更小的，便于项目职责划分后项目成本、 进度、 质量等控制的工作包的过程。根据已经制定的详细范围说明书和从公司项目管理获取以往类似项目的WBS 模板。我开始着手对项目范围进行分解。我根据本项目的特点用树形结构作了颗粒度比较大的分解表，这张分解表我将项目按组织结构，项目的生命周期和可交付物三个层次分解成比较直观分解结构图。但由于本项目相对结构比较复杂，周期长，在树形结构的基础上
9、标准了表格式的WBS 分解表，表格式的WBS 虽然不是和直观但是，其包含的内容比较多，可以逐层进行分解。同时我使用滚动计划的方式，将近2 周内要完成的工作进行分解详细，并形成工作包， 使项目组成员不仅明确我们的总目标，更知道当前需要做什么。4.范围确认范围确认是项目干系人接受项目的可交付成果的过程。在本项目中我设置了几个确认点， 一是，详细范围说明书编制完成时，在医院信息中心主任的帮助下组织了医教科、 护理部以及部分临床科室医生、护士参加的项目启动暨项目范围确认会议，会议中我运用 PPT 以及公司的DEMO 进行演示；二是，在项目的关键点设置由客户参与的检查点，如在系统上线之前，完成内部测试后
10、即组织由医院相关人员参与的检查与测试，在功能与范围确认后在上线；三是，采取建立试点科室的模式，在一个科室运行一段时间，由个别科室试运行逐步完善的模式，使项目有序推进。5.范围控制项目需求蔓延是项目失败的主要因素，所有项目的范围控制至关重要，项目范围控制主要是对项目变更的控制，在项目实施过程中各种变更在所难免，特别是软件为主的项目， 由于业务流程的个体差异，需求的变革在渐进明细中不断的提出。有效的项目管理是减少不必要的变更的前提下使变更有序的进行。根据以往的项目经验，在项目的规划阶段我就制定了项目变更控制流程，确定变更控制各级审核和审批的权限。由于项目是在客户现场实施的， 无法使用公司OA 下面
11、的电子变更申请单，我就把表格打印出来，由各个部门手工填写。 通过有效的变更控制使项目按计划的进度进行，同时也使项目在满足客户需求的前提下于2013 年 5 月顺利验收。在本项目的实施过程中我运用范围管理理论和实践经验防止了范围蔓延，用规范的管理使项目在预定的范围内行进，而项目的实施过程总是千变万化，在种种的应对中，更让我收获了很多在书本上无法学到的项目管理经验：1.真诚沟通， 应对范围确认过程中出尔反尔在本项目实施过程中，前三分之一医生部分的电子病历可谓比较顺利，由于医教科有个精通业务又喜欢信息技术的医教科科长，在项目的实施中能把业务需求和电子流程很好的结合。可到了护理部分的电子病历着手让项目
12、组虚惊了一场， 护理部主任在范围定义时要求用现有的手工文书作为模板进行流程设计和模板开发， 并对之进行确认，而项目组在进行阶段确认时，发现手工模式和电子化的模式其实在流程上还有很大的区别，照搬手工模式其实使工作量增加不少。护理部主任一时有点茫然，不知道如何重新设计她的流程，忽然说让我们参照某家医院的照搬过来，我当时有点回不过神，要知道那家医院是另外一家公司开发的软件，和我公司开发的不管是开发语言、编程方式、数据结构都截然不同，照搬他们的意味着全盘重新开发，那该是怎样的工程量，估计再由 1 年我的项目组也完成不了这个项目。我把我的苦恼和难处反映给客户方信息科科长，他对医院的业务熟悉又懂信息技术，
13、首先他也认为照搬是不可能的，同时他就我反应的问题单独和护理部主任了解情况，回来后告诉我其实我没有做真正的理解她的意思，她其实是对新流程更好的改造方式，只要我们能提供切合新流程技术解决方案她也是能认可的。于是我们在信息科长的帮助下提出了我们能实现护理部又能接受的方案2.因力势导， 解决项目变更中随意性和规范性的冲突项目组是临时组建的，每个人对规范的依从性不一样，特别是在变更控制中我要求变更一定要求书面的记录和审核过程，个别项目组成员起初不以为然，认为填写这么多表格纯属浪费时间，特别是小的变更直接改一下就行了， 其中一次在一个皮试确认的环节，有个医生提出来他也能看到皮试确认界面，开发人员认为只要做
14、个调用和PBL 挂接就可以，就直接改了，结果在试点科室试用时差点出医疗纠纷， 按医疗流程， 过敏药物的皮试是由护士执行和确认的，药房在确认该病人皮试“阴性”的情况下才能发药，而我们的程序由于在医生界面也有确认功能，医生误操作把一个皮试“阳性”的药品点成了“阴性”，药房发了该药，幸亏在最后用药的环境护士发现这个结果有问题。 追查此事的原因时我才发现，皮试确认功能上有此变更。我以此为例，在项目组内召开了专题讨论会，该程序员承认了此错误，同时项目组也对我照办公司的流程变更表提出了意见。 于是， 我根据大家提出的意识将变更流程表重新进行了设计，在表格中对变更的影响程度进行分级，如对于影响小的变更用相对简化的流程，影响大的变更审核流程。进过磨合，项目的规范意思得到明显提高。我的前辈曾经说过一句话，项目开始容易，收尾难啊，在本项目中我虽然用范围管理知识避免了项目深陷范围蔓延的泥潭。如期完成项目， 获得客户认可， 也得到公司领导的认同。但在
