医院绩效精细化管理系统方案

 

 

 

目 录

第1章 对项目理解及项目整体技术框架

1. 对项目的理解

1.1 项目理解

1.2 项目建设思路

1.3 项目问题剖析

1.3.1 绩效管理情况

1.3.2 系统情况

1.4 整体技术框架

1.5 技术架构设计

1.6 医疗机构标准化改造设计

1.7 医院绩效精细化管理系统集成平台设计

1.8 医院绩效精细化管理系统设计

1.9 医院绩效精细化管理系统监管平台设计

1.10 医院绩效精细化管理系统对接设计

1.11 业务流程设计

第2章 完整的产品清单及描述

2.1 产品清单

2.2 功能描述

第3章 人员配置

3.1 实施组织设置原则

3.2 项目实施组织架构

3.3 项目组职责分工

第4章 实施计划

4.1 实施方案

4.1.1 软件需求分析

4.1.2 系统设计阶段

4.1.3 系统实现阶段

4.1.4 系统测试

4.1.5 系统部署

4.1.6 系统试运行

4.1.7 系统验收上线

4.2 售后与培训计划

4.1 培训内容及大纲

4.1.6 售后服务内容

第5章 工期及质量管理

5.1 工期

5.1.1 进度控制目标

5.1.2 实施进度计划管理

5.1.3 WBS工期分解过程

5.2 质量管理

5.2.1 建立标准化工作程序

5.2.2 完善的人员管理措施

5.2.3 完善的问题管理措施

5.2.4 实行阶段性成果提交与变更控制

5.2.5 实行里程碑式的审查与版本控制

5.2.6 全面测试

5.2.7 系统实施过程的质量保证活动说明

第6章 突发事件处理

6.1 应急措施及组织结构

6.2 应急工作小组机构及职责

6.3 应急基本流程

6.4 紧急事件类型

6.5 预防措施

6.6 突发风险应急策略

6.7 业务证明数据损坏应急预案

6.8 服务器软件系统故障应急预案

 

第1章 对项目理解及项目整体技术框架

1. 对项目的理解

1.1 项目理解

目前国内大多数医院现有的绩效分配制度以传统的收支节余分配制度为主，医、护、技再按照简单的系数分配，不能客观的衡量医务人员的劳动价值和实际贡献，不符合相关的政策要求，影响员工的工作积性，同时也可能存在工作责任归属不清，影响医疗品质的界定，x终影响医院的长远发展。

因此，根据《关于印发公立医院成本核算规范的通知》（国卫财务发〔2021〕4号）、《关于印发公立医院全面预算管理制度实施办法的通知》（国卫财务发〔2020〕30号）、《关于开展“公立医疗机构经济管理年”活动的通知》（国卫财务函〔2020〕262号）及《关于进一步规范医疗行为促进合理医疗检查的指导意见》（国卫医发〔2020〕29号）等文件精神，结合医院战略发展目标，我司将搭建以医务人员的工作量、服务质量和医疗技术含量的价值为基础的绩效管理体系，充分调动员工的积性、主动性和创造性，树立正确的医院激励导向和医务人员价值导向，促进医院健康良性发展。

1.2 项目建设思路

（一）找准功能定位，优化病种结构

• 加强成本管控

在不影响医疗质量的前提下，通过临床路径实施过程控制。规范病组诊疗行为，实施合理用药耗、合理检验检查，合理控制住院医疗费用。

• 提升运行效率

加强各病组住院流程环节控制，缩短病组平均住院日，提高病床周转率。

• 保障质量安全

提升医疗质量，通过临床路径，规范医疗行为，保障患者安全;同时杜绝由于质量问题造成的资源浪费。

• 加强绩效管理

DRGs付费制度下，医院的管理者更加重视规范医生的行为及绩效管理，在保障患者质量安全的前提下，避免医生在治疗上花费过高的成本。

（二）业务与财务管理融合

应用DRG结合临床发展与运营管理，关注重点专科建设，保持竞争优势。

 

 

（三）建立以DRG为核心的成本核算体系

• 科室成本核算

从医院全成本核算入手，提高医院成本管理的意识与能力;建立目标成本管理，减少不合理成本的支出，提高科室经济运行效率。

• 项目成本核算

项目成本核算主要用于支撑DRG成本、病种核算，精细的核算可以准确地帮助医院找到成本控制点，进行资源配置的优化；提供医疗服务项目价格调整和新型x财政补偿的数据依据。

• 病种成本核算

基于DRG的病种成本核算再结合临床路径，医疗机构有效的在病组层面进行成本管理。

（四）保障质量安全—以临床路径为抓手、节约成本

在DRG付费下，医院成本的有效管控，需要用临床路径的方式来规范医生的诊疗行为，优化院内的支出结构，药占比低，为人员费用提供空间。反之，不重视正确的调整支出比例，导致医疗质量低下将会延长住院时间、增加住院费用，就会间接导致医院成本增加。

