1 项目概括
1.1 客户需求
1.1.1 国家政策导向
国家住建部出台相关标准来规范建筑能耗监管体系的建设，如《绿色建筑评价标准GB/T 50378-2014》、《绿色医院建筑评价标准 GB/T 51153-2015》等。
财政部出台相应的鼓励政策来引导大型公共建筑开展节能减排工作，如，2012年，财政部、住建部联合印发文件，关于《组织2012年度公共建筑节能相关示范工作的通知》，提供专项资金申请，进一步推进公共建筑节能工作。
国家卫计委联合住建部开展医院能耗监管系统的建设工作，并予以资金支持。2014年6月，国家卫计委组织编制《全国医院节能规划（2014—2020年）》，积极制定《绿色医院建筑评价标准》，严格完善绿色医院评价体系，积极推进节约型公共机构示范单位建设。设置专项资金支持44家卫生委管理医院开展医院建筑能耗监管系统建设工作。
1.1.2 能耗精细化管理
医院人员密集、能源形式多样、能耗构成复杂，从而导致医院建筑能耗普遍偏大，有关资料表明，医院建筑能耗是一般公共建筑的1.6~2倍。因此，需要建设医院建筑能效监管系统，通对能耗数据实时采集，分类、分项计量，准确掌握不同医疗功能建筑、核算单元、特殊区域和重点设备的能耗，指导医院能耗管理，优化能源运营策略，减少能源浪费，同时为医院建筑节能改造提供依据。具体而言，主要满足以下几点需求：
（1）能耗数据的分类分项采集
根据医院消耗的主要能源种类划分进行分类采集和整理，如：电、水、集中供热、集中供冷等；
按医院建筑功能分类进行采集和统计，如门急诊类建筑、医技类建筑、病房类建筑、医疗综合类建筑、后勤办公类建筑、科研教学类建筑等；
根据消耗的各类能源主要用途划分进行分项采集和整理，如：空调用电、动力用电、照明插座用电、特殊区域用能等。
（2）能耗计量等级满足三级计量
三级计量包括楼栋、楼层、科室。对于不能做三级计量的，通过计量到楼层并提供拆分到科室房间的计算方法，以满足将能耗分摊到各科室。
（3）能耗统计与分析
通过将数据不断积累并加以对比排名分析，从而发现用能的不合理点；
通过对定额的设定与调整，为指导各科室用能提供有效支撑；
通过对既有建筑的能源计量分析，可以为后续用能提供预测，也可以为医院扩建、新建等提供能源规划支撑；
通过数据收集、分析，为后续节能工作提供支撑。
1.1.3 设备管理
医院供医疗、护理病人之用的特殊公共建筑，对能源的不间断供应要求高，需要保障能源的稳定供应，避免因电力、空调冷热水、生活用水的中断影响病患的安全和舒适度。
医院供能设备分布较为分散、数量众多、操作专业性要求高，周期性巡检和临床报修处理机制无法满足设备实时监视和及时消缺的需求；传统的纸质管理方式缺乏系统性，无法追溯各设备的历史运行数据，难以做到针对设备的统计与管理。
需要建立一个高度专业化、规范化、智能化及集成化的系统，来提高供能设备的管理水平与工作效率，实现设备运维的可追溯，为设备的全生命周期管理提供数据化的支持，同时，降低和控制设备故障、事故引发风险的可能性与严重程度，为患者、家属、员工和探视者提供安全可靠的环境。具体而言，主要满足以下几点需求：
（1）电力的稳定供应
实时监测高压侧双路供电线路的运行状态，实时推送故障告警，如停电、缺相、电压或频率超出范围；
实时监测柴油发电机运行状态，当市电均断电时，柴油发电机应自启动，短时内达到额定转速、电压、频率后投入负载运行；
柴油发电机应定期保养和运转，并进行记录；
对于不间断运行要求高的重点科室和部位，如手术室、ICU、信息中心机房，应对配备的EPS及供电回路进行实时监测，保证供电质量和可靠性；
实时监测并诊断电力系统故障信息，主动预防事故发生。
（2）设备的规范化运维和管理
设备定期进行预防性维护与保养，延长机电设备的使用寿命以及提高建筑安全性；
从多维度（设备运行信息、维修保养信息、故障及告警信息、能耗信息等）整合设备信息，进行存档、分析和评价，对设备进行全生命周期的管理，帮助医院预防问题，降低风险，制定系统改进决策，规划设备升级或更换。
1.1.4 后勤信息化
医院的人流密度大，后勤业务流程交叉，对后勤业务的安全性、可靠性、稳定性要求非常高；患者感受与后勤业务直接相关，影响病患的体验度；安全操作规范性低，对于多数后勤业务规范大多停留在医院本身的管理框架，没有细化。
医院后勤业务复杂导致评估指标多样，难以管理；相关业务重合，易成孤岛效应，不便于人员操作；后勤人员有一定流动性，管理资料、经验难以继承。
而后勤信息化平台可以让能源、设备、信息三者深度结合，并提供全面的分析工具，辅助决策；提供完善的在线监测、告警管理与分层管理功能；软件功能匹配管理者需求，节约投资，优化流程；
1.1.5 节能需求
为贯彻落实医院节能工作的长久机制，推进和深化节约型医院建设，卫生和计划生育委员会、国家住房和城乡建设部、财政部已在全国范围内开展医院建筑能耗监管系统建设及节能技术应用。
作为具有重要影响力的重点医院，龙岩第一医院各级领导对此非常重视，成立专门机构推进医院建筑节能改造工作。在对医院的各类能源消耗和计量监管现状进行了详细统计分析的基础上，同时根据《医院建筑能耗监管系统建设技术导则（试行）》和《医院建筑能耗监管系统运行管理技术导则（试行）》的具体要求，设计并完成了医院节能方案。
2 一体化解决方案总体设计
2.1 平台方案总体设计
基于对院方需求的支撑，医院后勤智慧运维一体化解决方案，关注医院后勤整体工作，针对后勤团队不同层级的需求，提供覆盖后勤工作流程的运维平台与服务，辅以自动化的物联传感设备支撑，打通后勤管理数据流，建立多维度指标体系，为管理决策提供数据支撑和管理手段，提供宏观态势，数据统计分析、设备仿真运行等不同角度构建与业务数据高效关联的可视化平台，实现业务流程再造和高效管理。
运行保障
后勤保障是后勤管理的核心，设备设施的安全运行是后勤保障的重中之重。医院智慧运维平台围绕着设备设施综合监测和设备告警管理，通过建设现场设备监测点位，建立设备运行预警平台，实现设备设施的在线实时监控，提升设备的安全运行保障，降低设备故障率。同时通过设备能耗管理，在保证设备安全运行的基础上实现能源利用合理化，降低能源消耗，起到降本增效的管理目标。
运维服务
服务是后勤管理的宗旨，医院智慧运维平台以提升后勤服务满意度为核心，打造设备设施运维管理和后勤服务管理平台，提升设备运维和后勤服务的响应效率，实现后勤工作的规范化、标准化。通过信息化管理，同时实现了日常工作的数据化，为数据分析和管理决策提供数据支撑，保证管理人员在日常管理中不断优化后勤工作流程，提升后勤工作的满意度。
管理提升
后勤管理的提升需要有效的管理与正确的决策，而管理和决策需要大量的信息支持，需要参考和把握既往与现行的数据和信息。医院智慧运维平台利用BI技术，通过对平台数据的挖掘、整合、分析，使管理决策人员准确掌握医院后勤资源的信息和后勤设备的状态，通过信息技术及信息数据的支持，结合分析、模拟和预测，做出相应决策，制定相应措施，从而确保医院医疗工作的运行顺畅。
2.2 方案特点
整体的端到端解决方案：
本项目设计使用的医院后勤智慧运维平台覆盖了感知层、通讯层、平台层和应用层。并在每一层都提供了自研产品，核心竞争力强，实现了从数据端到应用端的管理。
统一的设备编码为纽带，建立动静结合的设备台账：
医院后勤智慧运维平台以设备编码为基础，通过统一的设备编码关联设备检修、设备巡检和设备保养的全过程，实现设备台账的动态更新。
体系化的设备维修策略，实现设备可控：
医院后勤智慧运维平台通过设备标准检修体系和设备巡检、保养体系的建立，实现设备日常运维工作标准化、规范化，降低设备故障率，提升设备生命周期。
设备管理数据中心，提供科学辅助决策能力：
医院后勤智慧运维平台利用BI技术，通过对平台数据的挖掘、整合、分析，为管理决策人员准确掌握医院后勤资源的信息和后勤设备的状态，对后勤管理做出科学的决策提供数据支撑。
2.3 设计原则
2.3.1 安全性
业务安全：平台实现功能全部在医院安全稳定运行的基础上考虑，任何系统功能设计、实施服务、运维服务，需要最大程度以保证医院安全性为前提；
访问安全：通过设置系统访问权限实现。可配置角色和用户，设置角色、用户的页面访问权限、位置区域或功能区域访问权限；用户登陆时根据所授权的权限访问系统相应的内容；
数据安全：采用三级数据保存机制，防止数据丢失；采用冗余备份机制，防止数据损坏；采取安全防范措施，防止非法入侵。
2.3.1 先进性
一体化解决方案在设计思想、系统架构、采用技术、选用平台上均具有一定的先进性、前瞻性、扩充性，具有先进水平的分析模型和应用模型，为以后功能扩充打下基础。
2.3.2 实用性
一体化解决方案符合医院后勤管理模式，尽可能用简单、统一、可靠、易于使用的方式来实现，避免追求片面的复杂和完美。
软件操作简单、易于操作；同时提供强大的软件功能，供系统维护人员使用。
2.3.3 可扩展性
系统具有良好的接口和方便的二次开发工具，以便系统不断的扩充、求精和完善，更方便医院将来各类数字化系统建设的无缝接入。
2.3.4 经济性
在满足功能需求的前提下提高经济性，充分考虑降低初期建设投资、运行费用和维护费用。硬件设备选用性价比高，具有很高的可靠性和较长的使用寿命。
2.3.5 标准化
EAM设备管理平台可将区域内医院备品备件标准化，录入台账，进行统一调拨管理，通过标准化提高经济性。
2.4 设计依据
本方案依据包含但不限于如下规范：
2.5 功能设计方案
能源管理系统是能够帮助建筑体降低单位面积能耗、降低能源使用成本、提升能源使用安全、保障环境品质的综合系统。
2.5.1 能耗分析
能耗分析功能实现对区域对象|业态对象能耗的分析。
区域|业态对象能耗查询功能
根据已选择的对象，查看相应对象的“10分钟，小时”颗粒度的能耗值；支持折现和柱状图显示；支持表格显示，更加清晰，支持导出功能
查询时间选择功能
当前时间段选择功能，“当日、本周、本月”快速选择功能。
同比、环比
根据已选择条件，查询当前时间条件下同比、环比能耗信息。
单位面积、人均
根据已选择条件，查询对象单位面积能耗、人均能耗值。
能耗饼图
饼图形式显示各能耗占比。
2.5.2 能耗排名
区域|业态对象能耗查询功能
根据已选择的区域对象，查看相应对象各能耗类型能耗值及排名；
根据已选择的业态对象，查看相应对象能耗值及排名；
查询时间选择功能
当前时间段选择功能，“当日、本周、本月”快速选择功能。
单位面积、人均
根据已选择条件，查询对象单位面积能耗、人均能耗值。
转化为标准煤、碳排放量、转化为人民币
查询当前条件下，能耗转化为标准煤的值、二氧化碳的排放量、转化为人民币的值。
对象占比
饼图形式显示选定对象占比情况。
2.5.3 能耗对比
多对象、多时间
选择多对象，可以查看多个对象相同时间段内的能耗对比走势曲线；
选择多时间，可查看同一对象多时间段内的能耗对比走势曲线
区域|业态对象能耗查询功能
多对象——根据已选择的对象，对比查看各对象电、水、气等能耗值；
图 能耗对比界面
多时间——根据已选择的对象，查看该对象电、水、气等能耗值；
查询时间选择功能（多对象）
当前时间段选择功能，“当日、本周、本月”快速选择功能。
对比对象功能
多对象——表格形式查看各对比对象总能耗值，最大值，最小值，平均值。
多时间——表格形式查看各对比时间总能耗值，最大值，最小值，平均值。
2.5.4 关联分析
区域|业态对象能耗查询功能
根据已选择的对象，查看相应对象选定能耗类型、时间段下的能耗数据；
参数选择功能
选择不同的能耗类型设备，查看相应设备相应时间段下的数据；
关联系数
根据选定的“对象与能耗设备”数据，计算出两个数据选定时间段内的相关性系数。
2.5.5 能效专家
变压器
支持按区域拓扑中选中对象，查看不同对象对应的平均负载率、功率因数、运行效率、损耗率、变压器温度等多项信息指标。
区域对象信息查询功能
可根据选中的不同区域对象，查询相应对象的各指标数据。
时间选择功能
可选择不同的时间段作为查询限制条件，或者使用快速选择连接选择“当日、本周、本月”。
平均负载率、功率因数、运行效率、损耗率、变压器温度
选择“平均负载率、功率因数、运行效率、损耗率、变压器”，查看相应指标数据。
同比值、环比值
可查看“负荷总览，损耗率总览”的同比数据，环比数据。
空调
支持按区域拓扑中选中对象，查看不同对象对应的“冷冻水输送系数，冷却水输送系数，冷冻水温度，冷却水温度”等信息。
时间选择功能
可选择不同的时间段作为查询限制条件，或者使用快速选择连接选择“当日、本周、本月”。
冷冻水输送系数，冷却水输送系数，冷冻水温度，冷却水温度等能源成本
选择“冷冻水输送系数，冷却水输送系数，冷冻水温度，冷却水温度”，查看对象不同的数据信息。
同比值、环比值
可查看“能耗总览”的同比数据，环比数据。
能效对标
查看能效对标，判断冷冻站所处能耗水平。
2.5.6 驾驶舱
用能规划
展示能耗节点的能耗KPI数据，包括定额值与剩余值，如下图所示。
节能架构
展示组织结构信息与节能通告，如下图所示。
告警总览
展示月和日时间范围内的告警数量曲线，如下图所示。
能耗总览
展示节点下的能耗占比饼图，以及能耗排名信息，如下图所示。
环境品质
展示节点的环境数据，比如温湿度、二氧化碳等数据，如下图所示。
2.5.7 KPI管理
定额KPI管理
根据查询条件，查看各“能耗类型、区域、时间段内”对应的“能耗定额、实际能耗、剩余能耗”。
区域对象定额分析功能
选择区域对象，实现对相应对象“定额信息、实际消耗、能耗趋势”等信息的查询。
定额时间选定功能
可自由选择要查询的年月。
能耗趋势分析功能
根据实际能耗信息，图形计算显示年内、月内的剩余能耗趋势分析。对比显示“定额之，实际值，趋势”三者之间的关系。
多能耗信息同时展示
同时显示“电能耗、水能耗、单位建筑面积能耗、单位空调面积能耗”等能耗信息的“定额值、实际消耗值、剩余值、能耗趋势”的关系。
经营KPI
根据查询条件，查看各“业态|区域、时间段内”对应的KPI信息。
实现对单位床日能耗、单位门诊量能耗、万元GDP能耗、单位业务量能耗、单位面积能耗、单位空调面积能耗等指标的管理
选择区域对象，实现对相应对象“实现对单位床日能耗、单位门诊量能耗、万元GDP能耗、单位业务量能耗、单位面积能耗、单位空调面积能耗”等信息的管理。
单位床日能耗、趋势分析
选择区域对象，实现对相应对象“单位床日能耗、趋势分析”等信息的查询。
单位门诊量能耗、趋势分析
选择区域对象，实现对相应对象“单位门诊量能耗、趋势分析”等信息的查询。
万元GDP能耗、趋势分析
选择区域对象，实现对相应对象“万元GDP能耗、趋势分析”等信息的查询。
单位业务量能耗、趋势分析
选择区域对象，实现对相应对象“单位业务量能耗、趋势分析”等信息的查询。
单位面积能耗、趋势分析
选择区域对象，实现对相应对象“单位面积能耗、趋势分析”等信息的查询。
单位空调面积能耗、趋势分析
选择区域对象，实现对相应对象“单位空调面积能耗、趋势分析”等信息的查询。
2.5.8 人工录入
数据录入
根据“能源类型、区域对象、业态对象、设备、时间颗粒、时间”录入人工填报信息。
记录查询
根据“时间颗粒、时间段、设备名称、能源类型、区域对象、业态对象、设备”综合查询相关人工录入信息。
3 项目管理方案
3.1 项目管理整体方案
3.1.1 项目管理方法论
3.1.1.1 项目管理原则
在项目管理过程中，应遵循和贯彻以下几点原则：
1、以客户为中心，全过程的多方协作原则。从项目立项、需求调研到后来的系统发布、上线、试运行和客户验收的全过程中，保证与总集成商、客户方紧密配合，协调工作，使得三方的作用在项目实施中都能很好的发挥；
2、发挥质量体系组织能力，降低项目管理开发的个人依赖性。在项目的开发计划、质量计划制定，项目需求调研分析、设计分析以及项目的各个重要阶段，各个部门按照质量体系要求，对项目的重要阶段进行咨询和监控，避免由于项目经理或开发人员的个人因素给项目质量带来重大影响。
3、阶段控制和全程控制相结合的原则。项目实施分为若干阶段，每个阶段的实施质量影响着后续阶段的项目质量，因此必须实施严格的阶段控制保证每个阶段的实施质量，对于重要的项目实施阶段如需求分析、系统设计必须重点控制；同时结合整个项目的具体情况，对整体项目的各个阶段的协调、进度控制、总体资源和成本进行控制，是项目管理控制的另一个角度。
4、全员控制的原则。项目的质量是所有项目参与人员包括需求分析、设计分析、软件编码、测试人员等等共同努力才能保证的结果。因此，每个参与项目的设计开发人员必须是有能力完成自身的工作，担负明确的质量责任。质量体系中对每个项目参与人员的质量责任都作了明确的界定。
5、人员组织管理和技术管理相结合的原则。软件项目的成功不仅需要完善的组织管理水平，同时需要先进成熟的技术和深厚的行业知识。针对具体的项目，选择在该类项目上具有成熟经验的开发人员；同时，利用先前开发的产品或成果，总结利用业界先进的技术，也是项目管理的重要部分。
3.1.1.1.1 项目实施管理框架
针对建设规模大、时间紧、技术要求高类的项目，对项目的实施和管理提出了很高的要求。大项目实施管理框架下图所示：
项目实施和管理工作开展从四个层次考虑，分别是战略层、管理层、执行层、监督层，在战略层我们从本项目实施要求和工程技术方案出发，分析项目难点和关键任务，制定项目实施管理总体策略，并对项目实施范围进行明确定义，提出项目实施管理方法，从宏观层面制定项目实施和管理的策略、方法；在管理层我们关注项目的组织、计划、制度规范、使用的工具和交付成果，通过与甲方管理层的充分沟通、交流，在经验、知识、项目特点的基础上建立项目实施组织并制定实施计划，对项目实施过程的关键阶段任务和里程碑进行定义，同时制定项目实施管理的制度、规范，选择合适的项目实施管理、开发、测试等工具，保证项目的可管理性；执行层主要考虑项目管理方面的内容，如进度控制、范围控制、风险控制、沟通管理等，从项目具体实施的各方面因素考虑，做好项目前期准备、工程管理工作，此外还要考虑知识转移的管理，使项目建设成果被用户最大程度的使用，以期对用户的工作有更大的帮助；监督层为项目实施管理引入过程监督机制，由甲方项目管理人员、工程监理、专家参与项目实施的全过程，行使监督管理职能，为项目成功提供更多保障。
3.1.1.2 项目管控模型
多年的经验积累，大型工程项目的管控要素可以分布三个相对独立的纬度上，分别是软件工程、项目管理和过程管理三个方面。
其中，软件工程提供软件项目实施的过程组织方法和各阶段工作的工作方法、目的、工具等；项目管理则是从管理的方面进行项目的范围、进度、成本、质量、风险等方面的管理；过程管理是对项目的过程组织从微观上进行管理，它关心项目中每个阶段、每个过程的启动、计划编制、执行、监控、收尾的过程。
通常，信息系统实施项目中的多数工作都是由三个纬度方面的要素组合构成的。这样，我们依据以上三个纬度来分析本项目的难点重点，会比较系统和全面，避免产生疏漏。
3.1.1.3 项目管控策略
为了保证整个工程能够自始至终协调有序、保质保量地按计划完成，本项目的系统建设工作设计了完善的项目组织结构，配备了一批具有扎实的项目管理理论知识和丰富的系统工程实践经验的项目管理人员、ISO9001和CMMI质量管理人员和工程技术人员组成项目队伍。通过遵循ISO9001和CMM质量管理体系要求，已经形成了完整的包含分析、设计、开发、测试、实施、验收等项目实施全过程的管理体系。以此为基础规范项目的实施过程，降低和消除项目风险，保证本项目的质量和工期。
3.1.1.4 项目管理内容体系
现代项目管理知识体系主要包括PMI开发的PMBOK、APM开发的APMBOK、IPMA开发的IPMA-ICB三种主流知识体系，PMBOK最具代表性，定义了项目管理九大知识领域（项目整体管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理。）、44个知识单元，以及五个管理过程，同时，项目管理融会贯通了以上9大知识领域，并在这9大领域的内容中贯彻了质量管理体系，是ISO9000和CMM的结合体，综合运用以上知识和工具、方法，来规划、组织、指导和监控项目进度、成本、质量、人力资源、风险等各个方面来实现项目建设目标的过程，项目管理内容体系框架如下图所示：
项目管理基础部分的主要内容是项目与项目管理的基本概念，项目生命周期的三个阶段、五个过程、项目管理的九大知识领域是项目管理的基本过程，方法与工具则包括了项目管理常用的方法和工具。
按项目生命周期来讲，项目分为启动、执行、收尾三个阶段，按项目生命周期作为线索进行知识组织呈现了项目自始至终其主要活动在时序上的逻辑，能够突出项目管理的核心过程，有利于把握项目管理的核心过程和重要内容。
按项目管理知识领域来讲，项目管理九大知识领域是基于项目管理职能分工的背景而提出，将跨生命周期阶段的知识内容按项目管理职能领域进行组织，能清晰体现知识领域的逻辑性和与项目周期、过程的关系。
3.1.1.5 项目管理工具与方法
项目管理方法与工具是项目管理的重要组成部分，根据不同项目的特点可以选用不同的方法与工具，常用的项目管理方法如下表所示：
1.管理领域 方法与工具
2.范围管理 工作分解结构
3.时间管理 网络技术技术、甘特图、里程碑图
4.费用管理 项目融资、资源费用曲线、资源负荷图
5.质量管理 质量控制方法、质量技术文件、标杆管理
6.人力资源管理 责任矩阵、激励理论
7.风险管理 模拟技术
8.沟通管理 沟通方式
9.综合管理 挣值方法、并行工程
10.其他要素分层法、方案比较法、SWOT分析法、资金时间价值、评价指标体系、项目财务评价、不确定性分析、有无比较法
常见的其他项目管理工具有微软的MS Project和 Rational ClearQuest，MS Project是一个功能强、管理细腻、操作方便的优秀项目管理网络计划软件。它为提供了一套完整的项目描述和计算的方法及模型，通过这个软件生成的图、表或文件，使所有参加项目工作的人员对于项目的理解达到共识，从而能够协调一致地工作，出色地完成项目。
3.1.2 范围控制方案
项目是为完成产品或服务所做的一次性努力。因此在这里，范围的概念包含两方面，一个是产品范围，即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。在确定范围时首先要确定最终产生的是什么，它具有哪些可清晰界定的特性。要注意的是特性必须要清晰，以认可的形式表达出来，比如文字、图表或某种标准，能被项目参与人理解，绝不能含含糊糊、模棱两可，在此基础之上才能进一步明确需要做什么工作才能产生所需要的产品。也就是说产品范围决定项目范围。
范围管理保证项目包含了所有要做的工作而且只包含要求的工作，它主要涉及定义并控制哪些是项目范畴内的，哪些不是。范围管理的基本内容包括：项目启动、范围计划编制、范围核实、范围变更控制等等。以下所讨论的是其中比较重要的部分。
3.1.2.1 范围定义及跟踪
“工欲善其事，必先利其器”。要想真正管理好项目范围，没有必要的技术和方法是肯定不行的。国外曾经有人对项目失败原因进行调查，其中计划被放到了首位，可见它在项目管理中的重要性。
首先就是周密地做好范围计划编制。范围计划编制是将产生项目产品所需进行的项目工作（项目范围）渐进明细和归档的过程。做范围计划编制工作是需要参考很多信息的，比如产品描述，首先要清楚最终产品的定义才能规划要做的工作，项目章程（典型的例子是合同）也是非常主要的依据，通常它对项目范围已经有了粗线条的约定，范围计划在此基础上进一步深入和细化。
范围说明在项目参与人之间确认或建立了一个项目范围的共识，作为未来项目决策的文档基准。范围说明中至少要说明项目产品、项目可交付成果和项目目标。项目产品是产品说明的简要概况；项目可交付成果一般要列一个子产品级别概括表，如：为一个软件开发项目设置的主要可交付成果可能包括程序代码、工作手册、人机交互学习程序等。任何没有明确要求的结果，都意味着它在项目可交付成果之外；项目目标是要考虑到项目的成功性，至少要包括成本、进度表和质量检测。项目目标应该有标志（如：成本、单位）和绝对的或相对的价值（如：少于1000万元等）。不可量化的目标（如：“客户的满意程度”）要承担很高的风险。
范围管理计划是描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估（比如：怎样变化、变化频率如何及变化了多少）。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类（当产品特征仍在被详细描述的时候，做到这点特别困难，但绝对必要）等问题的清楚描述。
3.1.2.2 需求管理
需求是整个项目的设计开发和实现入口，对于需求的管理是非常有必要的。需求管理指识别、分析、建立客户需求，监控需求的状态，控制需求的变更过程，进行客户需求的追溯等活动。需求规格说明书是重庆市应急资源管理和共享项目的建设内容的范围描述和框定，是进行项目建设开发的依据，需求管理是范围控制的重点管理内容。
3.1.2.2.1 需求管理的主要活动
需求管理为项目在需求方面建立和维护与客户的共识，并将所建立的客户需求作为估算、策划、实施和管理项目的基础；控制管理需求及其变更，使项目开发计划、工作产品和活动与客户需求保持一致；进行客户需求的追溯，可改善产品质量、降低维护成本、实现重用。需求管理的活动贯穿项目的整个生命周期。
3.1.2.2.2 需求管理强调
• 控制对需求基线的变动。
• 保持项目计划与需求一致。
• 控制单个需求和需求文档的版本情况。
• 管理需求和联系链之间的联系或管理单个需求和其它项目可交付物之间的依赖关系。
• 跟踪基线中需求的状态。
需求管理的主要活动包括变更控制、版本控制、需求跟踪等几个方面，如图所示：
3.1.2.2.3 需求变更控制
当客户方提出新需求或有新的政策法规、管理制度下达时，要对已有需求进行需求变更。
（一）目的
修改“原需求文档”中不正确的内容，产生新的需求文档。
控制需求文档的变更，防止发生混乱。
（二）启动准则
项目组一方（来自开发方或客户方）提出变更“原需求文档”的申请（一般是新需求或新政策下达后）。
（三）主要步骤
1、提交需求变更申请
根据项目具体需要，或来自客户的需求变更，由项目组长根据具体项目情况，组织填写软件需求变更申请。
2、需求变更评审与审批
标识相关需求变更；
根据变更计划执行需求变更。
3、需求变更追踪
制定新的项目计划（也包括SQA计划和SCM计划）或项目周计划；
填写项目需求变更列表。
（四）变更管理的控制流程
变更控制流程如下图所示：
3.1.2.2.4 需求版本控制
版本控制是需求管理中必不可少的功能，特别是在多人协作的团队中，版本控制工具可以提高效率，消除很多由于版本带来的问题。
通过需求管理工具，可以记录需求变化的每一个版本，可以定制为当需求文档发生变化、需求负责人、状态发生变化、或需求的某些重要字段发生变化，就自动记录需求的一个版本，需求管理工具不仅可以记录需求的版本，还可以恢复到需求的任何一个版本，这极大的方便了需求管理者的工作。
3.1.2.2.5 需求跟踪
项目组通过《需求跟踪矩阵》建立各个开发阶段各个需求点之间的连接链。
1、分析阶段的需求跟踪
软件工程组在《需求跟踪矩阵》中建立业务需求和软件需求的对应关系，将已经完成需求分析的业务需求状态标识为“R”，未完成需求分析的业务需求状态标识为“UR”。
2、设计阶段的需求跟踪
软件工程组在《需求跟踪矩阵》中建立软件需求和设计项的对应关系，将已经完成设计的需求状态标识为“D”， 未完成设计的需求状态标识为“UD”。
3、编码阶段的需求跟踪
软件工程组在《需求跟踪矩阵》中建立设计项和代码项的对应关系，将已经完成编码（通过自测）设计状态标识为“C”， 未完成编码（通过自测）的设计状态标识为“UC”。
4、单元测试阶段的需求跟踪
测试组在《需求跟踪矩阵》中建立代码项和单元测试用例的对应关系，将通过单元测试的代码项状态标识为“U”， 未通过单元测试的代码项状态标识为“UU”，并更新测试文档。
5、集成测试阶段的需求跟踪
测试组在《需求跟踪矩阵》中建立设计项和集成测试用例的对应关系，将通过集成测试的设计项状态标识为“I”， 未通过集成测试的设计项状态标识为“UI”，并更新测试文档。
6、系统测试阶段的需求跟踪
测试组在《需求跟踪矩阵》中建立软件需求项和系统测试用例的对应关系，将通过系统测试的软件需求项状态标识为“S”， 未通过系统测试的软件需求项状态标识为“US”，并更新测试文档。
7、发布阶段的需求跟踪
软件工程组对需求和验证项的对应关系进行维护。
3.1.2.2.6 需求管理输出文档记录
《需求跟踪矩阵》
《需求变更申请表》
《需求变更评审报告》
《需求变更状态跟踪表》
《软件需求规格说明书》
《需求管理过程检查表》
3.1.2.3 变更管理
项目发生变更时，如果管理不好，就会直接导致项目延期或失败，所以变更管理在整个项目的管理中处于重要位置。
大型复杂项目的变更往往会导致项目建设目标的偏离，造成投资的浪费和成本的不可控。因此对于项目的变更要严格控制，尤其对于重大变更必须由项目各方都参加的联席会议评审通过，对于重大的技术变更，必须由专家委员会评审通过。并经过总集成商和总监理方的签批认可。
项目变更管理主要是控制影响项目变更的因素，并有效控制变更的影响。下面针对本项目列举可能产生的变更原因和对变更管理的流程。
3.1.2.3.1 变更的类型
纳入本项目变更管理的变更类型主要包括：范围变更、业务需求变更、技术架构变更、进度变更、交付物变更。
从变更提出人的角度，又可以分为中标人提出的项目变更和招标人提出的变更。
如果是我方提出的项目变更，我们将提前对变更的影响和范围进行评估，并评估其变更对其他相关项目的影响，经招标人确认后方可实施变更。我方确保自身申请变更的合理性，在成本上可以接受，对受影响的交付物按照新基准进行相应调整。
在应用系统集成工作终验前，因建设单位提出的需求变更、项目变更等，我方应无条件接受，不对此额外申请费用。
3.1.2.3.2 变更产生的原因
造成项目变更的原因很多，具体包括如下：
项目的变更需求一旦执行，有可能会影响到项目计划的调整，这点在项目管理中要注意及时调整并发布给相关项目组成员。
3.1.2.3.3 变更控制流程
1、首先由需求人提出变更需求，提交给项目经理。项目经理接收到变更需要后，查看是否合理、信息是否全面；
2、项目经理委托有经验的实施组长或专家对变更需求进行分析，主要从变更对项目的质量、进度、费用、流程等各方面进行影响分析；
3、项目经理根据分析报告决定变更需求是否能实施，如果不能实施，提出解决建议并召开由项目管理办公室参加的变更会议；
4、通过变更会议，对变更进行裁决是否可行；
5、项目经理应及时跟踪变更的执行，并分析对项目的实际影响。
3.1.2.3.4 变更控制工具
项目的变更需求一旦执行，有可能会影响到项目计划的调整，这点在项目管理中要注意及时调整并发布给相关项目组成员。
项目的变更管理要结合项目管理信息系统的变更管理工具，变更的提交、评审、跟踪、实施以及变更相关配置文档的修订更改等都需要记录。
相关文档包括：《项目变更申请表》、《项目变更通知单》、《项目变更跟踪表》。
3.1.2.3.5 变更控制文档
项目的变更需求一旦执行，有可能会影响到项目计划的调整，这点在项目管理中要注意及时调整并发布给相关项目组成员。
项目的变更管理要结合项目管理信息系统的变更管理工具，变更的提交、评审、跟踪、实施以及变更相关配置文档的修订更改等都需要记录。
相关文档包括：《项目变更申请表》、《项目变更通知单》、《项目变更跟踪表》。
3.2 项目质量管理
项目质量管理是为确保项目达到其质量目标所需要实施的一系列过程。包括质量规划、质量控制和质量保证等。
本项目将接受客户方有关软件质量情况的监督，无条件接受客户方的要求和建议，并进行认真整改；我们将制定项目质量管理制度，明确项目质量管理工作流程及发现、解决质量问题的方法；将根据质量目标层层分解，制定分层次的质量职责，并明确责任人；将明确项目质量目标、质量标准，定期举办质量保障评审会和技术研讨会，提供评估流程以确保软件质量，明确项目产出物的评审，确定评审的方式和时间。
对于本项目，将根据用户的要求，参照ISO9001质量体系和CMMI模型，在各个阶段严格履行质量保证计划，从而最大限度地避免因工程质量问题造成的返工，保证用户可以按期使用满足质量要求的应用系统。
3.2.1 项目保障目标
1、遵循成熟的管理过程执行本项目；
2、确保交付的软件及其文档质量达到行业标准；
3、确保交付的软件及其文档经过内部审查和评审；
4、软件系统开发文档和软件系统使用帮助文档要求具有完整性、一致性和方便性；
5、确保各实施过程经用户参与和检验；
6、最终实现客户满意。
3.2.2 质量保证角色与职责
3.2.3 质量保证流程
在项目具体开展过程中，项目组及相关人员将严格按质量管理体系要求的工作流程执行，其中，涉及项目管理控制的环节主要有三个，一个是以项目经理为主的“项目跟踪与监控工作流程”，一个是以配置管理员（CM）为主的“配置管理工作流程”，一个是以质量保证员（QA）为主的“质量保证工作流程”。具体执行流程分别描述如下。
3.2.3.1 项目跟踪与监控工作流程
3.2.3.2 配置管理工作流程
3.2.3.3 质量保证工作流程
3.2.4 本项目过程和产品的检查与评审
3.2.4.1 项目过程和产品检查活动
在项目的进行中，由技术专家顾问，项目管理部和质量控制人员组成专门的质量控制小组，不定时的对项目在技术和管理方面进行抽查，并将考核直接上报给公司的最高管理层，统筹管理，保证项目能高标准的满足用户需求。
（1）产出物检查
包括但不限于：
项目总体计划检查（准备阶段，正式评审）；
项目过程裁剪表检查；
需求规格说明书检查（需求阶段，正式评审）；
概要设计说明书检查；
详细设计说明书检查（设计阶段，正式评审）；
代码检查；
测试环境检查；
招标人测试环境测试工作计划检查（测试阶段，正式评审）；
试运行工作总体实施方案检查；（试运行阶段，正式评审）
软件安装部署实施方案检查；
推广实施方案检查（推广阶段，正式评审）；
推广实施阶段应急预案检查。
（2）过程检查
包括但不限于：
项目计划检查；
项目过程裁剪检查；
风险管理检查；
里程碑检查；
项目监控检查；
需求开发检查；
需求管理检查；
系统设计检查；
系统测试检查；
产品发布检查；
系统上线检查；
配置管理检查；
评审检查；
项目结项检查；
项目验收检查。
3.2.4.2 项目过程与产品检查形式
质量保证人员通过参与项目的各种重要会议，参与一些重要的管理活动，包括与项目经理和项目组成员进行沟通，以达到对项目过程的检查目的；通过对项目文档的检查和审核，以及与相关人员的沟通达到对项目产品检查的目的。
质量保证人员参与的项目组的管理活动：
（1）项目质量管理例会
项目质量执行例会，是项目质量管理的最重要的活动。
参加人员：质量经理、项目经理、项目核心组成员、质量管理组成员。
主持人：质量经理
会议内容：总结各小组在各阶段的工作是否达到或满足质保计划的要求，以及改进措施
递交件：《项目质量管理例会会议纪要》
执行频度：在项目每个阶段的开始。
（2）项目每周例会
项目每周例会，是项目组一般情况下的主要管理活动。
参加人员：项目经理、成员、质量管理组成员。
主持人：项目经理
会议内容：总结上周计划执行情况，审查下周工作计划。解决项目中的问题。
递交件：《项目周报》
执行频度：每周一次。
（3）项目技术和管理检查会
项目技术和管理检查会，是项目组不定期的对于技术或管理的自我检查活动。
参加人员：项目经理、成员、质量管理组成员。
主持人：项目经理或项目核心组成员。
会议主持人：项目经理或项目核心组成员。
递交件：《会议纪要》
执行频度：视需要而定。
（4）里程碑审查会
里程碑审查会：在项目进程中的关键点（如需求确定、设计完成），组织较大规模的审查活动，以帮助项目组防范风险。
参加人员：质量管理组人员，项目组主要人员，客户方的后援机构，公司的后援机构。
递交件：《会议纪要》和《里程碑检查表》
执行频度：根据需要而定。
（5）评审会
评审会：在项目总体计划、需求规格说明书、系统设计说明书、系统测试方案等需要客户方参与评审的重要会议，质量保证员需要参加，一些内部的评审会议和重要的讨论会议也最好能够参加。
主持人：客户方领导，或我方项目经理
参加人员：质量管理组人员，项目组主要人员，客户方的后援机构，公司的后援机构
递交件：《评审报告》
执行频度：文档确定需要评审，同时变更也需要评审。
（6）务虚会
务虚会：比较自由的一种会议，一般用来发现项目管理中的漏洞和风险。
参加人员：不限。包括质量管理组成员。
递交件：《会议纪要》
执行频度：根据需要而定。
3.2.4.3 本项目质量保证工作总结
每周，质量保证员将质量保证活动情况汇报给质量保证经理，提供项目周报中质量保证部分内容；
每月，质量保证组出具软件质量测量报告，提交项目经理；
每个里程碑，质量保证员将质量保证活动情况汇报给质量保证经理，提供里程碑报告中质量保证部分；
项目结项时，质量保证员进行质量保证活动总结，向质量保证经理汇报。
3.2.5 质量保障措施
质量保障措施包括项目质量管理保障措施和软件开发质量保障措施两方面。
3.2.6 项目质量管理保障措施
3.2.6.1 资深的质量经理与质保组
针对本项目，将派遣资深的质量经理参与质量保证组（简称SQA组）。SQA组负责确保项目遵守质量保证体系的标准要求，确保遵循项目计划书中描述的要求，确保交付的软件及其文档以及非交付的软件在需求、设计及管理等诸多方面的质量。
3.2.6.2 全程参与的质量经理
质量经理，即质量保证组组长，监控项目成员的软件活动，并对软件产品与可适用的标准、过程和软件开发计划的符合性进行评价，为双方项目领导小组监控项目的软件生产提供适当的可视性。
3.2.6.3 合理的质量控制流程
质量经理负责对项目进行监控与分析，将结果报告给由双方高层人员组成的项目领导小组。项目经理批准发布给用户的所有文档和软件，必须得到质量经理的复核和批准。
3.2.6.4 质量管理规范
质量经理的工作依据为行业标准、客户方约定的管理规范和公司的管理规范，工作方式为编制质量计划、过程和产品检查、评审和审计、问题上报等。
3.2.6.5 服从工程监理
鉴于本项目的专业性和复杂性，如本项目中标，乙方将在系统建设、系统测试和验收等各环节严格服从专业监理公司的全过程监控，以保证整个项目的质量。
3.2.6.6 加强协调管理
由于本项目参加建设单位较多，需要统一协调与配合。如本项目中标，乙方将积极配合、充分协调项目参与各方的关系，提高工作效率，团结一致共同建设本项目。
3.2.6.7 严格合同和计划管理
本项目内容复杂为保证工程建设的质量和建成后运行的质量，在施工各环节将严格加强合同管理和计划管理，严格按合同及工作计划进行施工，确保工作质量。
3.2.6.8 重视培训
由于本项目内容复杂，专业程度较高，乙方将把培训工作贯穿到整个建设过程中。本项目的培训不能按照传统的培训方式在项目完成后进行，在工程设计、施工阶段采用边设计施工边培训的方式，以便用户更快使用本系统，同时保证工程少出偏差，保证工程质量。
3.2.6.9 软件质量保障措施
软件质量保障措施包括对项目资源的保障，对质量管理过程的保障和对产品质量的技术保障。
3.2.6.9.1 对软件产品的测试
软件测试是对软件产品质量保障最重要的措施之一。
测试是评价检查质量目标实现的重要手段，过程如下：
3.2.6.9.2 对软件产品生产过程的审计
项目质量经理将检查软件产品确实已经得到评审，确保评审报告的结论和问题已经得以解决。对软件生产过程进行审计，以过程审计报告的形式提供给相关管理者。
3.2.6.9.2.1 审计项目计划和监控过程
项目计划和监控要求项目经理编制出各种软件开发、计算机软件配置项（CSCI）测试和系统测试、软件安装和软件交付的计划。对项目开发的文档，质量经理应当帮助项目标识出适当的指南，标准或数据项描述，并帮助项目对这些指南、标准进行裁减，以满足项目的要求。
3.2.6.9.2.2 审计软件需求管理过程
软件需求分析的目的是规划出软件的需求基线，编制需求基线文档，并对需求基线进行管理；对软件需求的澄清、更正或变更请求做出应答；对各种请求的影响进行分析；修订软件需求规格书；并对软件需求分析和变更过程进行管理。
3.2.6.9.2.3 审计设计过程
设计活动确定软件的整个结构。根据前一阶段标识的软件需求，将软件分解成许多功能块，然后定义每一功能块的各个功能以及这些功能块之间的关系。
详细设计的目标是从逻辑上定义软件应当如何满足已分配的需求。详细设计应该详细到这样的程度，使得其他工程师，而不是原始设计者完成计算机编程。
3.2.6.9.2.4 审计软件实现和单元测试过程
软件实现或编码指的是在软件开发周期中实施软件设计的软件过程点。这个过程也包括软件代码的单元测试。
3.2.6.9.2.5 审计集成测试与系统测试过程
在软件开发生命周期的集成测试阶段，测试的焦点已从单个软件组件的正确性转移到组件与组件之间接口的正确性操作，转移到整个系统的信息流，以及系统要求的满足程度。
质量经理对集成测试与系统测试过程进行审计，提交审计报告给项目经理。项目经理对审计中的不符合项进行改进。
3.2.6.9.2.6 审计验收交付物
质量经理应当对交付物的准备活动进行审计，以确保结束项产品的功能审计和物理审计的程序或项目需求一直都得到满足。在某种情况下，如果项目没有满足合同的要求或标准，则容许质量经理禁止某些项目的交付，例如文档、代码或系统。
质量经理对于交付物的审计，提交审计报告给项目经理。项目经理对审计中的不符合项进行改进。
3.2.6.9.2.7 审计配置管理过程和变更活动
按照软件配置管理程序文件要求审计和审计配置管理过程和变更活动。
质量经理对更改活动的过程进行审计，提交审计报告给项目经理。项目经理对审计中的不符合项进行改进。
3.2.6.10 项目质量控制点
按照项目特点，根据项目组织和管理规范和乙方软件开发质量保证体系，本项目的质量控制点主要体现在开发过程质量控制点及数据中心建库过程质量控制点。
3.2.6.10.1 开发过程过程质量控制点
开发过程包括项目的需求、设计、编码、调试、测试及试运行等。在这几个阶段
3.2.6.10.1.1 需求阶段
需求是系统开发和测试的入口，需求工作的成效直接影响项目的成败。因此，下面首先介绍我们在需求工程方面积累的一些理论知识和实战经验。
需求工作可以分为开发和管理两方面的工作。需求管理主要包括需求基线形成、需求跟踪矩阵和变更控制三方面的工作。在实施团队中，主要是由项目管理团队负责需求管理工作。需求开发包括需求调研（在RUP定位为业务建模）、需求分析（在RUP定位为系统建模）、规格说明书的编写（含功能和非功能两部分）、需求原型的开发细化、规格说明书的评审和需求验证。这方面的工作主要需求经理和行业专家负责。
需求评审工作也是一项十分讲究技巧的活动，通常，我们会对此事做专门的策划和精心安排，一般将分成三个层次的评审，第一层是项目组内部人员和操作层面客户的评审，第二个层次业务管理人员和行业专家的评审，第三个层次是有决策层参加的评审会。
3.2.6.10.1.2 需求调研与分析
1、在用户的配合下，完成需求调研，明确业务点、功能、数据项、流程和界面原型。对关键应用系统要遵循甲方要求提供原型并组织开发。其中提供的原型需要经过专家论证和用户论证，确认所提供功能可达到用户使用要求后，再在此基础上进行后续的设计和开发。
2、编制《软件需求规格说明书》。《软件需求规格说明书》中将具体明确本项目的业务功能需求、性能需求和用户对本系统的其他相关要求。以此作为本项目实施的依据，从而保障项目的实施进度和质量。
3、《软件需求规格说明书》评审，制定第一版《软件需求规格说明书》，其后的软件开发过程以需求说明书为指导。
4、在需求发生改变情况下，通过需求变更，对《软件需求规格说明书》相关部分进行更改或细化。
3.2.6.10.1.3 系统分析与设计阶段
系统分析与设计包括系统概要设计和详细设计。
系统概要设计的工作内容包括：
（1）制定本阶段详细工作方案。内容包括进度安排、详细的工作（安排）分工、人员组成及人员资质说明等内容；
（2）制定概要设计标准和规范；
（3）严格按照概要设计标准和规范进行概要设计；在完成设计阶段的工作时，需准备系统设计原型，证明方案的可行性和可用性。
（4）概要设计结束阶段，提交《概要设计说明书》、《软件逻辑设计》、《系统结构设计》及相关文档，由客户方组织评审，评审通过由客户方签字认可后进入详细设计阶段。
系统分析设计的主要任务是根据需求分析的结果细化并构造系统，基于RUP的分析设计中，将其分为系统架构和用例的分析设计工作。最终的制品统称为系统设计模型。
系统架构设计：主要是进行系统的整体架构设计、接口设计、部署设计、关键技术问题解决方案等，从而产生稳定的系统架构；
系统详细设计：根据设计分解的子系统，进行系统的详细设计，主要包括界面、逻辑和控制的设计，并要进行O-R（对象-关系数据库）的转换及设计，最终提交的文档制品包括设计类图、交互图、界面设计、数据库设计等。
项目经理组织评审《概要设计说明书》，并填写《评审表》。《概要设计说明书》需要经过部门经理或和客户批准。
也可由实施部门经理或技术管理部评审《概要设计说明书》。
具体项目的概要设计评审，需要在《项目计划书》中约定。
评审通过后，提交《概要设计说明书》给技术管理部，并入库。
3.2.6.10.1.4 编码阶段
软件开发组长负责对开发人员工作进行分配，开发人员接收到需求规格说明书及系统设计资料后，即开始进行编码工作，同时负责所分配单元的测试工作。开发人员在工作中应遵守相关研发管理规范，每天工作结束时，应向项目经理提交任务完成进度信息，以便于项目管理者进行进度控制。
3.2.6.10.1.5 测试阶段
系统测试也需要有计划、设计、实施、报告几个过程。在系统分析和设计阶段，就要进行测试计划制定和测试用例的设计。系统测试实施的内容包括：关键单元的测试、集成测试、性能测试及联调测试，每个阶段完成后都要有相应的系统测试报告。
系统测试用例应在系统设计阶段同步设计，测试用例需要特别关注的内容是用例是否全面，因此在遵循公司相关的测试规范的基础上，应引入最终用户参与系统测试用例的设计工作，以保证测试用例的有效性。
3.2.6.10.1.6 试运行阶段
系统试运行在由用户指定的试点单位进行。乙方要做好试运行工作的组织保障、技术保障、资源保障、规范保障和流程保障。必须制定完备的试运行方案，确保试运行工作的成功实施。其中以下几点要重点考虑。
试运行培训：试运行期间的试点单位培训工作对用户掌握系统使用、系统尽早投入使用有重要意义。因此，要设计好试运行培训方案，成立培训组织机构，保障培训效果，扩大系统应用效果。
试运行保障：一定要制定好试运行保障方案，包括组织、技术、规范等。由试运行组织机构负责期间的技术支持服务，满足用户的使用需求；针对试运行过程的系统接口和功能完善问题，要及时完善改正。
3.3 项目风险管理
项目风险是指在项目管理活动或事件中消极的、项目管理人员不希望的后果发生的潜在可能性。风险管理目标包括早期识别潜在问题；确定并采取适当的行动措施以防范这些问题的发生、确保风险及其应对措施得到持续的监控和评估。项目风险管理是对项目风险从识别到分析到应对措施的一个过程，包括制定风险管理计划、风险识别、风险分析、风险应对、风险跟踪与控制五个方面。
本项目系统涉及面广，业务关联繁杂，如果不进行详细的风险分析和预估识别，将面临很大问题，因此，我们对本项目进行了独立的风险分析，并制定了具体的应对方案。
本章节方案主要从风险控制的理论、方法和技术方面进行阐述。具体内容如下。
3.3.1 项目风险识别
由于项目的一次性和特殊性，在风险判别中无法根据历史数据或资料对项目风险做出准确估计，只能靠专家或决策人员根据自身经验和知识对项目风险做出主观估计，特别是在项目立项论证或研制的初期阶段更是如此。为对项目风险进行准确判别，有必要规定统一的级别描述标准。技术风险、费用风险、进度风险、管理风险的级别描述分别如下表所示。
3.3.1.1 技术风险级别描述
技术风险 风险级别
成熟性 现有的或局部重新设计 低风险
主要部分重新设计，但技术可行 中等风险
技术可行的复杂设计或最新技术，某些研究已完成 高风险
复杂性 简单设计或局部增加复杂性 低风险
复杂性有中等程度增加 中等风险
复杂性显著增加或极其复杂 高风险
相关性 与现有系统、设施或相关的研制单位无关或进度取决于现有的系统设施或相关的研制单位 低风险
性能取决于现有系统性能、设施或相关的研制单位 中等风险
进度取决于新系统的进度、设施或相关的研制单位或性能取决于新系统的性能、设施或相关的研制单位 高风险
3.3.1.2 费用风险级别描述
费用风险 风险级别
任务要求明确性 任务要求明确，使用方和承制方对任务有共同的理解 低风险
任务要求基本明确，某些细节上尚需进一步确定 中等风险
任务要求不明确，使用方可能不断提出新的要求或双方对任务要求有不同的理解 高风险
技术风险影响 无高风险项目，中等风险项目不超过2个 低风险
无高风险项目，中等风险项目超过3个 中等风险
有1个以上的高风险项目 高风险
进度风险影响 无高风险项目，中等风险的进度指标不超过2个 低风险
无高风险项目，但中等风险项目在3个以上 中等风险
有1个以上的高风险项目 高风险
成本预算准确性 有充分的类似项目的历史数据可供参考，成本估算部门有足够可用的合格人员 低风险
有足够可用的合格人员但仅有部分历史数据可供参考 中等风险
缺乏可用的合格人员且无类似项目的历史数据供参考 高风险
3.3.1.3 进度风险级别描述
进度风险 风险级别
技术风险影响 无高风险，中等风险项目不超过2个 低风险
无高风险，中等风险项目超过3个 中等风险
有1个以上的高风险项目 高风险
计划安排合理性 计划切实可行且留有一定时间宽裕度以防意外情况发生 低风险
计划可靠，但对意外发生的问题未留有宽裕度 中等风险
计划不可靠，不是根据每项研制工作的实际需要来安排时间，而是根据竞争的需要或上级命令来分配时间 高风险
资源充分性 资源充足且可供使用 低风险
现有资源充足，但与其它项目之间有潜在的矛盾冲突，可能因某些预想不到的问题而影响进度 中等风险
现有资源不足或与其它项目之间存在严重的潜在冲突 高风险
项目人员经验 参与该项目的人员在类似的项目中已积累了经验，有足够的知识储备可用于该项目 低风险
参与人员在类似的项目中已有一般性的经验，但在某些关键部门还缺乏有经验的人员 中等风险
参与人员[普遍没有在类似项目中工作的经验，关键部门可用的有经验人员很少 高风险
3.3.1.4 管理风险级别描述
管理风险 风险级别
领导素质影响 领导者决策能力强，很有威望 低风险
领导者决策能力较强，威望一般 中等风险
领导者决策能力一般，同时也没什么威望 高风险
组织机构影响 组织机构健全，各机构间配合密切、融洽，运作效率高 低风险
组织机构基本完善，运作效率一般 中等风险
组织机构不完善，或虽完善但运作效率很低 高风险
计划条理性 计划安排很有条理，且在关键项目上态度较为保守 低风险
计划安排有序，但在计划安排上态度较激进 中等风险
计划安排没条理，或一般但态度很激进（冒险型） 高风险
研发人员素质 研发人员整体素质高，且人员之间协作能力强 低风险
研发人员整体素质较高，但人员之间协作能力一般 中等风险
人员整体素质一般，协作能力也一般 高风险
研发实力及条件 实力雄厚、条件优越且得到大家一致公认 低风险
实力和条件较好，能胜任项目的研究 中等风险
实力和条件一般，基本能胜任项目研究工作 高风险
各阶段的协调 协调能力强，能作好各阶段的协调工作，应付突发事件能力强 低风险
协调能力较强，正常情况下能保证各阶段的协调一致，应付突发事件的能力一般 中等风险
协调能力一般，应付突发事件的能力差 高风险
3.3.1.5 海外项目风险识别及应对
海外项目风险管理涉及多个复杂因素，需要综合考虑政治、经济、文化、法律等方面的风险。
政治风险：包括政策变化、政治不稳定等
政治风险评估：在项目启动之前，进行细致的政治风险评估。了解目标国家的政治体系、政策环境、法律法规以及政府的稳定性，以便更好地预测和评估可能的政治风险。
建立政府关系：与目标国家的政府建立良好的关系是管理政治风险的重要方面。寻找合适的合作伙伴或当地顾问，与当地政府进行沟通和合作，了解相关政策和法规。
多元化投资：分散项目的地理风险，通过在多个国家和地区开展业务，减少对单一国家的依赖，从而降低政治风险对整体业务的冲击。
持续监测和预警：建立有效的监测机制，密切关注目标国家的政治动态。与当地合作伙伴、咨询公司或政府机构保持紧密联系，及时了解政治变化，并及时采取相应的应对措施。
应急计划和风险对策：制定详细的应急计划，包括灵活的决策机制、紧急撤离计划等。同时，制定政治风险管理策略，例如购买政治风险保险、采取合适的合同条款等，以减少潜在损失。
经济风险：包括汇率波动、通货膨胀、市场萎缩等。
汇率风险管理：汇率波动可能对项目的成本和收益产生重大影响。您可以采取以下措施来管理汇率风险：使用金融衍生品如远期合约或期权进行汇率对冲，与银行合作制定有效的外汇管理策略。
国际市场分析：对目标国家的经济状况、市场趋势、竞争态势进行深入分析。了解消费者需求、市场规模以及潜在的经济增长机会，有助于更好地评估项目的可行性和潜在风险。
多元化供应链：依赖单一供应商或市场可能会增加风险。建立多个供应商和合作伙伴的关系，以确保供应链的稳定性和灵活性。这样可以减少供应中断的风险，并在价格波动时寻找替代方案。
资金管理：合理规划和管理项目的资金流动。制定预算和财务计划，确保资金充足，并及时跟踪和分析资金的使用情况。如果需要，可以考虑与当地金融机构合作，以便在需要时获得资金支持。
建立风险储备：为项目设立适当的风险储备。这样可以应对不可预测的经济变化和突发事件，减轻其对项目的影响。
文化风险：包括语言障碍、文化差异带来的沟通困难等。
跨文化培训：为参与跨国项目的员工提供跨文化培训，使他们了解目标国家的文化、价值观和商务习俗。这有助于减少误解和冲突，并提高团队在多元文化环境中的协作效率。
适应当地文化：尊重和理解当地文化是非常重要的。在项目执行过程中，避免触犯当地文化禁忌，尊重当地习俗和传统，有助于建立良好的合作关系，并赢得当地员工和利益相关者的支持。
灵活性和包容性：在项目规划和执行中考虑到不同文化的差异，保持灵活性和包容性。例如，在制定时间表和工作方式时，考虑到当地的节假日和工作习惯，以便更好地与当地团队协作。
多语言沟通：确保有效的多语言沟通渠道，以消除语言障碍。使用当地语言进行沟通，或者提供翻译服务，有助于建立良好的沟通和理解，避免信息失真和误解。
文化中介和顾问：在需要时，寻求专业的文化中介或跨文化顾问的帮助。他们可以为项目团队提供宝贵的文化洞察和建议，帮助解决跨文化沟通和合作中的问题。
法律风险：包括合同纠纷、知识产权保护等。
良好的合同管理：确保与项目相关的所有合同都经过仔细审查和谈判，并由专业律师审查。合同中应明确定义各方的责任和义务，包括支付条件、违约责任、法律适用和争议解决条款等。
遵守当地法律法规：了解并遵守目标国家的法律法规是非常重要的。这可能涉及到公司注册、税务、劳动法、知识产权和环境法规等方面。寻求当地法律顾问的帮助，以确保项目的合法性和合规性。
跨国合规团队：建立跨国合规团队，负责监督项目在各个国家的合规情况。该团队可以为项目成员提供相关培训和指导，确保他们了解并遵守适用的法律要求。
风险评估：对潜在的法律风险进行全面的评估和监控。这可能涉及到识别可能触犯法律的行为，比如反垄断法、贿赂行为或者知识产权侵权等，以及采取相应的预防和纠正措施。
争端解决机制：在合同中明确约定争端解决的机制，可以是仲裁、法院管辖或其他方式。了解目标国家的司法体系和仲裁规则，并选择最适合项目的争端解决方式。
3.3.2 项目风险分析
尽早进行风险分析，能够减少项目实行过程中的不确定性。它不仅使各层次的项目管理者建立风险意识，重视风险问题，防范于未然，而且在各个阶段、各个方面实施有效的风险控制，形成一个前后连贯的管理过程。 作为面对项目风险的有效手段，全面风险管理强调风险的事先分析与评价，风险因素分析是确定一个项目的风险范围，并将这些风险因素逐一列出以作为全面风险管理的对象。罗列风险因素通常要从多角度、多方位进行，形成对项目系统的全方位的透视，风险因素的分析可以采用以下方面进行分析：
尽早进行风险分析，能够减少项目实行过程中的不确定性。它不仅使各层次的项目管理者建立风险意识，重视风险问题，防范于未然，而且在各个阶段、各个方面实施有效的风险控制，形成一个前后连贯的管理过程。 作为面对项目风险的有效手段，全面风险管理强调风险的事先分析与评价，风险因素分析是确定一个项目的风险范围，并将这些风险因素逐一列出以作为全面风险管理的对象。罗列风险因素通常要从多角度、多方位进行，形成对项目系统的全方位的透视，风险因素的分析可以采用以下方面进行分析：
1、首先，按项目系统要素进行分析。这主要有四个方面的系统要素风险：
项目环境要素风险，最常见的有政治风险、法律风险、经济风险、自然条件、社会风险等；
项目系统结构风险，如以项目单元为分析对象，在实施以及运行的过程中可能遇到的技术问题，人工、材料、机械、费用消耗的增加等各种障碍和异常情况等；这是IT项目中最主要的风险。
项目的行为主体产生的风险，如供应商技术及管理能力不足，不能保证安全质量，无法按时交工等产生的风险；项目管理者的能力、职业道德、公正性差等产生的风险；
其他方面的风险，如外围主体（政府部门、相关单位）等产生的风险。
2、其次，按风险对目标的影响分析。这是按照项目的目标系统结构进行分析的，它体现的是风险作用的结果，它包括以下几个方面的风险：
工期风险，如造成局部的（工程活动、分项工程）或整个工程的工期延长，不能及时投产；
费用风险，这包括财务风险、成本超支、投资追加、报价风险、收入减少等；
质量风险，这包括工程等不能通过验收，工程试生产不合格、经过评价工程质量未达到标准或要求；
生产能力风险，项目建成后达不到设计生产能力；
市场风险，工程建成后达不到预期的经济目标，没有竞争力；
法律责任风险，可能因此被起诉或承担相关法律的或合同的责任。
3、再次，按管理的过程和要素分析。这个分析包括极其复杂的内容，但也常常是分析风险责任的主要依据，它主要包括：
高层战略风险，如指导方针战略思想可能有错误而造成项目总体目标设计的错误等；
环境调查和预测的风险；
决策风险，如错误的选择等；
项目策划风险；
技术设计风险；
计划风险，如目标的错误理解，方案错误等；
实施控制中的风险，如合同、供应、工程管理失误等方面的风险；
从总体上可以将该项目的风险分为宏观和微观两部分，宏观方面的风险指针对该项目的特点而使项目的实施具有的风险，微观风险则指在软件开发过程中会出现的风险。
3.3.3 项目风险监控
3.3.3.1 风险再评估
风险控制经常需要识别新风险，对现有风险进行再评估以及删去已过时的风险。应该定期进行项目风险再评估。反复进行再评估的次数和详细水平，应该根据相对于项目目标的项目进展情况而定。
3.3.3.2 风险审计
通过风险审计，检查并记录风险应对措施在处理已识别风险及其根源方面的有效性，以及风险管理过程的有效性。项目经理要确保按项目风险管理计划所规定的频率来实施风险审计。既可以在日常的项目审查会中进行风险审计，也可单独召开风险审计会议。在实施审计前，要明确定义审计的格式和目标。
3.3.3.3 偏差和趋势分析
很多控制过程都会借助偏差分析来比较计划结果与实际结果。为了监控风险事件，应该利用绩效信息对项目执行的趋势进行审查。可使用挣值分析以及项目偏差与趋势分析的其他方法，对项目总体绩效进行监控。这些分析的结果可以揭示项目在完成时可能偏离成本和进度目标的程度。与基准计划的偏差，可能表明威胁或机会的潜在影响。
3.3.3.4 技术绩效测量
技术绩效测量是把项目执行期间所取得的技术成果与项目管理计划所要求的技术成果进行比较。它要求对技术绩效的量化测量指标进行定义，以便据此比较实际结果与计划要求。这些技术绩效测量指标可包括重量、处理时间、缺陷数量和存储容量等。偏差值（如在某里程碑时点，实现了比计划更多或更少的功能）有助于预测项目范围方面的成功程度，还能揭示项目面临的技术风险程度。
3.3.3.5 储备分析
在项目实施过程中，可能发生一些对预算或进度应急储备有积极或消极影响的风险。储备分析是指在项目的任何时点比较剩余应急储备与剩余风险量，从而确定剩余储备是否仍然合理。
3.3.3.6 状态审查会
项目风险管理应该是定期状态审查会中的一项议程。该议程所占用的会议时间长短取决于已识别的风险及其优先级和应对难度。越经常开展风险管理，风险管理就会变得越容易。经常讨论风险，可以促使人们识别风险和机会。
3.4 项目进度管理
由于项目规模大，建设内容之间存在这样那样的内在联系，这就导致各项建设任务之间存在的复杂的依赖关系，如果在安排详细项目进度计划时缺乏整体考虑将导致整体工程延期等问题。
即使项目开始时编制了精美的计划，但在类似项目中往往业主对项目进度没有清晰直观的认识。
为解决这些与时间进度相关的种种问题，我们计划在项目实施中采用以下的进度管理方案。
3.4.1 项目进度安排
采用科学合理的方法确定进度目标，编制进度计划和资源供应计划，在与质量、费用目标协调的基础上，实现工期目标。
项目组将在中标通知书下达后尽快向客户方提供详细、可行的实施方案，包括制定项目里程碑和进度计划，并做好项目实施的准备工作。项目进度要求以合同约定为准。
3.4.2 项目进度跟踪
在项目的实施过程中，还要对项目的实施情况进行跟踪，确保项目的实施符合计划的要求。跟踪的方法可分为正规跟踪和非正规跟踪，正规跟踪就是定期召开项目进展情况汇报会、提交项目进展报告等，从而使项目利益相关者了解项目的执行情况。根据进展报告，与会者讨论项目遇到的问题，分析并找出问题的原因，研究、确定应对方案和预防措施，为控制项目提供依据。
非正规跟踪则是项目经理频繁地到项目现场，通过观察、与现场人员交谈、收集数据等方式了解情况，发现问题。在项目管理过程中，非正规跟踪比正规跟踪更加有效，原因是：
1、了解的情况真实、及时；
2、缩小了项目经理与现场成员之间的距离，使之关系更融洽，问题更易解决；
3、现场的执行人员更容易沟通；
4、项目经理更能亲身体会现场的工作气氛，掌握团队的士气；
5、更容易获取解决问题的答案；
项目任务进度的度量：首先把每项工作分解到工期在一周以内，每周末进行进度评估，我们采取工时提交原则，即提交工作任务的完成工时。
项目进度信息采集的方式：项目周报、项目例会、阶段性评审。
1、项目周报：就是项目实施小组每周向项目经理提交每周的工作汇报，包括存在问题。
2、项目例会：就是项目组定期举行工作会议，分析项目状态，落实下一步工作，其中包括对现有的问题进行讨论并解决。
3、阶段性评审：就是在项目的阶段最后，召开项目小组成员、项目指导委员会、外部项目质量保证等人员对项目的阶段工作进行评审，包括进度、交付物的质量、阶段里程碑、项目中的重大问题、项目风险、分析项目中的好的方法等。
3.4.3 项目进度分析
挣值法：这种方法提供了三个数据来跟踪项目的执行情况：计划做什么、实际做什么、以及做完的工作花了多少费用？这种方法交计划需完成的工作同实际已完成的工作进行比较，确定项目在费用支出与时间进度方面是否符合原计划的要求，从而跟踪项目执行的好坏。
3.4.4 项目进度控制
项目计划只是根据预测而对未来做出的安排，由于在编制计划时事先难以预见的问题很多，在计划执行过程中往往会发生或大或小的偏差，这就要求项目经理及其他管理人员对计划做出调整，消除与计划不符的偏差，以使预定目标按时和在预算范围内得以实现。
项目计划的控制就是要经常对每项工作进度进行监督，然后，对那些出现”偏差”的工作采取必要措施，以保证项目按照原定计划进度执行，使预定目标按时和在预算范围内实现。
按照不同管理层次对进度控制的要求分为三类：
1、项目总进度控制：项目指导委员会对项目中各里程碑事件的进度控制。
2、项目主进度控制：项目经理针对项目进度计划中的关键路径进行控制，保证总进度的如期完成。
3、项目详细进度控制：主要是各作业部门对各具体作业进度计划的控制。这是进度控制的基础，只有详细进度得到较强的控制才能保证主进度的按计划进行，最终保证项目总进度，使项目目标得以顺利实现。
进度控制的依据主要有：项目进度表、项目进展报告、变更请求等。
项目进度的控制方法如下：
1、把能力强的成员放在关键路径的工作上，把新手放在时差大，不重要的工作上；
2、赶工期，包括通过加班加点来缩短关键路径上单项任务的持续时间；调整关键路径上活动之间的逻辑关系，变FS为SS等；
3、重新谈判，即与项目利益相关者讨论增加预算或者延长时间基线；
4、缩小项目范围，以便减少费用、节省时间；
5、投入更多的资源，看看可否增加人力、设备到工作中？这需要平衡费用与进度孰重孰轻；
6、接受替补方案，看看能否制定一个更省钱、更现实的方案；
7、寻求其他资源；
8、接受部分交付物，看看能否先接受部分交付物，使项目能继续进行；
9、提供奖金，看看能否提供奖金或其他激励措施，促使按时完成任务；
进度控制的结果包括：项目时间表更新、补救的行动、经验教训。
3.4.5 里程碑控制
里程碑是项目中的重大事件或时间点，对里程碑点进行全面的评估，组织专业的评审，偏差控制，与项目初期的计划进行比较，及时发现和诊断项目在进度、质量方面的风险和问题。里程碑管理主要内容包括：
1、里程碑计划评审：项目管理组和其他职能组对项目初始阶段制定的里程碑计划进行评审，审核通过的里程碑计划需提交工程办审批，对于重点项目还需局领导审批。
2、里程碑进度跟踪：项目管理组监控各项目里程碑进度，掌握项目整体进度情况，并对各项目里程碑的执行情况进行偏差分析，形成里程碑监控报告，并在工程例会向工程办领导汇报。
3、里程碑交付物评审：项目里程碑完成时，要组织项目里程碑交付物评审会，对项目里程碑交付物进行评审，重要项目里程碑交付物必须邀请外部专家进行外部评审。
4、里程碑总结评审：工程办和各职能组在工程例会上，对项目前一阶段的管理工作及里程碑总结进行评审，对项目下阶段里程碑管理工作给予指导，并确定项目下一阶段的里程碑计划。
所有软件开发项目的主里程碑都应执行里程碑阶段评审，评审一定要以会议的形式，并且项目主管必须参加。一般由项目经理主持。
里程碑阶段评审应该达到以下目标：
1、评审项目本阶段发布的所有产品，评审的目的不是生成产品评审通过的评审记录，而是评审产品是否能实现项目目标；
2、评审项目的进度、成本、人力状态和技术状态；
3、评审项目的风险管理状态；
4、评审项目当前的和已规划的商业需求、客户需求、最终用户的需求是否能够满足；
里程碑评审的结论应该是项目已达到本阶段的目标。如果项目还没有达到阶段性目标，则应该制定相应措施来消除缺陷，并进行跟踪直至缺陷消除。里程碑评审应记录会议纪要，并记录缺陷修订措施，其中问题应该记录到问题跟踪表。
3.5 项目文档管理
项目文档控制管理主要分为两部分，一是对项目过程中所使用和产生的文档的管理；二是对项目成果文档及交付物的管理。
对项目过程文档的管理遵循软件开发能力成熟度模型及相关项目管理规范进行规范的版本控制、发布等流程。
3.5.1 项目过程文档版本控制及发布方案
版本控制是软件工程中最常用的技巧之一，以在开发和使用的过程中，确保由不同人所编辑的同一软件或文档都得到统一的更新。
3.5.2 版本管理流程
版本管理是指工程实施过程中对各项目产生的交付物的变化过程进行跟踪、记录和控制，交付物包括软件本身和软件相关的各种文档；通过版本管理，可以完整地重现软件和文档在历次修改之前的状态，执行差异分析，撤销错误的修改，支持开发团队的协同工作。
版本管理分为项目组的版本管理和跨项目的版本管理。版本管理的主要工作包括：
1、协助工程办建立跨项目软件版本和文档版本管理流程，协调各项目的开发进度，保证工程整体进度。
2、应用系统开发项目在开发过程中要进行软件版本发布，充分考虑项目之间软件版本的关联性，及时进行跨项目协调，保证整个信息系统生产环境的稳定运行。
针对软件开发项目不同阶段的工作特点，提出了开发版本和测试版本两套软件版本管理流程。
1、开发阶段软件版本控制
在开发阶段执行每日构建，即每天进行一次全系统的编译，以编译通过的源程序作为当天的开发版本。
具体流程如下图所示：
注：开发人员每日上午及时查收邮件。开发人员每日提交最新的开发成果，一定要保证已经在本地编译通过。
对于开发人员，通过版本控制工具更新程序和提交程序时，执行流程如下图所示：
2、测试阶段软件版本控制
在测试阶段，由专人对测试环境进行维护与更新。测试组将基于定期发布的最新测试版本通知进行测试工作。
3.5.3 版本标识及版本控制
如果客户方有明确的软件版本标识规范和文档命名方法，我们提交给客户的软件及文档都遵循客户的相关规定。
下面是配置项命名和版本号演变的一个参考方案，在具体实施中会进行细化和具体化
1、项目名称
项目名称：客户名称_项目简称
项目简称：合同名称简化
项目代号：英文缩写（便于加在文档名称中）
2、版本演变
说明：采取2位或3位的形式：VX.Y，VX.Y.Z 。
V 是版本标识；
X 是主版本号
Z 是Release版本号
3、文档标识
（1）纳入基线前的命名规则：
<项目代号>_<文档名称>_YYYYMMDD；
（2）纳入基线的命名规则：
<项目代号>_<文档名称><版本号>。
4、文档版本控制
软件有版本的区别，文档也一样。对于每一份文档的版本号管理，以下面的规则为准：
（1）版本号分总号与子号，例如V1.0，其中的1为总号，0为子号。
（2）创建文档时为V1.0版 ；
（3）在未经客户方审阅前的内部审阅和修改，版本总号不变、子号递增，如：V1.1、V1.2；
（4）经项目经理或客户方的审阅或修改后，则版本号升级，如：V2.0；
（5）当文档最终确定后，统一提交项目经理或文档管理员存档，若需要修改须通过变更流程。
3.5.4 项目成果文档和交付物管理
本项目成果和交付物按阶段提交，具体各阶段主要成果和交付物如下表所示：
项目验收时提交成果物内容全面包括软件包、程序源代码、开发文档、管理文档、用户文档、上线文档、记录文档、反馈文档等，包括纸质及电子版本。
3.6 项目代码管理
项目代码管理是指对项目中的代码进行统一的管理、版本控制和协作。它可以帮助团队成员更好地协同开发，保证代码的质量和稳定性，提高开发效率。
常见的项目代码管理工具有Git、SVN等。这些工具可以帮助团队成员将代码存储在一个中央仓库中，并对代码进行版本控制。团队成员可以通过这些工具进行代码的拉取、提交、合并等操作，保证代码的一致性和可追溯性。
在项目代码管理中，通常会使用分支管理策略。团队成员可以基于主分支创建自己的开发分支，在开发分支上进行代码修改和功能开发。当功能开发完成后，可以将开发分支合并到主分支中。这样可以保证团队成员之间的工作不会相互影响，同时也可以方便地进行代码审查和测试。
另外，项目代码管理还可以结合代码质量管理工具，对代码进行静态分析、自动化测试等操作，以保证代码的质量和稳定性。
总的来说，项目代码管理是项目开发过程中非常重要的一环，它可以帮助团队成员更好地协作开发、保证代码的质量和稳定性，提高开发效率。
3.7 项目变更管理
项目变更管理是指在项目执行过程中，对项目范围、进度、成本、质量等方面的变更进行管理和控制的过程。它旨在确保项目变更得到有效管理，以最小化对项目目标的影响，并确保变更的合理性和可控性。
项目变更管理包括以下几个方面：
变更识别和请求：在项目执行过程中，团队成员可能会发现项目需要进行变更，例如范围的调整、需求的修改等。这些变更需要被识别并记录下来，形成变更请求。
变更评估和分析：对变更请求进行评估和分析，包括评估变更对项目目标、范围、进度、成本、质量等方面的影响，分析变更的可行性和风险。
变更决策和批准：根据变更评估和分析的结果，项目管理团队需要做出决策，决定是否批准变更请求。如果批准，需要确定变更的实施方式和时间。
变更实施和控制：对批准的变更进行实施，并进行相应的控制和监督。这包括变更的规划、执行、跟踪和监控，确保变更按照计划和要求进行。
变更验证和确认：在变更实施后，需要进行验证和确认，确保变更达到预期的效果，并对变更的结果进行评估和记录。
变更沟通和交流：在整个变更管理过程中，需要进行及时的沟通和交流，确保项目团队和相关利益相关方对变更的情况有清晰的了解，并能够做出相应的决策和行动。
项目变更管理的目标是在项目执行过程中，对变更进行有效管理和控制，以确保项目目标的实现，并最小化对项目范围、进度、成本、质量等方面的不利影响。
项目变更流程如下：
3.8 信息安全管理
保密域信息安全管理是指对保密域内的信息进行安全管理和保护的一系列措施和实践。保密域是指一个组织或机构内部的特定区域，其中包含了敏感和机密的信息，需要进行特殊的保护和管理。
保密域信息安全管理的目标是确保保密域内的信息不被未经授权的人员访问、泄露或篡改，并保证信息的完整性、可用性和可靠性。
以下是保密域信息安全管理的一些常见措施和实践：
访问控制：建立严格的访问控制机制，限制只有授权人员才能访问保密域内的信息。这可以通过身份验证、权限管理、访问审计等方式来实现。
数据加密：对保密域内的敏感信息进行加密处理，确保即使数据被窃取或泄露，也无法被未经授权的人员解读。
安全审计：建立安全审计机制，对保密域内的信息访问和操作进行记录和监控，及时发现和应对异常行为。
物理安全：对保密域的物理环境进行安全管理，包括安全门禁、视频监控、防火墙等措施，防止未经授权的人员进入保密区域。
员工培训和意识提升：加强对员工的信息安全培训，提高他们的安全意识和对保密信息的保护意识，防止因员工的疏忽或错误导致信息泄露。
安全漏洞管理：及时监测和修复保密域内的安全漏洞，确保系统和应用程序的安全性。
灾备和备份：建立完备的灾备和备份机制，确保保密域内的信息在灾难事件或数据丢失时能够及时恢复和恢复。
合规性管理：遵守相关的法律法规和行业标准，确保保密域信息安全管理符合法律和规定的要求。
综上所述，保密域信息安全管理是对保密域内的信息进行安全管理和保护的一系列措施和实践，旨在确保信息的机密性、完整性和可用性。通过合理的安全措施和实践，可以有效防止信息泄露和损害，保护组织的利益和声誉。
3.9 项目沟通管理
3.9.1 沟通管理方案
项目实施是一个团队任务，信息不畅容易导致工作偏离目标，或者是成员之间产生误解。项目实施过程中，我方将通过建立制度化的沟通渠道等方式，加强与业主和甲方（合称客户方）和监理方的沟通。
首先，遵守客户方项目管理相关规定，接受客户方项目管理机构和项目负责人的领导，接受项目监理方的监理，指定负责人与客户方和监理方保持沟通和协调。
其次，将建立项目例会制度，就项目进展情况、存在的问题、需要协调的主要事项、下一阶段工作计划等与客户方和监理方进行适时的沟通协调。
3.9.2 沟通汇报体系
沟通汇报体系是指通过建立适当的机制和流程，保证在工程涉及的范围内，将准确一致的信息在适当的时间、通过适当的渠道和工具传递给适当的对象，从而确保整个工程团队相关人员都能够及时了解工程目标、领导的指示、工程进展，并体验工程带来的工作环境改善和变化等。
主要工作包括：
1、制定清晰、一致、适时的沟通方法和计划；
2、按计划适时沟通，传递一致、清晰的信息；
3、获取沟通目标方的充分参与及反馈，取得工程全体人员的广泛支持；
4、根据本项目工程要求，设计不同形式的沟通方式，并定义恰当的沟通计划，有效实施沟通活动，包括：项目月报、项目进度状态报告、项目高层决策会议、专题讨论会、项目信息发布等。
3.9.3 沟通管理的主要过程
3.9.3.1沟通计划
沟通计划包括决定项目涉及人的信息和沟通需求：谁需要什么信息；什么时候需要；怎么获得。虽然所有的项目都需要沟通项目信息，但信息需求和传播方式差别很大。确认涉及人的信息需求和决定满足需求的适当方式是项目获得成功的重要因素。
项目实施过程中，沟通计划通常体现在项目计划和公司的管理规程中。
3.9.3.2 信息传播
信息发送是指将需要的信息及时地传送给项目涉及人，它包括实施沟通管理计划以及对突发的信息请求作出反应。发送者有责任使信息清晰、没有歧意和完整以便接收者能正确地接收。发送者也有责任确保信息被正确地理解。接收者有责任确保完整接收和正确地理解信息。沟通有很多类型：
书面的和口头的，耳听的和口讲的;
内部的（项目内）和外部的（与客户、媒体、公众的沟通）;
正式的（报告，指示等）和非正式的（备忘录，特别安排的谈话等）;
垂直的（组织内上下级之间）和水平的（与同级别之间）。
3.9.3.3 执行报告
执行报告包括收集和发布执行信息，从而向项目涉及人提供为达到项目目标如何使用资源的信息。执行报告一般应提供范围、进度、成本、质量等信息。许多执行报告也要提供风险和采购的信息。执行报告应写得具有综合性或针对某一特例。这样的过程有：
状况报告：描述项目当前的状况。
进展报告：描述项目小组已完成的工作。
预测报告：对未来项目的状况和进展作出预计。
项目实施过程中，执行报告的任务通常体现为小组周会、项目周报、项目月报等。
3.9.3.4 行政总结
项目或阶段在达到目标或因其他原因而终止后需要一个总结。行政总结包括对项目结果的鉴定和记录，以便由发起人、委托人或顾客正式接受项目的产品。行政总结包括项目记录的收集、确保项目记录反映最终的设计书、项目成功和效益的分析以及对此类信息的立卷以备将来之用。
行政总结在项目进行中不应被拖延，项目的每一阶段应以适当的方式结束，以确保重要和有用的信息不会被丢失。
项目实施过程中，行政总结的任务通常体现为里程碑总结、阶段总结或项目总结等。
3.9.4 沟通机制
项目组将建立工程管理各层之间的有效的沟通机制，通过多种渠道来规范各类信息在组织内部快速流转，对于保证工程建设进度，避免信息不通所造成的延误、浪费等问题至关重要。
在沟通机制方面有多种方式，如日报、周报、会议纪要、工作联系单、会议等多种方式，其中定期的会议制度至关重要。
会议制度方面，我们建议在工程管理组织内部的形成三种类型的会议机制。
三类会议的目的、参加人员和会议频率如下表所示：
其中工程运作会议是项目组内部最重要的会议类型，主要表现为项目周例会和项目定期汇报会。
3.9.4.1 项目周例会
（1）目的
完成情况，讨论下周任务安排，协调项目问题。
（2）主要内容
项目状态检查及进度跟踪；
当周重要事项的汇报；
下周详细工作计划；
变更请求状态检查；
近期需提交的提交件状态检查；
项目成员工作情况检查。
（3）会议时间
属定期会议。
（4）与会人员
项目经理，有关领导，各组长。
（5）会议结果
会议纪要。
3.9.4.2 项目定期汇报会
（1）目的
向有关领导汇报项目达到的主要里程碑情况，或重要情况单项汇报。
（2）主要内容
项目的进展时间；
项目的完成进度；
项目的成本控制情况；
项目的完成质量；
下一阶段详细的工作计划。
（3）会议时间
重要阶段或重要事件需要汇报时，属不定期会议。
（4）与会人员
项目经理，有关领导，各组长。
（5）会议结果
会议纪要。
4 项目计划及相关资源投入
4.1 项目实施总体计划
项目启动后，将通过6个月来建设项目，质保期为六个月，其中包含三个月上线支持。
项目的总体计划
4.2 项目交付物清单
4.3 项目组织结构与职责
服务商 项目成员角色与职责
服务商 项目指导委员会 – 项目总监（服务商 Project Executive):
代表服务商参加指导委员会月会
确保项目资源
提供项目指导
解决关键问题
服务商 质量管理组 – 质量管理总监(QA，Quality Assurance Director):
协助项目品质保证计划执行
于项目进行中，审视项目过程于阶段性结果，并作评估
对所评估的内容提出建设性的改进意见
服务商 专家支持组:
交流、共享全球领先企业的先进经验
提供项目所需的各领域的专业技能
为项目组提供必要的专业培训
借助质量保证专家对项目的重要阶段成果进行检查和建议
服务商 项目经理:
与甲方项目经理共同执行：
检视双方在工作说明书及契约上的责任
准备一份高阶项目计划去确认与指派工作、项目的里程碑及估计工作完成的时程
管理详细项目计划与高层项目计划的准备
与甲方项目经理检视项目计划
协助甲方项目经理执行：
针对项目计划作衡量、追踪及评估进度
项目偏离修正
检视项目工作、时间表与资源，并在适当时机作改变或增加
进行进度会议，与项目小组共同检视项目进程
在每周进度会议中检视项目进程
维持项目沟通
协助项目文件纪录及程序标准的建立、协调与管理
检视及协助项目变更控制程序的管理
协助并协调与管理项目成员所需执行的技术性工作
准备及提交每月进度报告
检视项目小组的工作成果
服务商 业务功能组 – 业务设计顾问
进行分析需求的调研
在梳理甲方业务管理指标的基础上，进行指标体系的设计
服务商 数据建模组 – 数据建模顾问:
进行现况分析。
了解各级管理层的分析需求
定义需求分析字典
进行数据模型设计
进行分析应用设计
发掘管理问题并提出解决方案。
服务商 数据应用组 – 前端展示顾问
分析报表展示设计
指标展示设计
展示报表的定制与实现
关键绩效指标的定制与实现
4.4 项目人员配置
见附件人员名单。
5 用户培训及知识转移
5.1 知识转移的定义
知识转移是指建立起技能传授、学习和知识管理的体制，将我们在流程改进,系统实施和项目管理方面的知识、技能和方法传递给甲方，为甲方培养一批掌握系统应用、开发技能的复合型管理人才，使其具备自行推广和后续自我支持能力。
5.1.1 知识转移的目标
知识转移目标是：
保证通用流程、系统核心功能及其它知识能以统一的标准有效地传授到试点实施的实施小组及相关人员。
培养甲方的关键用户，使其掌握的核心功能以及项目实施方法和步骤，具备配合实施顾问推进项目的能力
培养甲方的IT人员，使其掌握日常运行和维护系统的技能，包括故障排除、寻求它方支持等
培训甲方的最终用户，确保新流程和系统功能的知识转移，使其能从上线的第一天开始正确地、高效地使用系统。确保员工对总体流程和系统的集成性有大致的理解。提供有效的、全面的和标准的文档给最终用户，成为其后续稳定应用的保障。
5.1.2 项目知识转移概述
甲方作为一个大型企业，业务据分析在全企业内的拓展和完善是一个长期的过程，不能长期完全依靠外部的实施力量，我们建议甲方通过本项目能培养起企业自己的数据分析队伍，逐步负责后继的系统支持，完善及在其他子公司的扩展工作。因此，在本次项目中，我们将特别注重知识的转移（从咨询公司顾问到甲方人员），不但使甲方能培养起一支自己的系统支持和扩展队伍，而且使甲方对业务流程优化，变革管理，项目管理，项目风险控制能力有较大的提高：
在项目实施过程中，咨询公司专家及顾问将为管理人员和业务人员提供多层次的循序渐进的培训(实施方法论及项目管理、数据分析方法论、数据架构设计、数据治理服务流程设计、大数据开发、系统维护、系统二次开发等培训)。
项目实施过程中，咨询公司顾问将与甲方人员一起对业务流程、系统操作进行规范化，并按照咨询公司的标准制作成高标准的文档，这一点对于甲方将来的管理规范化标准化、新员工培训等有非常重要的意义。
在项目实施过程中，咨询公司将派驻全职的顾问与甲方人员紧密合作，展开一系列的流程改进研讨会、流程评审会、测试讨论会等，我们认为手把手的工作方式是最佳的培训过程。
5.1.3 知识转移的方法
为保证在短期内将各种知识和技能传授给不同层面的众多项目参与者，我们建议在项目管理层成立技能转移专项小组，专职负责策划和实施各种培训并衡量其有效性。技能转移专项小组将由联合实施小组专职顾问和甲方的实施骨干共同组成，专职为试点的实施小组和相关人员提供培训。为确保成功的技能转移，我们将采用如下几种方式：
课堂培训
针对各种专题开设培训课程，如项目管理、实施方法及系统核心功能等，通常安排在相关任务开始之初，以使各参与人员能具备完成相关任务的基本技能。
在职培训
通过课堂培训所获得的基础知识需经过实际工作中的不断应用和反复锤炼才能被充分吸收，并达到可举一反三、熟练应用的境界。咨询顾问顾问将通过联合工作的方式，协助甲方的用户解决实际应用中的问题，不断深化所学的知识。此种方式可适用于联合项目管理、系统开发等日常工作。
交付文档
项目实施过程中交付的一系列文档也是技能转移必不可少的媒体。这些文档可作为日后进一步培训、推广或联合工作小组的重要参考。为确保项目成果存档，并为今后甲方后续自我支持提供模板，在我们的咨询项目中应用广泛，并受到客户的普遍欢迎，它能充分支持项目实施过程中的经验、知识的共享，对于甲方这样范围广的大项目尤其适合。
讲座研讨
组织讨论会或讲座，由咨询顾问资深顾问通过讨论会等互动方式，与甲方管理层交论有关内部管理、流程等方面的内容。在项目进展中的各类研讨会有：
总体设计研讨会
业务流程改进和应用系统配置的研讨会
实施阶段的模板匹配研讨会
5.1.4 知识转移方案
项目进展过程中需要传授的主要知识和技能包括：
项目管理
项目管理的思想和方法将贯穿本项目实施过程的始终。咨询顾问综合了世界著名企业的案例和自身的实践经验，总结出一系列项目管理的方式和方法，从项目立项、可行性分析，到项目中的成本预算控制、变革管理、风险控制和防范，到项目成果的确认、审核，以及项目最终的总结和收获。我们不仅将这些原则和方法使用于本项目的实施过程，也愿意和甲方分享我们成功的经验。根据甲方的需要，咨询顾问还可以提供专门的项目管理的培训。
项目实施方法
咨询顾问将采用DCMM模型等实施方法来指导本项目的实施，同时结合甲方的具体特点，定制出甲方的实施方法，使之更有效地帮助甲方推广实施数据治理工作和其他应用系统数据治理改造工作，降低项目的总体成本，减少项目风险。
通过项目实施方法的培训和联合工作小组的方式，我们将把数据治理实施方法传授给甲方。
业务流程
基于系统的最佳实践流程，结合咨询顾问项目实施经验，我们将和甲方一起定义未来业务运作流程，规范业务、人事管理，通过系统实施来改进现状。确保实施后甲方具有自行支持业务运作、自行优化业务流程和运作的能力。
系统开发、技术
实施中，咨询顾问将帮助甲方进行需求定义、功能分析、设计开发等，向甲方转移实施范围内的技术手段和方法，使甲方具备自行开发的能力。
项目中咨询顾问针对甲方的经营情况开发的工作成果，包括有关工作文档，其知识产权属于甲方；涉及咨询顾问专有的创意、概念、方法和工具、包括信息技术和商业运作中的创意，其知识产权仍属咨询顾问方，不随其产生的成果产权转移而转移。
5.1.5 培训方案设计
5.1.5.1 培训方案设计思路
鉴于本次项目实施复杂性，培训课程的设计与交付需要分层级、全方位推进：横向细分不同层级对象，组织对各级人员进行分层次培训；纵向贯穿项目不同阶段，落实过程交付培训和宣贯；同时通过制定细致全面的培训课程，及提供国内外先进企业人力资源管理的培训或交流机会，有力地支持管理变革工作，支持和辅助领导有效地决策。本次项目知识转移方案设计思路如下：
制定培训计划，明确各阶段培训内容及对象：制定详细的培训计划，贯穿项目启动、方案设计、实施及试运营上线支持全过程；针对不同阶段的知识转移需求，明确培训的重点及接受对象。
针对不同对象，进行分层级培训：对于不同层级对象，制定有针对性的培训内容，以提高人力资源服务方案的普及度，加强方案的认可度。培训对象包括集团集团和项目涉及的各单位，覆盖人力资源部、信息化管理部、业务部门和其他核心职能部门等。
细致全面的培训内容，提供服务商增值培训：知识转移贯穿项目始终及未来运营期间，需要针对甲方的管理特点、文化特点以及协同关系等，确定培训内容并组织编写细化的培训手册。
5.1.5.2 培训设计原则
基于上述设计思路，培训方案的设计应遵循如下原则：
计划清晰详实：培训时间安排针对项目不同阶段，培训具体内容与方案设计、实施的进度保持一致，以配合业务开展与人力资源系统方案的逐步推广。
对象分级分类：针对集团集团、各单位不同层级、人力资源部、信息化管理部、业务部门及其他相关职能部门等不同职能人员，采用分层级的培训体系，逐层熟悉人力资源系统方案与运营方式，达到良好的培训效果。
内容全面细致：通过培训帮助受训人员理解及运用人力资源系统方案设计的具体内容，包括战略框架、业务流程、组织人员、标准体系及服务运营等，建立人力资源系统应用的全局观。
5.1.6 培训内容设计
5.1.6.1 培训主题
本次项目的培训主题主要包含项目方法与技术培训、数据服务培训及服务商增值培训三类，各类主题主要培训内容如下：
项目方法与技术培训：主要用于本次项目中使用的项目方法、工具、技术的培训，包括但不限于数据服务需求调研的方法论与工具、数据服务调研的方法论与工具、流程设计与研讨的方法论与工具、系统架构设计的方法论与工具等，涵盖项目设计的各个环节；
数据服务培训：主要用于数据服务方案，包括数据服务发展趋势、数据服务规划、先进企业人力资源数据服务案例等。
卓越运营：主要面向项目组关键用户、业务管理部的管理团队，包括卓越运营管理、服务运营管理、运营产能计划与分析等。
内部专题讨论会：组织项目关键决策层参与工作坊进行沉浸式的学习与研讨，并在过程中提供国际最新趋势及技术分享，助力甲方达成国内领先、国际先进业务源数据服务系统的核心目标。
5.1.6.2 培训内容
知识转移是项目成功的关键，只有内部人员和用户真正掌握了系统，项目才能成功，系统才能正常运行。培训是知识转移的桥梁，系统运行维护和改进不仅依赖于内部的运行和维护管理人员，而且与使用该系统的业务人员（即系统用户）也密切相关。因此，在上岗前后各类人员都应该接受相关培训，以使他们的知识和技能满足其岗位要求。
系统实施成功与否与所提供给企业管理层、关键用户及最终用户的成功培训息息相关。有效的培训及相关的训练是项目顺利进行的催化剂，是所有主要流程变革和系统成功实施的关键因素，同时也是知识转移的重要手段。
借鉴于其他同类型企业培训经验，以及本项目的特点，服务商建议项目在项目培训过程中将人员按以下目标听众群划分，并推荐相应的培训课程如下：
关键用户层（关键流程负责人）：使其掌握数据服务的建设项目的核心功能以及项目实施的方法和步骤，具备配合实施顾问推进项目的能力。此类培训对象既要了解软件工程的宏观概念，更要充分理解业务相关的具体模块的功能概况，从而在制定项目规划的进程中，与实施方共同定义项目蓝图，项目组将向他们详细介绍最佳业务实践理论和国内外类似项目的经验，以保持项目实施和解决方案的先进性。
技术骨干层（信息技术支持）：培养集团内部支持团队，使其掌握项目实施全过程和系统维护、二次开发的技能。与项目实施方共同工作，为后续长期独立支持企业内部项目实施和运维奠定基础。
最终用户培训：为使最终用户在系统上线的第一天即能正确地、高效地使用，并能向他们提供有效的、全面的、标准的文档，成为后续稳定应用系统的基础。
具体细化的培训内容及培训材料将在中标后与甲方做进一步商榷。
5.1.7 培训计划
基于上述培训内容，本次项目还将制定涵盖项目各个阶段培训计划，在项目各个阶段做好向项目组内部支持队伍的知识转移工作。各阶段的培训目标、讲师、对象和主要培训内容初步计划如下：
5.1.7.1 方案设计阶段
在方案设计阶段，项目组会形成数据服务平台实施方案。因此在培训安排上，建议按照实施及实施时间计划，在各单位业务迁移前完成培训，使培训对象尽快掌握方案细节，在方案迁移前提出意见与建议；同时，也要兼顾不同类型的单位情况，分不同批次完成方案的知识转移。该阶段培训目标、讲师、对象和主题如下：
培训目标：了解本项目中的关键方法与工具，以及数据服务实施方案，建立人力资源数据服务的全局观
培训讲师：方案设计工作组及服务商专家
培训对象：集团人力资源部门及其他相关职能部门、信息管理部、项目组关键用户
5.1.7.2 迁移准备与业务切换阶段
该阶段培训主要是在上线前培养各岗位知识储备及系统操作双重履岗能力。该阶段培训安排较为紧凑，建议以周为单位，进行系统化的培训，使培训对象达到系统上线实操要求。该阶段培训目标、讲师、对象和主题如下：
培训目标：明确实施迁移阶段注意事项，了解实施方案及时间安排，具备专业知识并逐步建立履岗能力，帮助迁移阶段平稳过渡
培训讲师：服务商实施工作组
培训对象：本次项目范围内单位人力资源部门及业务部门、管理层级、业务板块、区域中心、项目组关键用户
5.1.7.3 试运营阶段
该阶段培训主要是在上线后试运营期间开展，目的是进一步强化项目组对人力资源数据服务方案的理解与运用，尤其是服务运营管理方面的知识转移，形成持续提升的服务运营闭环管理机制。该阶段培训目标、讲师、对象和主题如下：
培训目标：强化数据服务业务规范的理解与运用，建立服务运营管理机制
培训讲师：服务商实施工作组、项目组关键用户
培训对象：人力资源部、信息化管理部、项目组关键用户
5.1.7.4 项目培训计划
基于上述不同项目阶段培训需求的分析，结合项目整体计划，服务商将为本次项目制定科学、可行、全面的培训计划，并在项目全过程按计划开展各项培训，具体时间计划将在中标后与甲方做进一步细化商榷。
6 售后服务方案
6.1 质保期后的技术服务
6.1.1 服务承诺和保障
本项目服务商承诺上线后提供两个月的现场运维服务。
服务商出色的服务支持能力源自于技术、流程和人员三者平衡的服务框架：
先进的技术：服务商将利用业界领先的技术和工具为甲方提供全面的IT环境管理服务。
主动严谨的管理流程：服务商的管理服务贯彻以预防为主的方针。主动的管理流程将风险降到最低。服务级别的管理将确保服务的高质量。
经验丰富的专业技术人员：服务商非常注重专业技术人员的学习和经验共享，通过不断的学习和团队工作以保证技术人员的专业水平和技能的提高。服务商具有多年IT管理经验和多厂商支持服务经验的专业技术人员将对服务提供强大的技术保证。
6.1.2 服务整体交付模式
服务商将通过以远程顾问为主、按需派遣现场顾问相结合的方式为甲方速赢项目用户提供所要求的质保服务。
安排现场顾问在现场可以方便的和甲方客户进行面对面的及时沟通，更加透彻的理解客户需求，探讨各类问题的解决方案，以便发现更佳的解决方案。同时服务商的远程服务团队可以充分利用服务商全国和全球的服务资源和经验，同现场顾问一起迅速解决问题，同时也可以大大降低运维支持服务的成本。这种混合资源的模式，可以取得最佳成本收益比。
2－5年运行支持的顾问的现场支持费用应由甲方另行支付，该费用根据实际发生的原则，包括差旅和住宿费用，出差津贴和相应的税费。
6.1.3 日常运维管理服务流程
图 运维管理服务流程
举例：问题解决流程描述如下：
6.1.4 日常应用运维管理服务
用户疑难解答
从热线支持团队接受事件，根据既定的事件和问题流程，进行后续的跟踪处理；
针对事件或者问题，对于属于需要第三方支持的问题，提交到第三方支持团队，比如涉及到原厂商的产品修正或者和基础架构硬件、软件相关不在支持服务范围内的问题。
生产机问题处理
分析问题，并诊断原因，适当的时候调整和修改配置或者更改现有的客户化程序，所有对现有系统的修正需要遵循既定的变更管理流程。
分析并解决调整对现有系统和业务流程处理的影响；
根据变更流程的结构，决定是否需要将相应的调整应用到生产系统
关键用户培训
每季度针对常见问题进行分析，属于操作问题的提供集中培训。
对于新的功能、流程的变更引起的操作改变可以按需求提供培训。
在日常服务中，对集中出现的事件和问题进行总结，并在必要时为关键用户提供相关培训，以提高系统的稳定性和工作效率。
服务商负责提供电子版的培训材料，不负责提供纸质的培训材料。
6.1.5 日常运维服务团队
服务商使用远程支持的模式，为甲方安排远程功能顾问团队，对服务范围内的模块进行支持。如果问题不能远程解决，则派顾问到现场解决问题。项目经理也会每月和甲方召开服务质量回顾会议，对目前的质保服务情况进行汇报。
项目负责人
对甲方的项目）总体负责，并作为升级流程中的重要角色，和甲方的管理层对升级的问题做出指引及决策。
服务项目经理
服务实施经理控制整个项目的服务质量，保证甲方能随时了解该项目的状况。服务经理负责定期向客户提供服务报告，召开服务回顾会议，并在必要时提供服务改进计划。
6.2 服务双方职责界定
6.2.1 甲方职责
甲方将根据需要提供所有数据治理平台硬件和所需的基础设施，并且提供和管理所有的通讯网络问题，使乙方在共识的服务级别上提供这些服务的能力不受影响；
指派专人负责与乙方联络。双方所指派的专人应有权代表合同双方当事人签署必要的文件，包括报告和备忘录等。
6.2.2 乙方职责
乙方进入甲方维护现场须遵守甲方之规章；
乙方在服务实施中要认真负责，保证在甲方购买的服务级别时限内做出相应响应；
负责选派合适的顾问进行远程和现场服务；
负责按照甲方维护管理办法及细则进行维护工作；
按照甲方的要求作好服务支持的各类记录、报告和分析统计工作，及时完成相应的文档；
遇突发事件时相关人员应保证随时联系得到；
如遇服务人员无法解决的问题，应及时向项目经理报告，调集其他技术资源，协调、配合予以解决。
6.3 我司运维服务对贵司的价值
通过为贵司提供应用管理服务，不仅能给贵司带来满足业务需求的快速响应和解决问题，还能为贵司的技术人员更专注于业务的核心发展。
6.3.1 无缝、平滑过渡
我司定位于贵司的长期合作伙伴，不是单纯的运维服务提供商，在整个服务周期内，将持续关注贵司的业务发展和变化，及时提供相应的服务，共同发展。作为数据治理平台运维管理服务的单一接口，提供及时服务，并协助贵司进行第三方服务的问题执行。缩短故障解决时间，提高工作效率。
6.3.2 提高贵司IT管理水平
通过我司提供的专业管理运维服务，帮助贵司提升IT运维管理水平，保障系统的高效性和可用性，提高系统的运行效率，保障业务的顺利运行最大化实现投资回报。
6.3.3 保障贵司得到迅捷满意的高质量服务
我司通过专业的服务管控流程，提供基于事先确认的SLA的应用运维管理服务，使最终用户得到迅捷、及时、高质量的服务，提高客户满意度。
6.3.4 优化贵司数据治理资源利用，提高企业核心竞争力
我司的数据治理服务可以使贵司的数据治理人员不再局限于日常烦琐的维护工作，他们可以把更多的精力投入于与贵司业务发展紧密相关或关键的核心业务上，使贵司的数据治理得到合理充分利用。同时，获得我司成熟的管理理念和流程， 从而提高贵司的企业核心竞争力和数据治理管理水平。
7 运维服务方案
7.1 运维服务范围
系统平台的最佳使用效果需要运维服务的支撑与辅导使用，提供了一套覆盖医院后勤业务，特别是医院后勤运行保障业务的运维支撑体系。
机电系统运维主要对供配电系统、中央空调系统、热力系统、给排水系统、医疗气体系统、污水处理系统及相应的智能化系统等进行运维服务。具体如下图所示。
图 机电系统运维服务范围
7.2 运维服务目标
运维服务以能源管理、设备管理、信息化管理和三维空间管理等模块的智慧运维平台为运维工具，为客户提供“运行、维护、诊断和管理”的数字机电智慧运维一体化解决方案，提高“保障、服务、管理”效果，实现运维服务质量的整合提升。
保障目标：
保障用能安全
保障设备安全
保障人员安全
服务目标：
提高服务品质
提高运维能力
提高运维效率
管理目标：
提高管理水平
提升管理空间
提供管理支撑
7.2.1 运维服务内容
7.3 运维服务实施安排
（1）运维合同独立签署
后勤运维现状调研
运维服务方案设计与确认
运维服务合同确定
（2）交接准备
人员准备
成立项目组及人员分工
开展内部培训
资料准备
标准与规范准备
标书、合同、技术协议收集
系统、设备资料收集
（3）项目交接
系统验收与整改
台账建立
接受厂家/建设方培训（新建项目）
联合试运行（新建项目
交接后的对接方式确认
（4）正式进场运维
建立运维体系，线上线下协同作战，在保障安全的基础上实现高效管理、节能运行。