(五）优化院内的CMI结构

DRG支付制度改革的一个重要方向就是优化三公立医院的CMI结构，使得他们能将更多的精力放在危急重症、疑难杂症中，而非常见病、慢性病领域。结合实例进行了该方面内容的阐述，示意图如下：

 

1.3 项目问题剖析

1.3.1 绩效管理情况

• 绩效考核导向不正确，未能突出公益性的办院宗旨。

绩效管理的效果受考核目的直接影响，作为综合性x医院，在目前发展形势下，x大限度保障老百姓健康的水平，建立和谐医患关系，解决老百姓看病贵、看病难应作为医院主要发展方向和应承担的责任。而目前绩效考核把经济作为先进指标，其直接导向是科室经济效益的x大化，其日的从源头就偏离了公益性方向。

实现组织战略和发展日标是绩效管理的终目的，组织战略目标实现的基础离不开绩效管理，为了实现医院的总休战略目标需要通过绩效管理过程将医院的战略目标分解到各科室乃至各岗位，通过各科室、岗位对绩效目标的实现而达成。医院的战略是坚持一切以病人为中心，突出医院的福利性和社会性，实现两个效益协调发展的宗旨。但纵观众多医院的绩效管理，其核心部分是建立在成本核算基础上的经济效益的考核，没有体现医院的战略目标，对社会效益的导向较弱，真正导向是倾向于医院经济效益的增长，与医院的战略目标处于脱节状态。同时，新医改方案明确提出公立医院应遵循公益性质和社会效益原则，而以岗位工作量为主的综合绩效考核和岗位绩效工资制度显然不能与之相适应。

• 绩效考核因素缺乏科学性。

绩效考核因素是绩效方案的关键，科学的考核因素能全方位立体地评价整体和局部的成绩，是医院战略管理取得成功的保证。目前的众多医院的考核指标因素，由于方法单一，未注重总体综合评价，从而使考核成绩较为模糊，缺乏科学性。所有指标的设计都针对经济利益方向，导致各科室在运行过程中集中地关注经济指标，甚至不惜以牺牲根本基础来保证经济指标增长的现象。同时，由于医院绩效管理模式中没有单病种总量考核指标及医保机构满意率指标等综合考核因素，显示出其不能适应新医改的大方向。

• 医院绩效管理未能体现激励和约束相结合。

众多医院的绩效管理未能体现激励和约束相结合，所有与之相关的工作都是对经济指标的激励，目标都指向经济效益的x大化。根本没有与之匹配的约束机制。约束与激励是一对矛盾统一体，缺乏约束的激励结果直接导致管理在某些领域失控，科室在运行过程中在医保、单病种、内部流程、患者、学习与成长方面没有标准可依，自然将追求经济利益作为先进目标，使得目前绩效管理弊端日益凸显。

• 绩效管理组织不健全，主体不明确。

建立强有力的组织保障体系是绩效管理成功实施的关键，高层领导及砖家的意见举足轻重，要具备有高层领导及砖家、职能科室人员直接参与的砖家组共同构成组织体系。目前众多医院的绩效考核基本都是由经营办一家部门组织和实施，从政策的制定、方案的实施、数据的核算、日常监督和记录都是该部门负责，由于没有砖家组及职能科室的参与，受科室专业水平所限，导致很多方面的考核流于形式。

基于上述分析，目前的公立医院绩效考核存在许多弊端，某些方面加剧了患者看病难、看病贵的问题，因此，设计一套与目前医院发展相适应的公立医院绩效精细化管理体系是医院管理者迫在眉睫的问题。

1.3.2 系统情况

由于健康管理和卫生服务本身固有的特殊性和复杂性，卫生系统发展整体水平还是不高，目前存在以下主要问题：

1、数据共享问题

现在大部分公共应用系统，如传染病直报、卫生监督、血液管理和慢性病管理等应用系统均为业务领域内垂直系统，缺乏业务条块间的横向连接，信息无法互通共享；

2、驱动力问题

某些应用系统动用了大量人力、物力和财力来建设，但建设完成后业务部门没有有效应用，数据长期没有更新，成为摆设。而且现在大部分业务系统都不是业务部门主动开展的，基本以上文件要求技术部门主导建设的，导致建设过程困难重重，应用效果不够理想；

3、服务功能问题

现在建设完成的大部分应用系统以内部管理为主，而对外向老百姓提供服务的应用系统数量较少，功能较弱，如何在以后建设过程中把重点放在对外提供服务上需要进一步完善和探讨。今后五年的系统建设工作，要着力解决这些不足，推进卫生系统更好更快发展。

4、医院医疗业务效率有待提高

由于目前很多社区卫生系统建设属于单个业务驱动模式，医院绩效精细化管理系统与HIS建设步伐不一致，采用的是两个独立的系统，两者孤立，彼此之间没有信息共享机制。存在数据缺乏共享，造成重复录入；健康档案无法及时记录、更新和完善，变“死档”；健康档案在医疗活动中无法利用，利用率不高，使健康档案没有发挥其价值；数据存放分散，不利于后期的数据利用和数据服务等问题。

1.4 整体技术框架

1.5 技术架构设计

医院绩效精细化管理系统基于现有基础进行建设，在对当前业务生产系统及平台进行完善的同时，根据考核要求，通过对绩效考核模型的构建，实现对医院医务人员绩效的分析与评估。

 

结合项目总体技术路线要求，采用面向服务的体系结构（SOA）的技术路线，通过基于SOA的总体技术架构，为本项目实现提供技术支撑。

面向服务架构（Service Oriented Architecture， SOA）促进了灵活的、可重用IT资源的创造，实现了端到端的业务解决方案。而SOA参考架构的使用是实现SOA价值主张的一个关键因素。

SOA参考架构的标准化提供了一个行业认可的、供应商中立的基线，来实现客户化SOA解决方案。这样可用于多个机构共同合作的场景，尽管供应商或系统集成商等存在变更。SOA参考架构提供一种常见的分类系统和术语表，来设计、构建和描述SOA解决方案。这不仅省时省钱而且也可以改进结果。

对采用SOA的组织，SOA参考架构可以帮助创建业务流程驱动的解决方案、业务工具、消息交换、服务集成、数据访问以及封装软件和组件。当架构师应用SOA的建模和交付方法论时，每个已被识别的SOA元素被映射到SOA参考架构，来提供SOA解决方案如何进行的视图。这也为特定机构或行业中的业务和IT利益相关者提供一个非常有用的通讯工具。

在SOA体系架构中，服务资源的交付形式即可以是基于WS-*标准的WEB服务，也可以是面向互联网的轻量REST API服务；通过平台服务总线实现对平台上全部开放服务资源的统一管理、发现、调用和监控；支持HTTP/HTTPs、SOAP、DNS、JMS等应用层服务访问协议。

1、门户层

展现服务层定义企业信息门户（EIP）中可配置、可重用的门户组件（Portlets），用于支持门户应用的开发；以及人机交互组件、网页组件、报表组件，实现对健康档案浏览器、移动APP等不同客户端接入方式的支持，并提供丰富的客户端展现方式。

通过基于互联网的统一门户实现，是系统应用面向特定用户发布的渠道，根据绩效考核系统使用及信息发布特点，一般包括门户应用、邮件封装、移动应用等。

2、服务层

服务组合层通过对下层的访问服务、数据服务、业务服务的编排来实现，流程编排的规则在该层内定义，通过服务的编排组合就可以快速搭建出新的业务应用系统。业务数据集成平台通过服务层实现一系列数据交换服务，实现对接入层数据的注册、采集、存储、加工，为数据进一步量化分提供技术支撑。使用平台服务总线进行统一的服务注册管理，编排、路由、监控实现服务集成。

3、应用层

业务服务层定义那些可重用的业务处理过程，用于支持复合的业务处理需求。这层定义的业务处理过程服务可能是单个原子事务的无状态处理操作服务，也可能是多个业务应用或异步服务之间交互的有状态处理操作服务。实现平台数据的具体应用和前台展现，包括考核对象管理、考核管理，以及质量考核、监督、管理、评价、服务等具体业务内容。业务服务层之上的开发者无需知道具体某项业务的逻辑处理过程。

4、数据层

数据服务层定义的服务支持把异构的、孤立的企业数据转变成集成的、双向的、可重复使用的信息资源。通过服务层将接入层数据及量化分数据进行分类存储，按照主题的形式存储，包括考核对象资源库、个案资源库、考核指标数据库，实现按考核业务类型、考核对象、考核时间等维度的数据运算。数据服务通过访问服务层以统一的方式访问企业的所有数据，数据服务层之上的开发者可以集中精力处理数据的加工问题，而不必关注访问不同来源的数据的实现细节。

5、访问层

访问服务层实现与底层数据资源、应用资源的通信功能，使用通用标准接口，定义整合企业信息资源（数据资源与应用资源）的各种访问服务，例如：不同类型的适配器以及专用的API等等。访问服务屏蔽了企业信息资源（现在的或未来的）的技术和实现方式，访问服务层之上的开发者无需知道数据的位置、类型以及应用程序的编程语言等。

6、交换层

服务间的消息交换和消息传输贯穿的各个服务层。消息交换和传输可以采用企业服务和消息服务总线二种机制。是绩效机制改革绩效考核信息系统的数据来源，主要指运行在医疗卫生机构的基本医疗和基本公共卫生等与医务人员工作相关的业务应用系统，其通过医疗卫生机构业务数据中心的数据通道接入财政绩效机制改革绩效考核信息系统，按照系统所定义的标准上传统计及个案数据。服务间的消息交换需要基于通用的交换标准和行业的交换标准。消息传输层提供通用的传输协议支持，如HTTP/HTTPS、SMTP、JMS、FTP等。

7、基础设施层

安全管理和服务管理贯穿各个服务层。在区域卫生信息平台中，信息安全与隐私保护主要在安全与服务管理层体现。系统建设所需的基础设施，包括主机、存储设备、网络、安全设备和系统软件等。

1.6 医疗机构标准化改造设计

基于医疗机构执业许可证登记号和医务人员身份证号，建立医疗卫生机构人力资源管理体系，实现人力资源信息统一管理，并将登记号和身份证号作为机构和个人的先进识别标识，确保业务工作量在医疗卫生机构、服务团队（科室、站点等）、个人等多个层均具有明确的归属，同时也为医务人员多点执业产生的工作量提供划分依据。系统主要功能包括：人力资源信息新增、人力资源信息变更及维护、人力资源查询。

1.7 医院绩效精细化管理系统集成平台设计

构建一个统一、开放的业务数据集成平台，以医疗卫生机构和医务人员先进标识为核心载体，通过数据接口方式，从区域卫生信息平台采集业务数据，实现绩效相关指标数据的精细化x小颗粒度采集和存储，并形成考核指标数据库。

考核指标数据库主要依赖于业务数据集成平台生成，也可包含在业务数据集成平台之中，是整个财政绩效机制改革绩效考核信息系统的考核数据源。考核指标数据库根据业务数据集成平台汇聚的明细数据和预设的指标值算法进行计算，形成可直接用于特定时间对特定机构和特定个体考核的x小颗粒度数据库。为确保绩效考核方案的灵活运用，考核指标数据库可以单独成库。

考核指标数据库实现针对特定考核对象（机构、科室站点、团队、医务人员）在特定间隔时间内（年、月、旬、周、天以及任务时间段等）的标准当量（工作量）的统计，工作量指标满足《关于全面推进医疗卫生机构绩效机制改革的实施意见》要求。考核指标数据库的数据x小的单位属性包括各种不同业务类型、x小考核单位（医务人员或x小团队）、x小考核时间（天），以满足各种不同业务类型、不同统计口径、不同对象层次、不同时间段等维度考核的数据查询分析。

1.8 医院绩效精细化管理系统设计

本次绩效考核管理平台需要与各医疗机构之间业务系统对接，在数据迁移工程中，原系统数据质量是影响数据移转项目进程以及质量的决定性因素。因此，在项目启动初期或者数据清洗过程中设计数据清洗规则时，将同时进行数据的质量评估。可通过完整性、准确性、关联性、及时性、稳定性这五个维度综合评价。

 

上述五大维度包括所有业务表的关联性、数据完整性以及部分字段的数据准确性；通过部署在前置机的质量评价体系评估各医疗机构的实际数据提交数据的质量，并将这些信息上传到数据中心，从而获得量化的各医疗机构数据上传质量评价，以便督促各医疗机构提高数据的上传质量。

基于绩效相关指标数据的精细化x小颗粒度采集，实现机构绩效考核方案的自主配置和管理，包括工作数量、工作质量、满意度等多维度考核指标的可配置化，以及各类权重、考核周期的自主设置，并实现考核指标数据的查询、对账、填报、确认、审核、评定、拨付、核算分配等流程的电子化管理。

1.9 医院绩效精细化管理系统监管平台设计

基于统一、开放的数据集成平台，提供相关智能分析界面，为辅助决策服务，实现对医疗卫生机构绩效指标的图形化展示和业务趋势分析、预警，对各医疗卫生机构的预设绩效指标进行综合排名，对预设指标项异常变化进行预警提醒，并根据已有生产数据和辅助录入数据，对当前补助金额进行计算，对趋势绩效金额进行估算，综合后形成绩效金额趋势分析图表，对趋势绩效资金超过预设范围的情况进行预警提醒。

可以按机构及指标等多维度查询分析考核标化工作当量数据，具体包括：同类机构某时间段工作当量汇总表、同类机构某时间段工作当量明细表、每医疗机构某时间段工作当量汇总表、每医疗机构某时间段工作当量明细表、每医务人员某时间段工作当量汇总表、每医务人员某时间段工作当量明细表、每指标项某时间段工作当量汇总表、每指标项某时间段工作当量明细表。

 

1.10 医院绩效精细化管理系统对接设计

根据实际情况，我司将结合医疗机构使用场景进行设计，从而把本次平台建设内容延伸至移动端，实现在微信及钉钉系统中进行数据查阅、搜索，并对数据信息进行分层分管理及呈现，x终实现移动端的应用实现与微信及钉钉平台的对接，使工作人员能在移动端操作。

 

1.11 业务流程设计

 

按照XXX、省、市的互联网+医疗健康支撑平台试点的要求，构建一个统一、开放的业务数据集成平台，在对当前医疗卫生机构业务应用系统进行完善的同时，根据考核要求，通过统一、开放的数据交换平台实现有关明细数据的汇聚。以医疗卫生机构和医务人员先进标识为核心载体，汇聚的数据包括但不限于电子健康档案、门诊住院就医信息、慢病信息、签约服务、双向转诊、妇幼保健、预防接种、结核病、传染病报告、重性精神病管理等考核绩效相关信息。通过数据接口方式，后续如有项目的增减，可通过调整数据交换平台的对应接口表实现。汇聚的明细数据，通过对绩效考核模型的构建，实现对医疗卫生机构医务人员绩效的分析与评估。

在建设数据交换平台时，数据来源主要是指运行在医疗卫生机构的基本医疗和基本公共卫生等与医务人员工作相关的系统系统，需要对系统的数据质量进行把控，针对覆盖范围更广、数据粒度更细、包含数据更多的新接口，需要建立配套的数据质量控制体系，优化数据交换及存储模式，建立配套的数据质量管理体系，以保证数据的完整性、准确性和一致性。

 

基于业务数据集成平台，实现机构绩效考核方案的自主配置和管理，包括工作数量、工作质量、满意度等多维度考核指标的可配置化，以及各类权重、考核周期的自主设置，并实现考核指标数据的查询、对账、填报、确认、审核、评定、拨付、核算分配等流程的电子化管理。

 

第2章 完整的产品清单及描述

2.1 产品清单

一功能	二功能	功能描述
系统操作	登录	用户输入账户登录
	退出	用户注销当前状态
	修改密码	用户修改自己的密码
	系统通知	其他用户或者系统发送消息给用户，用户可通过弹窗查看
	流程引擎	流程控制，确保用户在绩效核算之前完成所有必要步骤
	一次指引	图形方式指引用户完成绩效核算和操作
一次评价分配	一次评价计算	按照点数、规则、公式计算一次分配
	RVU 点数维护	维护 RBRVS 项目的基准点数和科室特殊点数
	核算模型管理	设置每个核算单元的公式、规则
	手工数据管理	绩效计算所需要的部分特殊数据，支持进行手工填写
	手工数据审核	对录入的手工数据进行审核
二次评价分配	科室分配项目	科室可自行设置绩效二次分配的名目
	科室绩效分配	科室按照设置的二次分配项目自行发放绩效
	科室分配审核	科主任对科室二次分配项目进行审核
	医院分配项目	医院层面直接发放到个人的绩效项目可在此设置
	医院计发分配	按照医院分配项目，由医院层面直接录入发放金额，并且计税
	医院计发审核	对医院发放项目及金额进行审核
成本管理	成本项目管理	设置成本科目字典
	成本数据管理	成本数据录入、导入、导出
	成本数据分析	成本数据校验和分析
KPI 管理	指标管理	KPI 指标模板的维护、指标分配到科室
	指标录入	打分科室为各个核算单元进行打分
	指标审核	对打分结果进行审核，并且计算出总分
	得分查询	科室查询各自 KPI 的目标值、考核制以及对应得分
	目标值管理	维护不同核算单元的指标的目标值
人事管理	员工信息管理	全院员工个人信息的维护，可设置其对应 HIS 工号等
	员工月查询	按月归档员工信息的查询，以及逐条信息的修改
	岗位字典	设置院内岗位字典
	职称字典	设置院内职称字典
	行政职务字典	设置院内行政职务字典
	护理能字典	设置院内护理能字典
组织架构管理	核算单元管理	核算单元的设置，及其关联 HIS 科室的对应关系
	发放单元管理	在核算单元上层设置发放单元，维护发放单元和核算单元的对 应关系
	科室管理	按照院内科室别设置，创建科室字典，并且创建科室和核算 单元的对应关系
	医疗组管理	设置全部医疗组，并建立医疗组和科室、核算单元的对应关系
数据汇总分析	表格数据分析	可对所有后台表格设置查询条件，并进行检索。支持数据导出
	数据采集情况	监控数据采集的执行情况
	表格数据维护	依照条件查询某些表格数据，并可直接对数据进行编辑和修改
	点数明细查询	科室查询各自奖金规则的收费明细项，并支持明细数据下载功 能
	后台明细透视图	可以通过条件组合，查询收费明细、点数的完整信息，或者求 和、平均、例数信息，功能类似于 Excel 的透视图。
	运营管理	数据分析的相关模块，可打开分析报表，或者执行各种系统 别的任务
权限控制	用户管理	维护用户信息
	权限管理	维护权限信息
	角色管理	维护角色信息
	菜单管理	维护菜单信息
	用户科室访问权限	设置用户可在不同模块访问不同核算单元

2.2 功能描述

（1）数据采集：为保证现有资源的合理利用，系统支持从现有医院信息系统和现有医院平台自动进行数据收集，采集范围可以包括 HIS 系统、LIS 系统、PACS 系统、电子病历系统、手术麻醉系统、成本核算系统、人事管理系统、排班考勤系统等。在院方的数据集成平台无法提供满足绩效所需数据和所需数据规模的情况下，可以采用面向数据库底层的数据采集方案。

（2）数据补录：保证绩效评价客观、公正，数据口径完整，数据来源丰富，应覆盖临床、管理的方方面面。就目前医院绩效精细化管理系统建设情况而言，部分必备的数据需要通过手工补录的方式，记录到绩效系统当中。《绩效管理系统》支持对此类数据的补录和扩展应用，而无需再做过多的定制化开发。

（3）数据上传：《绩效管理系统》各模块具备数据录入和上传两种方式，适应医院现有的数据处理习惯。为此，除常规的将数据输入到《绩效管理系统》外，还具备接收符合模板要求的 Excel 电子文档，以降低各科室在数据处理的学习成本。

（4）分配规则引擎：作为面向全院医生、护理、医技、管理不同职能领域的全面绩效管理系统，绩效的评价与分配的方法存在一定的差异性。为使一套系统满足不同的方案，而不必自定义新模块，绩效管理系统采用规则引擎进行绩效分配公式的定义。规则引擎支持用户随时修改规则、参数，且不需反复进行定制软件开发。

（5）点数规则引擎：绩效管理方案特点是以 RBRVS 的本地化方案为理论依据，计算各临床科室的工作量。点数规则引擎能将点数与规则结合，支持用户通过界面配置来完成项目点数的归属确认。通过多种条件的组合，实现较为复杂的逻辑。具有按照医生科室、病人科室、员工、职称、费别、项目、员工身份、节假日工作、门诊住院工作等条件进行规则制定的能力。

（6）规则复用：为简化操作配置流程，职能和内涵相似的科室已进行一致的处理。通过规则的快速复制或引用，能够尽快将项目落地，提高项目交付能力和后续维护质量。

（7）指标编辑器：关键业绩指标作为绩效考核与评价的重要维度之一，可扩展、可调整、可定义。指标结果的计算逻辑由公式编辑器来定义，公式编辑器支持按录入值进行梯度计算、按录入值完成率进行梯度计算、按区间进行计算得分等模式。指标支持不同的考核周期（月、季度、半年、年度），指标编辑器支持引入外部变量来作为指标的动态目标值。

（8）指标考核关系：为满足当前院内关键业绩指标评价模式，《绩效管理系统》支持科室之间一对一考核、一对多考核、多对一考核。

（9）指标考核模式：用户仅需要录入指标的原始值，由指标公式自行计算考核得分。每个指标的目标值支持固定目标、同期目标和浮动目标，支持按照不同考核周期调整浮动目标（月度、季度、半年、年度）。

（10）指标考核实现：为满足医院绩效精细化管理系统建设与发展，指标考核的方式包括自动采集汇总、自动引用上一周期、电脑端手工上报和数据导入等方式，多种方式相结合，以满足不同岗位的评分人员在不同环境下能够对关键业绩指标进行打分。

（11）人员属性管理：本模块支持全院医、护、技、行管、工勤等各岗位职工的人员属性维护，包括工号、姓名、在职状态、入职离职时间、个人职类、绩效发放职类、所属科室、职称、护理能、行政职务、岗位、是否计算个税，以及可扩展的身份属性定义。

（12）员工主索引：系统支持人力资源系统、HIS 系统等，在员工编码不同的情况下，仍然能够进行同一人员的匹配和关联，以确保绩效评价过程中员工身份的统一。

（13）人员系数管理：为满足基于年资的二次分配方案，针对不同职位、岗位、职称等能够设置相应系数，系数可应用于人员二次分配自动计算。

（14）人员归档管理：为保证每月绩效数据的稳定，人员信息可按月进行归档和封账，在重新测算历史绩效时候，不因人员变动而影响数据的合理性和真实性。

（15）成本管理：绩效所需成本项目，支持自动采集、手工录入和批量导入的方式。支持任意多层的成本项目。不同的成本项目在进入绩效分配运算时，支持不同的计提比例，通过计提比例的调整确保成本因素在绩效比例中占比合理。

（16）预提待摊：不同科室的成本项目因周期性波动，其数值变动较大。在系统中支持对个别月的成本进行预提待摊的处理，以消除波动性给科室带来的绩效巨大振幅，保证科室业务的正常运转。

（17）RBRVS 点数维护：全院收费项目通过本《绩效管理系统》和 RBRVS 的本土化点数结果进行一一对应，对应后的结果可在规则引擎中直接被应用而无需特殊处理。RBRVS 的本土化点数可由程序统一进行升，程序会主动发现未被赋点数的收费项目，并由升文件对未配点数的收费项目进行点数赋值。

（18）点数维护安全机制：通过《绩效管理系统》进行的任何一次点数修改，都能够通过系统回滚，确保点数维护过程中的数据安全和可追溯。

（19）基于 CPT-RBRVS 的个性化升：系统满足新增项目的 RBRVS 项目对应和升，不同临床分工的科室应可享有个性化的RBRVS 点数。对新技术新业务的点数，在个别科室可个性化调整，促使新业务新技术的良性开展。

（20）手术单项：结合历史数据梳理手术科室的基础手术工作量，对于超过基础手术工作量的部分进行单项奖励。对超过的比例、超额的奖励都可通过系统动态调节，无需进行代码修改。

（21）科室绩效发布流程：为灵活应对医院绩效管理部门奖金发放审核的流程管理要求，《绩效管理系统》以配置形式实现一次分配奖金的审核、封账、发布事件的流程组合，且可针对不同节点设置   不同权限。

（22）个人绩效上报：为支持科室自行评价考核科内人员的绩效并进行发放，《绩效管理系统》包括本模块，支持科室将发放结果以手工填报、Excel 上传等方式反馈到绩效管理部门。发放方式支持跨科室发放，允许核算单元负责人将部分绩效奖励给为本单元带来贡献的他科人员。

（23）绩效调剂：为支持部分大科室主任对其所管辖科室进行绩效的调节与再分配，《绩效管理系统》包含科室之间总绩效横向调拨的功能，以满足大科主任的管理要求。

（24）医、护、技、行管不同类别的二次分配方案：《绩效管理系统》除支持个人绩效上报外，还支持复杂的科室分配方式，通过系统采集到的个人数据（手术、管床、排班、门诊、特殊治疗项目、自定义项目等）结合科室手工核准上报的项目，从年资、工作量、奖惩三个角度，自动对个人绩效进行评价和发放。

（25）规则明细分析：通过系统能够精准定位到每一条收费项目所匹配的规则，以及规则核算主体，便于医院发现是否有工作量的分配被遗漏。

（26）绩效发放分析：对每月绩效进行科室、职能类别进行同比环比等数据分析，进行点数、收入、利润等的对比分析。

（27）权限控制：权限控制可精确到具体科室、具体按钮，确保权限控制有足够细的粒度。

（28）角色分组：用户可按照角色将权限进行打包，角色之间可进行权限叠加。

（29）日志分析：对用户的每一项操作都有详细的日志记录，每一次数据变化都可通过日志分析模块进行查询。

（30）安全别设置：系统支持以配置形式实现医院的密码复杂度要求。

第3章 人员配置

3.1 实施组织设置原则

我司为确保后期实施过程中能实现高效沟通、高效决策，实现实施过程中项目信息在团队内快速同步，同时确保项目高质量、高效实施，特为本项目制定了实施组织架构。我司组织架构设置原则如下：

1、明确的生产、监管分工。项目实施组由各模块研发小组、技术支撑小组、测试小组组成，团队由技术总监分管。团队主要职责是按照行业规范、数据规范、安全管理对系统进行设计、开发、测试。项目监管组由信息联系中心、采购组、质量控制组、安全生产等小组组成，团队由项目副经理分管，团队主要职责是负责项目变更、沟通、决策等工作的文档编写和支撑等工作，负责项目的采购、安全生产监管、质量控制等事项的监管。

2、明确岗位分工和职责。明确各岗位人员的工作界面和职责分工。

3、关键岗位优先选人。我司设置的组织架构中，对各岗位人员配置在项目管理和研发经验上均有较高要求。其中，信息联系中心成员要求具有较高的沟通、协调能力，拥有规范的沟通管理技巧。计划与控制成员要求精通项目计划制定、计划分析、绩效指标分析的能力，熟悉各项指标分析工具的运用，熟悉制定控制措施，具备高效管理项目各项指标的能力。以上人员均要求具备同类大型项目管理经验和相关资质。

4、恰当的设置实施小组。设置针对本项目的x佳管理幅度，实现组织内决策的高效和优质。

5、合理的权限分配。将部分权限下放给技术总监和项目副经理，实现程序化事项快速决策。非程序化事项由项目经理及管理团队共同决策。

6、设置信息联系中心。实现组织中横向、竖向的有效沟通。支撑管理团队对待决策事项的快速决策。实现组织内信息快速同步。在大型项目中，成员之间对经常变动的事件的沟通经常会形成多个版本的信息，因此设立专职联络小组是十分必要的。

7、程序化。对分工关系、小组设置、权限设定、沟通协调形成标准化、程序化的管理机制，实现组织管理的稳定性和高效性。

3.2 项目实施组织架构

 

3.3 项目组职责分工

组织	人员组成	职责分工
项目经理	由项目部总监组派遣出任	监督项目团队实施工作；协调公司资源对项目进行支持。主要参与的项目阶段是：项目全过程
项目副经理	由项目部副总监组派遣出任	配合项目经理对整个项目团队进行管理，推进项目实施
技术负责人	由具备丰富项目经验，熟悉客户日常业务、掌握相关软件技术的人员担任	根据项目要求组建项目团队； 根据项目情况、要求制定行之有效的项目计划； 领导项目组按计划开展项目运作，保证项目进度符合双方要求； 负责项目质量，保证项目质量符合客户要求； 协调项目实施过程中与客户的关系，保证项目顺利开展； 定期向项目领导小组汇报项目进度、项目情况，进行风险预测与评估，保证项目效果。 参与项目的全过程。
项目联络组	由客户方总部主管技术部门与主管业务部门的部门负责人共同组成	提供项目实施场地、项目用机等相关资源； 组建客户方总部的需求负责小组与技术负责小组，协助项目工作开展； 与项目经理共同制定计划，保证项目计划符合客户的要求与实际情况，并监督执行； 作为客户方总部的项目接口配合项目经理组织、安排需求调研、用户培训、系统试运行、系统推广等项目协调事宜，协助项目各项工作的顺利开展； 对项目总体需求负责，在相关需求出现冲突时，审核、协调并确定x终需求。 组织客户方总部对项目的x终成果进行验收。参与项目的全过程。
采购商务组	由专职采购人员组成	主持采购和商务的全面工作。 领导采购商务部门按部门的工作职能做好工作。 制定本部门的物资管理相关制度，使之规范化。 制定物资采购原则，并督导实施。 做好采购的预测工作，根据资金运作情况，材料堆放程度，合理进行预先采购。
计划控制组	由专职进度管理人员组成	控制整体项目进度情况
质量管控组	由专职质量管控人员组成	在质量控制组长的领导下，对项目各阶段进行跟进、监督，保证项目各阶段工作按CMM质量体系要求开展； 参与项目成果评审。 参与项目全过程。
需求调研经理	由具备丰富项目经验，熟悉客户日常业务的人员担任	与客户进行沟通交流，深入了解客户的实际需求。
详细设计组	由客户方总部相关业务部门熟悉业务流程、能对业务流程负责的人员组成	提供业务需求，并对需求分析小组提交的《系统需求说明书》进行审核，与项目组共同分析、确定系统需求； 检验系统功能是否满足需求。 主要参与的项目阶段是：需求调研、需求实现、系统测试、普通用户培训、系统试运行、项目/系统推广、项目验收。
研发小组	由相关技术水平高、具备开发经验的人员组成	根据需求进行系统设计，形成《系统总体设计文档》 根据需求进行代码编写、功能实现，形成《功能模块说明书》。 主要参与的项目阶段是：系统设计、需求实现、安装部署、系统试运行、项目/系统推广、项目验收。
实施小组	由客户服务中心的项目工程师组成	根据需求进行对系统原型进行服务端与客户端的安装部署、初始化、定制，包括表单定制、流程定制、协同功能定制等。 主要参与的项目阶段是：项目全过程。
软件测试组	由专职测试人员组成	在质量控制组长的领导下，对项目各阶段成果按照测试标准进行测试，提交测试报告； 监督测试结果的更新与改正。 确保产品的性能，在恶劣环境下的运行可靠性 主要参与的项目阶段是：需求实现、系统测试。
现场技术负责组	由客户方总部相关技术水平高的人员组成	承担系统的系统管理员； 在项目实施过程中，完成服务器、客户端的环境准备，解决系统运行所必需的网络、设备问题，保证系统能够正常运行； 参与项目需求调研、功能开发、用户培训、系统运行等全过程，了解系统功能，承担起系统的日常维护。 参与项目全过程。
培训小组	由熟悉客户日常业务、具有多年培训经验的培训讲师组成	编写各类《培训手册》，准备培训教材、培训练习、考核数据； 根据客户安排提供培训授课，保证培训效果； 辅导学员的日常使用，解决学员日常使用中出现的问题。 主要参与的项目阶段是：管理员培训、普通用户培训、系统试运行、项目/系统推广、项目验收。

 

第4章 实施计划

4.1 实施方案

 

其项目实施过程一般分为以下6个阶段：

1.需求分析

系统需求分析就是回答做什么的问题。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并x终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对项目的各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。

2.系统设计

软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元。模块，然后进行模块设计。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，常用方法还是结构化程序设计方法。

3.系统实现

软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的”源程序清单”。充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。

4.项目测试

软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例（测试数据和预期的输出结果组成了测试用例）。如何才能设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口，黑盒法。

5.系统部署

当设备和产品到位后，在实际安装地直接进行部署。包括网络设备和服务器的部署，系统软件的安装，然后进行应用软件产品的现场组织安装，项目负责人将确认设备型号和软件版本。如果需要，可以通过下载的方式使整个网络系统在软件版本上保持一致。

为了确保安装的顺利和按时，用户应对安装现场所有涉及的硬件和通讯线路等进行配合测试。所有结果文档将作为现场安装的参考技术资料，并由用户相关技术部门及项目小组签字。系统部署后给用户提供配置文档、管理员手册、常见问题答疑等文档材料。

6.系统试运行

系统部署完成后，准备系统试运行，测试系统功能完整性、业务流畅性、整体稳定性。

7.系统验收并投产上线

试运行结束后，系统正式上线，在正式上线运行一段时间没有明显错误、宕机等现象，到正式验收时，双方协商进行项目的x终验收。

8.系统维护

维护是旨在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。

在实际开发过程中，软件开发并不是从x步进行到x后一步，而是在任何阶段，在进入下一阶段前一般都有一步或几步的回溯。在测试过程中的问题可能要求修改设计，用户可能会提出一些需要来修改需求说明书等。

4.1.1 软件需求分析

由于项目与众多相关应用软件需要进行交互，因此需要先对这些项目进行分别梳理，充分做好需求调研工作，编写经项目单位认可并评审通过的《项目需求规格说明书》。

软件需求分析是按照项目定义的软件开发过程，根据系统分配给软件的需求，进行软件质量特性规格说明的过程。该过程包括进一步明确软件运行环境，明确对软件的功能、性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化，即完成对软件需求的分析与规格定义。

本元素在整个过程中的位置如下图所示：

 

4.1.2 系统设计阶段

进行人员和进度安排后，会由具体项目组成员进行详细需求调研和系统详细设计。我方承诺在编制正式的项目建设实施方案和详细设计时，我方应深入分析和充分考虑业主对本项目现在及未来发展的需求，设计出完整的优质方案。要开放各类数据显示的数据接口，便于系统功能的扩充和完善。所作的详细设计应完全满足用户的需求。

• 详细需求调研是根据项目进度计划，对用户的具体设计需求进行详细周密的调研工作，包括
• 详细环境参数的描述；
• 系统支持功能描述；
• 用户人员和工作流程描述等。
• 根据需求调研的情况，进行系统详细设计，主要包括：
• 应用结构设计；
• 数据结构设计；
• 功能开发技术环境选定；
• 功能模块划分；
• 功能实现设计；
• 接口设计等。

根据实际调研和设计的结果，制定出符合x终需求的详细设计方案，进行系统实施、个性化开发和试运行，x终提交验收。

4.1.3 系统实现阶段

编码阶段主要完成的工作是根据详细设计说明书编写程序源代码，包括必要的数据文件，并进行单元测试，单元测试的内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处理等方面。

本元素在整个过程中的位置如下图所示：

 

编码阶段在软件开发过程中的位置

• 代码开发和模 拟环境测试

分模块进行代码的开发工作，开发完成需要在与实际应用完全相同的环境下进行分模块、以及综合的测试，测试包括性能的测试、功能的测试、以及接口的测试。

• 具体开发工作及分工

项目负责人组织本项目组人员进行设计开发工作，不同的人员负责各自的设计开发，包括：

• 项目负责人负责总体把握和协调。
• 软件开发小组负责个性化的系统开发，设计页面、接口等，美工负责网页设计。
• 集成小组负责系统软件的部署、优化、安全。
• 技术支持和售后服务小组负责在系统实施完成后为用户提供长期的支持和服务，当用户系统出现问题时远程支持和解决以及上门服务。
• 软件测试小组负责分模块的性能测试、功能测试和接口测试。
• 培训小组负责为用户提供培训服务。
• 应用系统安装和参数配置

对已经完成的开发模块以及成熟的相关的应用产品进行现场组织安装，工程师将确认软件版本。如果需要，可以通过下载的方式使整个网络系统在软件版本上保持一致。

我公司的现场工程师将对设备系统软件的参数进行配置。这些参数包括：故障诊断参数、接口参数、系统性能参数等等。

为了确保安装的顺利和按时，用户应对安装现场所有涉及的硬件和通讯线路等进行配合测试，所有测试结果将作为现场安装的参考技术资料，并由用户相关技术部门及项目小组签字。

编码实现阶段的主要活动是编写源程序，以及围绕编码工作开展的其它活动：测试、编写用户操作手册和管理员手册。

4.1.4 系统测试

系统部署和数据整理和调整完成后，提交测试计划（包括测试程序、测试内容和检验标准、试验时间安排等），供用户确认。

测试在用户现场进行，依据测试计划逐项测试，对所有检验验收测试的结果、步骤、原始数据等作妥善记录，测试报告由双方填写并签字。

如果测试出现问题，将立刻进行诊断，弥补缺陷，然后再进行测试，直至全部测试通过为止。

4.1.5 系统部署

当设备和产品到位后，在实际安装地直接进行部署。包括网络设备和服务器的部署，系统软件的安装，然后进行应用软件产品的现场组织安装，项目负责人将确认设备型号和软件版本。如果需要，可以通过下载的方式使整个网络系统在软件版本上保持一致。

为了确保安装的顺利和按时，用户应对安装现场所有涉及的硬件和通讯线路等进行配合测试。所有结果文档将作为现场安装的参考技术资料，并由用户相关技术部门及项目小组签字。系统部署后给用户提供配置文档、管理员手册、常见问题答疑等文档材料。

4.1.6 系统试运行

在整体项目完成后，为了保障平台上线后的稳定、可靠运行，全面支撑各类业务的有序进行，需要通过既定时间段的试运行，全面考察项目建设成果。并通过试运行发现项目存在的问题，从而进一步完善项目建设内容，确保项目顺利通过竣工验收并平稳地移交给运行管理单位。通过实际运行中系统功能与性能的全面考核，来检验系统在长期运行中的整体稳定性和可靠性。

试运行工作需要达到以下考核目标：

1，系统功能、性能与稳定性考核

（1）系统功能及性能的实际应用考核;

（2）系统应用软件、软件支撑平台的长期稳定性和可靠性;

（3）系统主要硬件设备、辅助设备的长期稳定性和可靠性;

（4）数据通信系统的长期稳定性和可靠性;

（5）检测数据的长期准确性和完整性;

（6）系统长期安全性能;

（7）网络连接的可靠性。

4.1.7 系统验收上线

试运行结束后，系统正式上线，在正式上线运行一段时间没有明显错误、宕机等现象，到正式验收时，双方协商进行项目的x终验收。

首先由我公司提交验收方案，组织专门的验收小组对系统功能的完整性、实用性、可靠性、保密性进行验收。验收标准以业务需求说明书、工程实施技术方案及验收大纲的系统设计、质量和安全标准为准。

验收小组包括双方人员，验收工作应按双方认可的验收规程正式履行验收手续。

验收内容包括文档验收、设备验收、程序验收、演示、验收测试与测试结果评审等几项工作。系统验收合格后，须经验收工作小组成员签字确认。

项目竣工成果文档资料（电子文档及纸质文档）的提交包括但不限于以下内容，文档资料要装订成册，具体份数按业主单位要求。

a、应用软件的源程序及可执行代码。源程序要求具有良好的编程风格，可执行代码以二进制文件或可安装文件的形式提供；

b、数据库的设计以及数据实体模型、相互关系的描述；

c、系统的体系架构及描述；

d、提供的其它技术手册，包括：

e、项目范围确认书

f、需求规格说明书（含软件功能需求与数据要求）；

g、系统详细设计方案及系统测试方案设计；

h、数据库设计方案；

i、软件安装维护手册；

j、软件使用操作手册；

k、软件功能技术手册；

l、软件体系架构手册；

m、软件系统的测试分析报告。

n、培训资料（含系统演示操作视频）

实施过程文档要求如下：

a、项目实施前：项目整体管理计划(含项目章程)、范围管理计划（WBS）、进度管理计划、质量管理计划、成本管理计划、风险管理计划、沟通管理计划、干系人管理计划、人力资源管理计划、需求分析报告、设计方案、详细设计说明书等；

b、项目实施期间：项目实施工作单、故障诊断及排除记录、项目管理实施过程中衍生的其它相关资料，包括项目实施变更申请单、进度表、周报等报告，会议纪要等过程文档，以及项目联系单、申请单等报告；

c、项目实施后：系统试运行和自测报告、故障诊断与排除手册、工作总结报告等；

d、培训期间：培训计划、面向用户的宣传资料、用户使用手册、管理员使用手册、电子操作视频；

e、其他需要提交的材料。

4.2 售后与培训计划

1.1 培训内容及大纲

本项目的培训包括两方面的内容：

1）项目相关的专项培训

• 系统集成方案培训
  • 系统概述及功能框架
  • 系统介绍
  • 系统总体方案介绍
• 用户使用培训
  • 系统使用培训
• 系统安装部署培训
  • 系统安装
  • 系统初始化
• 系统管理与维护培训
  • 系统日常维护
  • 常见问题处理

1.1.1 总体方案培训

课程名称	课程编号	课时	培训对象
总体方案培训	ZS-001	4课时	1、运行、管理、销售等相关部分领导及业务人员； 2、系统管理员、运行维护人员等技术人员。
课程描述：对系统的建设目标、建设内容、技术方案等内容提供培训和介绍。
师资： （1）我司项目经理担任讲师。 （2）我司培训中心安排助教。 （3）提供配套的电子课件。
目的：培训通过对系统的项目目的、设计理念、设计思路等方面有宏观认识，对后续需求调研、项目实施打下基础

1.1.2 技术能力培训

课程名称	课程编号	课时	培训对象
系统技术能力培训	ZS-001	3课时	1、系统管理人员； 2、系统安装部署、运行维护与技术支持售后服务人员。
课程描述：对系统涉及到的基础技术理论的培训。
师资： （1）我司项目技术负责人担任讲师。 （2）我司培训中心安排助教。 （3）提供配套的电子课件。
目的：通过对系统技术的概要介绍，建立起对系统技术的认识

1.1.3 用户使用培训

用户使用培训为用户提供系统功能的培训，由于本系统涉及到的业务范围较广，人员较多，因此在用户使用培训中，我们将采用集中培训+一对一培训相结合的方式，首先由用户组织进行2-3批的集中培训，之后再安排培训人员在用户指定地点进行集中培训，对于关键用户和相关领导采用一对一培训的方式：

课程名称	课程编号	课时	培训对象
平台使用培训	YY-001	1天	各层使用人员；
课程描述：对平台功能进行讲解，主要功能框架。
师资： （1）我司项目经理和设计人员担任讲师。 （2）我司培训中心安排助教。 （3）提供配套的电子课件。 （4）提供《用户操作手册》
目的：使用户灵活的掌握平台的用途及使用操作。

1.1.4 安装部署培训

课程名称	课程编号	课时	培训对象
系统安装部署培训	BS-001	3课时	1、系统管理人员； 2、系统安装部署、运行维护与技术支持售后服务人员。
课程描述：对应用系统的安装部署与初始化环境设置进行的技术培训。
培训地点：用户统一安排
培训形式：全省集中培训
师资： （1）我司项目组技术人员担任讲师。 （2）我司培训中心安排助教。 （3）提供《系统安装部署手册》。 （4）提供配套的电子课件。
目的：使用户了解应用系统的安装部署及初始化环境设置

1.1.5 管理与维护培训

课程名称	课程编号	课时	培训对象
系统管理与维护培训	BS-002	3课时	1、系统管理人员； 2、系统安装部署、运行维护与技术支持售后服务人员。
课程描述：对应用系统管理和运行维护进行技术培训。
师资： （1）我司项目组技术人员担任讲师。 （2）我司培训中心安排助教。 （3）提供《应用系统管理与运行维护手册》。 （4）提供配套的电子课件。
目的：使用户了解系统管理的相关内容与操作，并灵活掌握运行维护的相关操作

4.2.0.1 培训质量保障

从培训组织保障、培训师资保障、培训教材保障以及现场实践保障等多方面着手，组织开展面向业主的培训工作。培训开始前将提供一份培训的详细计划，包括培训日期、授课方式、教材及教员职称与经历，并报业主批准。培训采取课堂讲解和操作训练相结合的方法。

 

 

4.2.1 售后服务内容

根据系统发展的实际需要，我方将建立完善的运维管理服务机制，来确保项目安全稳定地运行。

客户负责指导整个运维工作的开展、审核相关运维护制度，审核各项重大变更操作，对我方运维工作进行监督和考核，我方将依据ITIL和ISO20000，建立项目的运维机制，负责日常的运维工作。

该项目运维服务中心内全天候（7×24小时）运行。在热线电话发生故障情况下，提供其他备份方式的方便和迅速的联系方式。

1.1.6 系统售后服务服务

软件维护活动类型总起来大概有四种：纠错性维护（校正性维护）、适应性维护、完善性维护或增强、预防性维护或再工程。除此四类维护活动外，还有一些其它类型的维护活动，如：支援性维护（如用户的培训等）。

针对以上几种类型的维护，可以采取一些维护策略，以控制维护成本。

（1）改正性维护

改正性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随时进行：而有的错误非常重要，甚至影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。

（2）适应性维护

适应性维护是指使用软件适应信息技术变化和管理需求变化而进行的修改。由于计算机系统价格的不断下降，各类系统软件屡出不穷，人们常常为改善系统系统环境和运行环境而产生系统更新换代的需求；企业的外部市场环境和管理需求的不断变化也使得各管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。

（3）完善性维护

完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，还包括对处理效率和编写程序的改进，也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外．还要注意将相关的文档资料加入到前面相应的文档中去。

（4）预防性维护

预防性维护为了改进应用软件的可靠性和可维护性，为了适应未来的软系统环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。例如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。

1.1.7 更新升优化服务

我方将利用自身的整体技术优势承诺在本项目工程的售后技术支持和服务上为提供专职的技术砖家，给予全程、全网、全市范围的高质量、快速响应的技术支持和服务保障。

（1）文档更新服务

我公司将建立完备的资料库，并配备专门档案管理员管理这些资料，这些资料将分阶段作为成果提交给业主方。一旦资料进行了版本更新，我公司保证3天内向业主方提供x新版本的资料。

（2）升服务

我公司根据原厂商发布的系统软件版本/补丁升程序，并结合客户的需求和实际情况，为客户提供系统软件版本/补丁测试，实施现场软件版本/补丁的升服务以及系统微码固件的升。

我公司提供系统内系统、软件在维护期内的免费升服务。当系统内系统系统内嵌软件、应用软件、操作系统升时，我公司将无偿对系统进行升，并提供帮助文件（提供的软件中含相应的联机帮助文件）。

1）升服务。我公司免费提供系统内嵌软件、产品操作系统、第三方招标软件和应用软件的升服务。

2）系统优化。我公司根据运行情况定期免费向使用单位提供系统优化、使用优化和管理优化建议，确保系统以x优状态运行。

第5章 工期及质量管理

5.1 工期

在软件实施过程中，绩效管理小组要定期收集完成情况的各类证明数据，与已制定的进度计划进行比较，如果实施落后于进度计划，要召集相关单位，采取必要的纠正措施，并适当调整计划，以保证的正常进行，本项目工期预计6个月

人员	日历（日）   项目阶段	1-5	6-20	21-40	41-90	91-100	101-179	179-180
业务分析组	需求调研
	概要设计
	详细设计
应用开发组	程序编码
软件测试组	单元/模块测试
项目实施组	系统集成
	项目部署
软件测试组	联调测试
验收工作小组	竣工验收

5.1.1 进度控制目标

我公司对的工期目标如下：在实施期间按原定计划开展实实施作，由管理小组对实施期间各阶段的进度进行监管和控制，整体在指定时间内竣工并通过验收。为此，我司将从需求调研、研发进度计划管理、进度控制管理三个方面重点加强管理，保障各阶段工期提前完成，不影响总体的进度。

5.1.2 实施进度计划管理

实施进度计划的控制是根据计划文件、进度、控制图表等，利用统计分析手段、调查研究等方法，来获得与进度计划完成情况有关的各种因素，制定相应的措施和对策。

工作细分结构

我公司的项目管理，软件划分为若干易于管理的分部的方法，从而达到预期的目标。工作细分结构是我公司项目管理的基础，无论是进度控制或投资控制都根据工作细分结构。结构中的每一项任务都有明确的工作范围、执行期及完成任务并提供具体的输出结果所需的资源。完成这项工作所需的资源和进度安排，由项目经理及工地代表共同确定。届时，每一项任务都将分配给各子项目的实施队长。在成本和进度安排限定范围内，实施队长将全权负责并完成分配的任务。

进度计划管理内容

本系统实施涉及相关部门的协调配合。由于这类的复杂性，其进度计划的管理和控制则显得尤为重要。进度安排要求做到非常详细，因为每项活动都关系着项目能否按期顺利完成。

进度计划内容应涵盖如下内容：

需求调研计划

程序开发计划

系统测试计划

系统调试计划

系统验收计划

系统试运行计划

系统文档管理计划

实施进度计划编制

项目进度计划编制时，应估计每项任务活动的工期，确定整个项目的预计开始时间和要求完工时间，在项目的预计开始时间的基础上计算每项活动必须开始和完成的x迟时间，确定每项活动能够开始（或完工）与必须开始（或完工）时间之间的正负时差，确定关键（x长）活动路径。

项目进度计划编制，基本上是在业主单位的计划基础上对相关区域的各子系统的布线、端接和设备安装等工序的时间要求进行规定。

根据业主对进度的要求，做出总体进度计划安排，以保证高质高效地完成。根据实际量，我公司对工期进行了测算并制定了实施进度表。

在实施中，经常检查实施实际进度情况，并将其与计划进度相比较，若出现偏差，分析原因和对工期的影响程度，找出必要的调整措施，修改原计划。不断地如此循环，确保如期完成。

5.1.3 WBS工期分解过程

目的

WBS（工作任务分解结构）的目的是将整个项目分解成可管理的、相互关联的、模块化的构件或活动，即工作任务或工作包，用于估计项目的范围。分解的每项工作任务可以被分配、执行和跟踪。

WBS为项目分配工作量、进度和职责提供了一个参考和组织机制，是项目计划的“基础构架”，是项目估计、计划、跟踪和监控的主要依据。

术语

WBS：Work Breakdown Structure，工作任务分解结构

角色职责

项目经理负责软件项目的WBS活动。根据采用的方法和项目具体情况，由项目经理和项目经理指派的有经验的程序员、软件工程师、软件估计人员等负责实施项目的WBS活动。x终的确认必须由项目经理进行。

入口准则

• 方案论证报告被批准；
• 项目任务书已被批准；
• 项目合同等被批准。

输入

• 经批准的方案论证报告；
• 经批准的项目任务书；
• 经确认的客户的需要/需求；
• 经批准的项目合同等。

活动

WBS采用自顶向下分解的方法，将项目分解成层次化的项目活动元素（工作任务）。

5.1.3.1 WBS中的项目活动元素

WBS中的元素可以分解为5类：

• 产品分解元素—是对可交付产品物理结构的细分，是x通用的WBS。所有这类项目都有一个有形的输出产品：软件，建筑物，水坝，飞机，用户手册等。
• 项目管理元素—这是一个项目的管理责任和管理活动的分解。如报告、项目审查、里程碑评审等。
• 服务分解元素—服务项目没有有形的、结构性的可交付成果。他的输出是一个为别人做的工作实体：会议，宴会，婚礼，假期旅行等。工作分解是关于相关工作领域的一个逻辑集合。
• 结果分解元素—其输出是一个过程结果，一个产品或者一个结论，如癌症研究，新药物开发，文化变革等。
• 横向关联元素—横跨产品所有内容的一种分解，如建筑设计、安装、产品集成或系统测试。这些元素通常是技术性的或支持性的。
• 软件项目的WBS一般按产品分解元素或项目管理元素进行分解。

5.1.3.2 WBS的分解层次

将软件项目的WBS按以下5层次进行分解：

• 项目
• 可交付物，如软件，收集和培训课程
• 构件，是产生可交付物需要的关键工作项，如产品系统软件需要的模块和测试
• 工作包，产品构件需要的主要工作项或相关任务集
• 任务，通常由单个人完成

5.1.3.3 WSB分解方式

 

 

 

5.1.3.4 WBS的分解原则

WSB的分解应符合以下几个原则：

• 粒度适当，即每个任务x好分解到能在1周内由1个人完成。
• 大小可比，即任务大小可比，不超过一个数量，x多不超过10倍，因为跟踪进度时是按0/1法跟踪任务完成情况的。
• 在进行WBS分解时，下列活动容易遗漏，需要引起注意，务必使WBS分解包含以下内容：
• 制定计划的活动
• 计划变更的活动
• 所有的评审的活动（项目主计划，PPQAP，MAP，CMS，SAMP，需求，设计，测试用例。。。。）
• 跟踪矩阵建立的活动
• 跟踪矩阵的维护活动
• 周例会（周期性的活动）
• 里程碑评审
• 实施PPQA的活动
• 度量计划的制作
• 度量数据的收集与分析
• 采购相关的活动
• 集成的活动
• 交付的活动或者分期交付的活动
• 回归测试的活动
• 技术方案选择与评审的活动
• 过程裁剪的活动

出口准则

• 得出WBS结果。
• WBS经项目经理确认。

输出

WBS文档。

度量和分析

项目经理统计进行WBS分解的工作量。

5.2 质量管理

基于本项目建设项目的背景和特点，在本项目的实施过程中，重点考虑快速进行系统部署，在原型基础上根据业务需求，对系统进行调研和开发。以需求为导向，做好项目的整体规划，快速高效搭建符合实际业务需求的系统，促进资源的深度共享和利用；保证平台系统的健壮性、可靠性、高效性等多方面的企业表现。我方将建立标准化工作程序、完善人员管理措施、完善问题管理措施、进行全面的系统测试等手段，保障项目质量达到优秀等。

在人员配置方面我方将参照CMMI5和ISO质量管理要求，配备专职的质量管理人员，全过程跟踪和管理项目质量，提交完成的项目文档，确保进度计划的执行和质量控制。

在项目的实际实施过程中，不可避免的会遇到需求调整或修改的情况，我方有能力在适当的时机帮助客户及时管理和控制这些变更，并提出相应的建议和措施，确保项目的顺利实施。

在实施项目前首先成立合理的组织机构，建立健全保障项目顺利实施的各项管理制度和质量保证体系，我们安排足够的有x行业项目经验的高素质人才参加本项目的建设。在本项目的执行过程中，项目经理专职于本项目，主要技术人员全程参与到本项目中，并且保证整个项目团队的人员相对稳定。不会有项目参与人员不固定，随时变换的现象出现。

项目管理集中体现在3P上，即人员(People)、问题（Problem）、过程（Process）上。我们质量保证管理体系（ISO9001及CMMI5）着重体现在这三方面。我们将从这三方面保证项目进度、质量管理。

5.2.1 建立标准化工作程序

项目启动时，项目技术协调小组室应根据项目范围、项目要求，首先组织人力编制项目程序、工作标准及相应工作手册，形成工作方法体系，实现项目工作的程序化、标准化，并对项目人员进行培训，使他们了解和遵守项目程序和要求。

5.2.2 完善的人员管理措施

软件工程是人的智力密集、创造性劳动。对于人的管理非常重要。针对该项目我方建立x优的组织体系。安排对企业管理有丰富经验工程师参加系统调研。项目管理中采用《日程表制度》，工作分解到人，任务划分到4小时，加强考核。建立良好的激励措施。加强人员培训，加强团队精神建设。

项目周报制度，每周将项目进展情况向项目监控部、项目经理、客户方项目经理汇报。

5.2.3 完善的问题管理措施

1）需求管理

由于软件需求并不是固定的，做好需求的变更控制，变更记录，问题分解并落实到人。

跟踪需求控制。

2）配置管理

对于开发过程中文档，设定配置基准，采用版本配置管理工具进行管理。

3）协调与沟通问题

项目涉及单位多、成员多，项目难以协调。不确定性是经常存在的，会引起项目组计划、决策的改变，互操作性成为项目实施的关键特性。为了保证项目的实施，必须建立有效的协调、沟通方法。沟通方法有：

• 正式的、非个人的方法

包括需求报告评审、需求更改、软件工程文档及交付物、技术备忘录、进度计划、错误跟踪报告等。此类必须有正式的记录（正式文档或FAX）。浙移集成与建设方之间的沟通较多使用此方法。

• 正式的、个人间的规程

集中体现在开发过程中产品的质量保证活动中，包括设计、代码检查。

• 非正式、个人间的规程

包括信息传播、问题结果、需求和开发人员配置小组会议，技术交流。

• 个人间的通讯

通过电子邮件、内部网进行沟通，可以与项目组内成员、也可以与项目组外成员讨论。

5.2.4 实行阶段性成果提交与变更控制

项目具有生命周期，这就为我们划分项目阶段提供了依据。一个大项目可分成若干阶段，每个阶段有自已的任务和成果。这样一方面便于管理和控制项目进度，另一方面可以增强项目人员和用户的信心。

在每个阶段末要提交部分成果，作为下一阶段开发的基础。成果提交之后不是不能修改，而是其修改要经过一定的审批程序，并且涉及到项目计划的调整。

5.2.5 实行里程碑式的审查与版本控制

里程碑式审查就是在项目生命周期每个阶段结束之前，都正式使用结束标准对该阶段提交的成果进行严格技术审查，如果发现问题，应及时在阶段内解决。

版本控制是保证项目部顺利工作的重要手段。版本控制的含义是通过给文档和程序文件编上版本号，记录每次的修改信息，使项目部的所有成员都了解文档和程序的修改过程。

5.2.6 全面测试

要采用适当的手段，对系统调查、系统分析、系统设计、实现和文档进行全面测试。

测试是确保本系统质量的重要手段，不经过认真测试的系统是不能被用于生产的。虽然，对各阶段的文档的审核也可认为是测试，但本项目所指的测试是指对应用软件的测试。做好测试是测试组的责任，测试组是与开发组相互独立的两组，且需要相当的技术和经验，对业务的理解要十分透彻。为保证测试的效率和质量需要主意以下几点：

建立高效合理的测试流程，包括：

建立尽量模拟真实环境的业务数据模型（即运行业务的初始环境）；

对测试案例的设计要有深度和广度；

特别在系统测试和验收测试阶段，安排好项目组的全体人员的任务和责任；

做好测试阶段文档和源程序的版本控制；

做好测试中发现的BUGS的记录及存档工作；

对发现的任何BUGS都要做好原因分析并记录归档；

做好回归测试；

防止对程序的修改而引起的其他问题。

软件测试是一个过程，涉及到软件生命周期的各个阶段。下图描述了软件测试过程模型：

 

测试过程是与开发过程并行的，软件测试的实施过程是与改程既是交错的、同时又是并行进行的。在集成测试阶段中，测试一般应当由独立的软件测试人员来实施。这种方法一方面可以有效地压缩测试的总周期，但更重要的是可以避免开发者自身的思维局限，更加客观全面地进行有效的测试。

5.2.7 系统实施过程的质量保证活动说明

在实施过程中将发生的重大质量保证活动或由此将产生的质量记录和产品，项目管理与开发阶段划分密切相关，因此主要按照项目实施的具体阶段划分说明。

1. 需求分析阶段

分五阶段需求调研、采用原型法、OOA方法，设定3个里程碑进行控制，加强中间结果评审，保证需求的质量和进度。

首先需要经双方协调，形成《需求调研计划》及《需求调研大纲》，确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容，经双方同意后按此计划开始调研。调研正式开始前项目开发组应检查所有必要的准备工作已经圆满完成。

项目开发组根据调研中系统实际技术需求和各个子系统的业务需求，编写并向工程领导小组提交符合CMMLEVEL5规范要求的《系统需求分析报告》，并由项目组评审，不合格的部分进一步完善调研；评审通过后由双方共同签署评审意见，并正式生效。

对于软件生产过程而言，需求阶段是整个过程中x重要的阶段，需求分析成果的好坏将直接导致项目的成功与否，因此合作双方在此阶段多投入是值得的。而且一旦评审通过并生效，则需求报告将成为系统的设计、开发、测试、实施试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其它因素的改变而变更，如需进行此种变更，需经双方项目负责人协商确定。

2. 总体设计阶段

设计过程中采用原型法，OOA/D方法，CASE工具（RationalRose、PowerDesigner等），设计/开发规范约束设计开发过程，测试负责人对源码检查。

项目开发组通过对系统的功能、运行和性能要求加以分析，产生一个高层次的系统结构、软件结构、接口和数据格式的设计，并向工程领导小组提交《系统设计报告》（其中包括数据库设计），组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划，评审通过后由双方共同签署评审意见，并正式生效，作为后续软件开发和测试的基础。

该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定，并需向工程领导小组汇报。

3. 详细设计阶段

项目开发组在《系统设计报告》的基础上，对功能和性能要求进一步加以分析和细化并且把软件的详细设计文档化，向工程领导小组提交《系统详细设计报告》，并由项目组组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划，评审通过后由双方共同签署评审意见，并正式生效，作为后续软件开发和测试的基础。

该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定，并需向工程领导小组汇报。

对于项目阶段点、里程碑进行评审，评审分为项目组内部评审，项目组评审、公司评审，客户评审。

软件质量保证过程包括对软件过程质量控制和软件产品质量控制。我公司在本系统项目组织中，由质量控制组负责质量控制和管理，采用软件度量过程采集信息对软件过程和软件产品的质量进行管理。

对软件过程质量的控制通过量化并提取软件过程信息实现对软件过程的目标管理，量化的主要内容包括：产品质量、项目进度和资源占用。软件过程控制一般采用软件开发过程的节点控制的方法。

软件开发过程的节点控制是提高软件开发的计划性和成功经验的可重复应用的重要支持手段。我公司在开发本系统的过程中，将充分利用该方法，确保本系统的高质、准时完成。在本系统的开发过程中，把涉及软件开发、应用的人员分为甲方、乙方，甲方代表各种层次的软件系统的用户，乙方代表软件开发商中各组织、各层次人员。软件系统的x终成功基于甲乙双方对软件开发过程的共同控制与管理，甲方侧重“需求”与“监督”职能，乙方侧重“供求”与“控制”职能。甲乙双方实现职能的基础是软件开发过程的可视性，即从甲乙双方角度得到软件开发过程的可见性。如下图所示：

 

图（a）表示一个对甲乙双方可见性差的过程，甲方给出需求后，经过乙方的开发过程得到的是x终结果，甲方对软件开发过程没法参与。乙方中只有具体的开发人员了解局部的软件过程，高层管理人员没法得到开发过程中具体的过程状态信息，不能根据过程状态做出决策。

图（b）表示一个对甲乙双方可见性较好的软件过程，在软件开发过程的特定阶段设置阶段控制点（也称为里程碑），甲乙双方依据阶段成果，从各自的角度提出过程改善与修改意见，控制软件系统生产的质量、开发过程的效率及项目资源消费。

4. 系统开发阶段

根据前面的设计结果，由双方的现场实施负责人、技术负责人讨论确定详细的开发计划，并向工程领导小组提交《项目开发计划》；工程领导小组对《项目开发计划》进行审查，由双方签字后正式生效，并将作为软件开发阶段的项目管理和监控依据，项目开发小组要严格据此计划控制项目进度，按时向工程领导小组汇报工作进展。

为了使用户能够及时获知项目的进展情况，开发小组需要每周向用户相关领导提交《项目客户周报》，用户项目组可以随时对项目的工作情况进行检查。

5. 系统实施和试运行阶段

首先需要经双方交流协调，形成《项目实施计划》，确定现场实施的准备工作、人员和日程安排、培训计划、阶段目标等内容，经双方负责人签字后生效，按此计划开始现场实施。正式开始现场实施前项目开发组应检查所有必要的准备工作是否已经完成。

现场工作首先要进行软件在服务器端的安装和调试，包括数据库中各类对象的生成，初始化数据，原有系统的重要数据的转换导入，前后台软件的安装，配置参数调整等工作；完成后需向系统维护人员提交《数据库安装目录》，《软件安装方法》文件，并协助用户进行软件安装。

软件安装完成并确认可在系统正常运行后，开始相关业务人员的培训；在培训开始之前需要由双方协商形成《培训计划》，明确培训环境、条件及方式，参加人员，课程课时等详细内容，由双方现场实施负责人签字后生效，并分别开始着手准备，在既定时间内完成。

培训过程中由工程师提供《培训考勤记录》，培训应该脱产、集中、封闭进行，并要求所有参加人每日必须两次考勤；培训完成后由双方共同进行《培训总结》，针对培训效果确定是否达到目标，是否再增加培训课程；对以上内容用户项目组须进行必要的考核和奖惩，培训工程师有权对参加培训人员进行客观评价。

培训顺利完成后将开始软件在试点部门试用，将向用户提交编译后的前后台软件，《软件使用操作手册》，《软件功能清单》，这两种文档将详细描述软件的使用过程，软件所包含的全部系统功能模块。

软件试用期内用户的主要工作是根据《软件功能清单》所列的系统功能模块，检查公司所提交的软件是否满足《系统需求分析报告》、《系统设计报告》的规定，列出未完成及含有较严重、明显错误的模块清单形成《软件问题及修改记录》并提交给公司继续完善；此段时间可以对软件的细节性问题进行测试、验证，但主要精力还是应放在模块功能的检查上，如果所有模块都已开发并可以进入试运行，其设计方法、技术可行性也都能够满足x终软件的需要，则用户各相关业务负责人、现场实施负责人需要签署各子系统的《软件交付书》，表明软件已在现场安装、调试、培训完成，基本可以进入软件试运行；此后在软件功能模块一上不应再发生大的变化，如需要修改功能模块设计，则需由双方项目负责人协商解决。

试运行期内用户负责组织针对《软件功能清单》所列的系统功能模块进行现场的系统测试，包括新旧两套系统并行工作一段时间进行验证，使每个功能模块都得到基本确认；对于其中发现的问题和软件的细节性修改意见，需以《软件问题及修改记录》的书面形式提交给公司；公司修改完成后立即提交到现场，用户负责组织立即对软件进行确认回归测试，如验证问题已修改需要在《软件问题及修改记录》中予以说明。通过试运行及修改后证明已经基本完成的模块，用户应组织相关的业务负责人在《软件功能清单》中逐项确认。

6. 项目验收阶段

在试运行期内系统存在一定的细节性问题是工程项目不可避免的问题，特别是随着用户应用的逐渐深入，此类需求会逐提出，此类问题不属于系统的致命性错误；因此当试运行期内所发现的真正的“问题和错误”收敛到一定数目以下时，各业务子系统经过一段时间的并行工作新系统已基本可靠，就可以切换到正式运行阶段，开始正式运行。

正式运行后，由用户提出验收要求，双方共同制定《项目验收计划》，组成项目验收小组，共同进行项目验收。此时公司将向用户提交验收的各类文档，包括对系统开发过程进行总结的《项目总结》，《项目技术报告》，x终的完整的《数据库字典》等。

验收工作将由用户组织的砖家组对系统进行全面的验收和鉴定，并出具项目验收小组领导签字的《项目验收报告》，并签署验收意见，公司在此过程中将全程参与，在现场进行验收前的维护工作。

7. 系统正式运行及维护阶段

公司承诺对系统软件提供服务保证期，在保证期内提供免费的软件升和维护服务；在保证期外，公司继续为系统的维护提供技术支持，对于软件升提供优惠服务。

维护期的具体工作方式请见售后服务承诺部分，所有维护工作，包括软件出现问题修改、细节性功能的增强，用户都要以《软件问题及修改记录》的书面形式提交给公司，修改完成后用户应组织相关的业务负责人进行确认，并在《软件功能清单》中说明；如遇紧急情况可事后补齐。

8. 各阶段辅助文档

《现场工作日程安排计划》，在实施中的各阶段，对于所发生的需要在现场进行较长时间工作的情况，如果在《需求调研计划》、《项目开发计划》、《项目实施计划》、《培训计划》等工作计划中未包含，则需要在工作开始前双方共同制订好《现场工作日程安排计划》，并严格据此执行，需要双方现场实施负责人签字生效。

《现场工作周报》，在现场实施工作中，为了把阶段性的工作任务具体落实完成，需要合作双方每周一之前由公司实施工程师与用户组共同制定本周的工作计划，给出每个工作日上、下午的工作内容，以及双方的准备工作。计划制定完成后用户项目组向所有相关部门和领导发布，开始执行；实施中双方互相监督按照原计划开展工作；周五时双方负责人共同对本周计划执行情况进行总结，对原计划填写工作总结，详细描述各项计划的完成情况，未完成的部分应写明未完成原因和责任归属，必要时双方协商一起进行加班处理，力争按时完成；对于不能按时完成的必须调整到下周计划中进行。

《用户项目报告》，对于实施中各阶段较长时间不在用户现场进行的，或项目处于用户试运行、维护期的情况，为了使用户能够及时获知项目的进展情况和公司开发小组的工作情况，公司将在开发阶段每周向用户相关领导提交此报告，维护期内每月至少提交一次。

《阶段评估报告》，实施中当某一阶段性目标实现后，公司将对该阶段双方联合开发组的工作情况进行总结，编写该报告并向工程领导小组提交，及时总结经验教训，为下阶段工作打好基础。

实施过程提交文件汇总

以下是对上面的实施过程中将产生的文件汇总说明：

 

阶段	名称	作用	评审别	变更控制
需求调研	《需求调研计划》 《需求调研大纲》	确定需求调研的准备工作、内容、方法方式及人员和日程安排	双方现场实施负责人	双方现场实施负责人
	《系统需求分析报告》	明确用户业务需求	双方项目负责人	双方项目负责人
设计	《系统设计报告》（其中包括数据库设计）	描述整个系统软件的模块设计，详细设计，数据库设计，供开发编码使用	双方项目负责人	双方现场实施负责人
	《系统详细设计报告》
软件开发	《项目开发计划》	软件开发的日程进度，分工，检查点设置，提交成果等计划	双方现场实施负责人	双方项目负责人
软件测试	《测试计划》 《测试问题卡》 《测试总结报告》	符合ISO9001质量保证体系规定的功能测试、同行间测试文档
软件现场实施	《项目实施计划》	确定现场实施准备工作、人员和日程安排、培训计划、阶段目标等	双方现场实施负责人	双方项目负责人
系统培训	《培训计划》 《培训考勤记录》 《培训总结》	明确培训环境条件及方式，参加人员，课程课时等要求 培训记录，培训效果总结，是否达到目标	双方现场实施负责人	双方现场实施负责人
系统安装	《数据库安装目录》 《软件安装方法》 《软件使用操作手册》	现场安装、调试和提交软件的相关文档
	《软件功能清单》	所提交软件全部模块结构划分，功能描述	用户系统人员
	《软件交付书》	软件已在现场安装、调试、培训完成，基本可以进入试运行证明	用户系统负责人
	《软件问题及修改记录》	实施中发现的软件问题和用户提出的具体修改意见，以及对其所作修改和确认记录
项目验收	《验收计划》 《验收报告》 《项目总结》 《项目技术报告》 《数据库字典》	开发过程项目总结，技术总结，数据库设计字典等验收相关文档
日常工作	《现场工作日程安排计划》	需在现场进行较长时间的一般工作日程安排	双方现场实施负责人	双方现场实施负责人
	《用户项目报告》	较长时间不在用户现场时向用户信息服务系统汇报项目进展和工作情况，
	《现场工作周报》	现场工作周计划	双方现场实施负责人	双方现场实施负责人
	《阶段评估报告》	某阶段性目标实现后进行总结，向工程领导小组提交，为下阶段打好基础

第6章 突发事件处理

6.1 应急措施及组织结构

在应急事件的处理中，一个组织良好、职责明确、科学管理的应急队伍是成功的关键。组织机构的成立对于事件的响应、决策、恢复，防止类似事件的发生都具有重要意义。结合本次项目组织结构的实际情况，可将有关应急人员的角色和职责进行明确划分。

（1）领导小组

及时掌握突发事件的发展动态，向上领导报告事件动态；对有关事项做出重大决策；启动应急预案；组织和调度必要的人、财、物等资源。

本项目应急处理领导小组由项目总经理、行政主管、经济师组成。

（2）应急处理工作小组

负责定期了解外部支持人员的变动情况，及时更新其技术人员及联系方式等信息；尽早发现工作过程中的异常状况，排除隐患。

本项目主要由项目管控副经理以及项目采购及管控副总经理，相关处理人员组成。

（3）外部支持人员

包括各供货单位、使用单位、其他相关施工单位、监理单位。负责在紧急情况下的应急解决方案和应急技术支援体系的支撑；积配合应急人员进行事件处理。

6.2 应急工作小组机构及职责

在应急事件的处理中，一个组织良好、职责明确、科学管理的应急队伍是成功的关键。组织机构的成立对于事件的响应、决策、恢复，防止类似事件的发生都具有重要意义。结合本次项目组织结构的实际情况，可将有关应急人员的角色和职责进行明确划分。

 

（1）领导小组

及时掌握突发事件的发展动态，向上领导报告事件动态；对有关事项做出重大决策；启动应急预案；组织和调度必要的人、财、物等资源。

本项目应急处理领导小组由项目经理、行政主管、经济师组成。

（2）应急处理工作小组

负责定期了解外部支持人员的变动情况，及时更新其技术人员及联系方式等信息；尽早发现工作过程中的异常状况，排除隐患。

本项目主要由项目管控负责人以及项目采购负责人等相关处理人员组成。

（3）外部支持人员

包括各供货单位、使用单位、其他相关施工单位。负责在紧急情况下的应急解决方案和应急技术支援体系的支撑；积配合应急人员进行事件处理。

（4）XXX-5-XXX子项目安全员

负责定期检查子项目的安全运行内容，及时和技术人员、施工人员等进行沟通，尽早发现工作过程中的异常状况，排除隐患。

6.3 应急基本流程

 

维护服务应急处理流程

 

6.4 紧急事件类型

本处理预案所称的信息系统，由计算机设备、网络设施、计算机软件、社会保险数据等组成。

信息系统突发事件分为网络攻击事件、信息破坏事件、信息内容安全事件、网络故障事件、软件系统故障事件、灾难性事情、其他事件等八类事件。

1）网络攻击事件：通过网络或其他技术手段，利用信息系统的配置缺陷、协议缺陷、程序缺陷或使用暴力攻击对信息系统实施攻击，并造成信息系统异常或对信息系统当前运行造成潜在危害的事件。

2）信息破坏事件：通过网络或其他技术手段，造成信息系统中的数据被篡改、假冒、泄漏等而导致的事件。

3）信息内容安全事件：利用信息网络发布、传播危害XXX安全、社会稳定和公共利益的不良信息内容的事件。

4）网络故障事件：因电信、网络设备等原因造成大部分网络线路中断，用户无法登录信息系统的事件。

5）服务器故障事件：因系统服务器故障而导致的信息系统无法运行的事件。

6）软件故障事件：因系统软件或应用软件故障而导致的信息系统无法运行的事件。

7）灾害性事件：因不可抗力对信息系统造成物理破坏而导致的事件。

8）其他突发事件：不能归为以上七个基本分类，并可能造成信息系统异常或对信息系统当前运行造成潜在危害的事件。

6.5 预防措施

针对上门服务过程中可能遇到的各种各样的风险，我公司总结多年维护服务经验，针对一些可能出现的情况，制定了一系列预防处理措施，举例如下：

类型	事件	预防措施	处理
应用软件	无法启动软件可执行文件	上门人员提前准备好各类需维护软件安装程序	将应用软件数据文件备份后，重新安装
	软件打开过程中或运行中异常错误关闭	上门人员准备好安装程序，操作系统优化和修补软件，查杀病毒软件	判断出错原因，备份数据，采取相关修复措施
操作系统	使用者本机操作系统异常或系统资源占用严重	准备好系统检查程序及修补程序，以及查杀病毒软件	告知使用者错误原因可能类型，提出解决方案，经使用者认可后采取相应措施
	B/S结构系统，IE浏览器异常或无法下载控件	准备流氓软件清理程序、修复浏览器软件、查杀病毒软件	检查IE浏览器选项设置，分析原因进行修复
网络或服务器	B/S结构系统网络流量异常或服务器登录异常	判断服务器是否异常，否则准备杀毒软件	检查网络流量，流量异常小则报修网络服务商，流量异常大则查杀病毒

1、网络攻击事件应急预案

当发现网络被非法入侵、网页内容被篡改，应用服务器的数据被非法拷贝、修改、删除，或有黑客正在进行攻击等现象时，使用者或管理者应断开网络，并立即报告应急小组。

应急小组立即关闭相关服务器，封锁或删除被攻破的登陆帐号，阻断可疑用户进入网络的通道，并及时清理系统、恢复数据和程序，尽快将系统和网络恢复正常。

2、信息破坏事件应急预案

当发现信息被篡改、假冒、泄漏等事件时，信息系统使用单位或个人应立即通知应急小组。

应急小组通过跟踪应用程序、查看数据库安全审计记录和业务系统安全审计记录查找信息被破坏的原因和相关责任人。

应急小组提出修正错误方案和措施，通知各员工进行处理。

3、信息内容安全事件应急预案

当发现不良信息或网络病毒时，系统使用人员立即断开网线，终止不良信息或网络病毒传播，并报告应急小组。

应急小组根据情况通告局域网内所有计算机用户，隔离网络，指导各计算机操作人员进行杀毒处理、清除不良信息，直至网络处于安全状态。

4、网络故障事件应急预案

发生网络故障事件后，系统使用人员应及时报告应急小组。

应急小组及时查清网络故障位置和原因，并予以解决。

不能确定故障的解决时间或解决故障的期限并属较大（III）及其以上的，应急小组应报告组长。

5、服务器故障应急预案

服务器故障后，应急小组确定故障设备及故障原因，并通知象山县大数据发展中心。

政务云平台提供容灾备份服务，即时切换系统服务至可用服务器。

6、软件故障事件应急预案

发生计算机软件系统故障后，系统使用人员应立即保存数据，停止该计算机的业务操作，并将情况报告应急小组。

应急小组应立刻派出技术人员进行处理。

应急小组组织有关人员在保持原始数据安全的情况下，对计算机系统进行修复；修复系统成功后，利用备份数据恢复丢失的数据。

7、灾害性事件应急预案

一旦发生灾害性事件，应急小组每一位成员都应有责任在x时间进入机房抢救服务器及存储设备。

应急小组对服务器及存储设备的损坏程序进行评估。如服务器损坏或存储设备损坏无法使用，立即联系相关厂商，进入维保服务程序。

根据服务器或存储设备修复和恢复系统所需时间，由组长决定是否启用备份设备。

8、其他突发事件应急预案

应急小组立刻派出技术人员进入现场，制定相应措施，根据实际情况灵活处理，并按要求报告组长。

6.6 突发风险应急策略

不主动采取规避风险的措施，就有可能被风险击倒。在开始时，就进行风险预测是风险规避所必须的，从下面几个方面考虑:

• 风险发生的可能性
• 风险的后果
• 估算风险对项目及产品的影响
• 对风险进行精确描述

进行预测也是为了避免风险的发生，x好的结果就是不发生风险，这就需要对风险进行缓解、监控和管理:

• 用户需求:用户对项目组能否在预算时间内按时完成有很大的影响，这是个实际的风险，项目中采取如下措施来规避用户需求的风险:
• 回顾与用户的合作历史，了解用户;
• 详细了解用户需求;
• 由用户把需求正式整理成文，并明确规定项目范围;
• 建立与用户进行信息交流的通道;
• 建立用户愿意的复审程序;
• 了解用户对技术的认知程度;
• 了解用户对软件工程的认知程度。
• 开发技术:技术风险要考虑开发人员的实力和经验。项目中对技术风险的规避做到下面这些方面:
• 对所使用的技术进行评估，确定项目组对此技术的掌握程度;
• 了解用户需求是否需要创新的算法或输入、输出技术;
• 考察所开发的软件是否需要使用新的或未经证实的接口;
• 确定系统是否要与用户提供的未经证实的软件产品接口;
• 确定本系统是否有与其功能及性能都没在本领域中得到证实的数据库系统的接口;
• 确定用户需求是否要系统采用特定的用户界面;
• 考察系统使用的技术，看开发人员以前是否使用过;
• 分析需求，确定开发中使用的分析、设计和测试方法;
• 分析需求，确定开发中要求使用的软件浙移集成法;
• 分析需求，确定用户对产品性能要求的可行性;
• 其他与项目有关因素，主要考虑人员相关的风险:
• 项目中使用x优秀的人员;
• 合理配备人员，使他们在技术上能够配套;
• 准备足够多的项目参与人员;
• 保持开发人员的稳定性，使之能够始终参加整个项目的工作;
• 项目中尽量少用或不用只能部分时间参加工作的人员;
• 了解开发人员对自己工作的期望;
• 对开发人员进行必要的培训;
• 加强文档的管理，使开发人员的流动后，仍能保证项目开发工作的连续性。

6.7 业务证明数据损坏应急预案 

（1） 发生业务证明数据损坏时，运维服务小组应及时报告系统突发故障应急领导小组，检查、备份业务系统当前证明数据。

（2）运维服务小组负责调用备份服务器备份证明数据，若备份证明数据损坏，则调用磁带机中历史备份证明数据，若磁带机证明数据仍不可用，则调用异地备份证明数据。

（3）业务证明数据损坏事件超过 4小时后，运维服务小组应及时报告系统突发故障应急领导小组，及时通知业务部门以手工方式开展业务。

（4）运维服务小组应待业务证明数据系统恢复后，检查历史证明数据和当前证明数据的差别，由相关系统业务员补录证明数据；重新备份证明数据，并写出故障分析报告，在调查工作结束后一日内报告系统突发故障应急领导小组。

6.8 服务器软件系统故障应急预案 

（1）发生服务器软件系统故障后，运维服务小组负责人应立即组织启动备份服务器系统，由备份服务器接管业务应用，并及时报告系统突发故障应急领导小组；同时安排相关责任人将故障服务器脱离网络，保存系统状态不变，取出系统镜像备份磁盘，保持原始证明数据。

（2）运维服务小组应根据系统突发故障应急领导小组的指令，在确认安全的情况下，重新启动故障服务器系统；重启系统成功，则检查证明数据丢失情况，利用备份证明数据恢复；若重启失败，立即联系相关厂商和上单位，请求技术支援，作好技 术处理。

（3）事态或后果严重的，应向系统应急指挥办公室和相关领导汇报。

（4）处置结束后,运维服务小组应将事发经过、处置结果等在调查工作结束后一日内报告系统突发故障应急领导小组。