标的提供的时间

本项目服务周期自2024年7月1日至2027年6月30日止，共36个月。

标的提供的地点

中山市

付款方式

1期：支付比例100%,付款方式 （一）本项目合同款，由甲方按以下方式向乙方分期支付： 1．2024年7-12月服务费（金额=合同总额÷36个月×6月） 结算金额=“2024年7-12月服务费”-“2024年7-12月结算应扣减的违约金（如有）” 付款条件：甲乙双方已对2024年7-12月服务期间，乙方服务工作进行验收结算，双方已书面确认结算金额。 结算时间：2024年12月10日 2．2025年服务费（金额=合同总额÷36个月×12月） 第一期：结算金额=2025年服务费×50%-2025年上半年结算应扣减的违约金（如有） 付款条件：甲乙双方已对2025年1-6月服务期间，乙方服务工作进行验收结算，双方已书面确认结算金额。 结算时间：2025年6月30日 第二期：结算金额=2025年服务费×50%-2025年下半年结算应扣减的违约金（如有） 付款条件：甲乙双方已对2025年7-12月服务期间，乙方服务工作进行验收结算，双方已书面确认结算金额。 结算时间：2025年12月10日 3．2026年服务费（金额=合同总额÷36个月×12月） 第一期：结算金额=2026年服务费×50%-2026年上半年结算应扣减的违约金（如有） 付款条件：甲乙双方已对2026年1-6月服务期间，乙方服务工作进行验收结算，双方已书面确认结算金额。 结算时间：2026年6月30日 第二期：结算金额=2026年服务费×50%-2026年下半年结算应扣减的违约金（如有） 付款条件：甲乙双方已对2026年7-12月服务期间，乙方服务工作进行验收结算，双方已书面确认结算金额。 结算时间：2026年12月10日 4．2027年1-6月服务费（金额=合同总额÷36个月×6月） 结算金额=“2027年1-6月服务费”-“2027年1-6月结算应扣减的违约金（如有）” 付款条件：甲乙双方已对2027年1-6月服务期间，乙方服务工作进行验收结算，双方已书面确认结算金额。 结算时间：2027年6月30日 （二）付款时间 1．每期付款前，乙方须先行按甲方要求提供相应付款额的发票正本一份及付款申请书原件一份，甲方收到符合要求的请款材料后30个工作日内支付；如乙方未按要求提供上述请款材料，甲方付款时间相应顺延，顺延至甲方收到乙方提供的符合要求的发票和付款申请书之日起30个工作日内（本合同另有约定除外）。 （三）付款方式：银行转账。           （四）因甲方使用的是财政资金，乙方同意：（1）甲方在上述规定的付款时间为向政府采购支付部门提出办理财政支付申请手续的时间（不含政府财政支付部门审核的时间），在规定时间内提出支付申请手续后即视为甲方已经按期支付；（2）甲方有权径行在待付款中扣除违约金。

验收要求

1期：(1)成交供应商完成技术服务工作的形式：成交供应商按合同要求提供服务，合同服务期满，整个项目验收时，按照合同要求移交全部项目文档（包括验收报告、技术文档、完整的软件技术资料等），由采购人书面验收合格。 (2)技术服务工作成果的验收标准：成交供应商按合同要求提供服务，按照合同要求移交全部需求过程文档。 (3)技术服务工作成果的验收方法：成交供应商应于服务期结束后7日内提交验收书面申请。采购人收到验收书面申请后7日内组织验收并签署《项目验收报告》。                                     (4)如采购人对成交供应商某次提供服务的质量有异议，须在成交供应商提供当次服务后的7日内以书面方式向成交供应商提出，成交供应商将根据合同要求进行整改。 (5)验收的时间、地点和人员：运维服务期届满后7日内成交供应商应向采购人提交书面验收申请，采购人同意后进行验收，验收小组成员应包括项目相关各科室负责人员，必要时可邀请专业技术人员参与验收。 (6)本项目需按要求提供以下项目验收资料（包括但不限于以下材料）： 运维实施          1） 项目实施计划（每半年提供1份）  2）项目总结报告（每半年提供1份）  3）项目验收报告（每半年提供1份）  4）项目运维记录报告（每半年提供1份） 相关产出物          1）终端查询、打印业务量统计（每半年提供1份）  2）运维记录（包括：功能需求上线确认表、数据统计分析截图、问题数据处理确认表等）（每半年提供）  3）项目运维记录报告（每半年提供1份）  4）项目月报（每半年提供6份）  5）项目满意度调查表（每半年提供1份）  6）驻点人员打卡记录（每半年提供1份）

履约保证金

不收取

其他

其它，一、报价要求，1、供应商须对各分项进行报价。  2、本项目投标报价包括了与本次服务项目相关的全部费用，按照政府部门有关政策应缴纳的发票税金由成交供应商承担。 二、投标说明，1、成交供应商负责磋商文件对供应商要求的一切事宜及责任。 2、成交供应商未经采购人同意不得分包本项目。

序号

品目名称

标的名称

单位

数量

分项预算单价（元）

分项预算总价（元）

所属行业

技术要求

1

其他信息技术服务

中山市社会保险基金管理局政务信息化项目2024-2027年度运维项目

项

1.00

2,160,000.00

2,160,000.00

其他未列明行业

详见附表一

参数性质

序号

具体技术(参数)要求

1

1. 项目运维采购内容

1.1.社会保险业务信息系统维护内容

社会保险业务信息系统维护主要维护服务内容为：

（1）业务需求维护。根据本地差异化业务需求以及加强业务管理提升服务水平的有关需求，对社保业务信息系统进行相应功能的开发和完善。包括综合业务类、社保关系类、三险待遇调整类、财务类、稽核类、档案一体化类等。

（2）协助提供社保数据应用处理服务。如协助开展数据分析测算、数据检查发现业务疑点问题、日常数据统计分析、协助外部门和上级部门提供数据等。

（3）完善和改造数据稽核功能。根据省系统每天下发的业务数据，完善和改造原业务风险监控平台，维护业务风险点校验方法库的检查语句，实现通过数据检查比对，对业务进行稽核检查，防范业务风险的管理目标。

（4）其它维护工作，包括：应用集群维护、数据库（ORACLE）维护、中间件（websphere）维护、服务器操作系统 (AIX) 维护和档案存储服务维护等。

1.1.1.业务需求系统维护

业务需求系统维护工作是根据本地差异化业务需求以及加强业务管理提升服务水平的有关需求，对社保业务信息系统进行相应功能的维护。需将采购人提出的系统问题和业务需求予以解决，保障系统正常高效、稳定运行，充分发挥系统作用。主要包括以下内容：

（1）软件改正性维护，即诊断和改正在使用过程中发现的软件错误和漏洞。

（2）软件完善性维护服务，即根据采购人的要求改进或扩充软件使它更完善，优化目前占用系统资源较大的程序。

（3）软件适应性维护服务，即修改软件以适应环境的变化，主要表现为因政策调整或是新政策出台，或是社保业务办理流程的完善而需要对软件系统进行功能修改或功能新增。

本项目需要维护的信息系统，包括社保核心业务信息系统，社保业务辅助系统，以及与社保核心业务信息系统实现一体化的档案一体化系统和财务一体化系统，以及其它关联系统和接口的维护。具体维护的系统由下表所示：

1.1.2.提供社保数据应用处理服务

社保局社保数据量庞大，且为重点民生数据。既有上线省系统前的历史数据，也有上线省系统后，通过市级交换库接收省系统下发的业务数据。通过本项目提供社保数据应用处理服务，加强社保大数据应用，提高社保局业务管理水平和工作效率。提供社保数据应用处理服务，一方面需深入了解业务，与采购人共同探讨并确定数据处理规则，另一方面须及时响应，通过信息化技术手段实现数据的统计和提取工作。如果数据需要编写有关程序处理，则须编写有关程序协助采购人维护数据。

提供社保数据应用处理服务，包括以下方面工作：

（1）数据统计分析等应用工作

包括但不限于以下工作：通过数据分析测算，加强政策制定的科学性和有关决策的合理性；通过数据稽核发现疑点数据，有利于开展针对性的核查工作，提高社保基金监管能力；通过日常数据统计分析，及时了解业务运行情况，做好有关业务的分析研判和决策支持；通过与市政数局等部门间的数据交互，实现政府数据的高度融合应用和业务协同；通过提供和统计相关数据，协助上级部门、审计、纪检巡察等开展有关专项工作；通过业务数据的提供，能丰富本地公共服务系统的数据来源，方便群众查阅和打印个人参保待遇资料，不断拓展公共服务方式，为群众提供多样化特色服务。

（2）问题数据处理工作

针对业务数据存在的各种问题，提出具体解决措施和方法，提高数据质量。

1）关联业务数据问题

关联业务数据问题主要体现在以下三个方面：

l 老系统数据本身存在缺失，系统上线后补录入系统。这类数据问题，需要等到系统上线后由现场维护人员通过数据转换程序转换到现用系统中。

l 已有信息系统中存在逻辑关系错误的数据。这类数据问题需要现场维护人员根据各关联数据间的逻辑关系，通过编写数据处理脚本进行数据修改。

l 已有信息系统中存在业务数据不准确的情况。这类数据问题需要现场维护人员根据历史数据或是关联数据间的逻辑关系，通过编写数据处理脚本进行处理。

2）运行中数据问题

运行中数据问题主要体现在以下两个方面：

一是由于程序自身编写错误导致系统中业务数据出现计算错误或是逻辑错误，这类问题需要首先对软件系统进行修改完善解决程序问题，然后根据错误原因对出现错误的数据进行修改。

二是由于个别业务经办人员对软件系统的业务流程不熟悉，对系统程序错误操作，导致业务数据出现错误，这类问题需要现场维护人员根据实际情况进行业务回退，修改错误数据。

3）完善、补充数据问题

完善、补充数据问题主要体现在，系统运行过程中需要完善、补充数据产生的维护任务，例如：新系统上线时有些数据由于时间原因或是非必要数据，在数据采集时没有进行采集，系统上线后需要通过数据转换将需要补充采集的数据转换入已有信息系统。

4）新增需求导致数据转换

新增需求导致数据转换主要是由于在信息系统中新增加了某些特殊需求或是特殊业务功能，导致需要将某一种类数据导入已有信息系统中或是对信息系统进行参数初始化工作。

1.1.3.维护数据稽核功能

根据省系统每天下发的业务数据，维护原稽核业务风险监控平台，维护业务风险点校验方法库的检查语句，实现通过数据检查比对，对业务进行稽核检查，防范业务风险的管理目标。

根据业务部门提出的业务风险点，结合省系统业务数据情况，编写相关数据检查语句，并配置至业务风险点校验方法库中。系统根据采购人设置的检查时点以及业务风险点校验方法库中的检查语句，定期搜索出疑似问题数据。疑似问题数据流转至相关业务科室工作人员，由相关人员进行核实确认，标注核实确认情况。

1.1.4.数据库、中间件等维护

（1）数据库维护

社保局社保信息系统使用到的数据库类型主要为DB2和Oracle。数据库运行维护工作在整个维护工作中占有非常重要地位。通过对数据库运行维护可以了解数据库的日常运行状态，识别数据库的性能问题发生在什么地方，有针对性地进行性能优化。同时，密切注意数据库系统的变化，主动地预防可能发生的问题。

本次维护工作中关于数据库维护部分主要包括以下内容：

1）数据库健康检查

检查并分析系统日志及跟踪文件，发现并排除数据库系统错误隐患

检查数据库系统是否需要系统最新的补丁集

检查数据库空间的使用情况

检查归档方案设计的是否科学合理

协助进行数据库空间的规划管理

检查数据库备份的完整性

监控数据库性能

通过改善系统环境的稳定性来降低潜在的系统宕机时间

根据软件条件和业务特征对数据库的初始化参数和数据库的逻辑结构进行适当的调整

2）数据库产品性能调优

分析用户的系统类型和行为

评价并修改数据库的参数设置

评价并调整数据库的数据分布

评价软件系统对软件和系统的使用情况，并提出建议

利用先进的性能调整工具实施数据库的性能调整

培训用户有关性能调整的概念

提供用户完整的性能调整报告和解决方法

（2）中间件维护

中间件维护是指对Websphere中间件的日常维护管理和监控工作，提高对中间件事件的分析解决能力，确保中间件持续稳定运行。具体包括以下工作内容：

1)监控服务启动是否正常

2)监控Websphere配置执行线程的空闲数量

3)监控内存曲线是否正常，是否能够及时的进行内存空间回收

4)检查Websphere日志文件是否有异常报错

5)根据信息系统运行情况对中间件系统参数进行调优

6)即时对中间件进行故障诊断，找到问题点，予以解决。

1.2社会保险公共服务系统运维内容

图一 自助服务系统拓扑结构图

社会保险公共服务系统运维主要维护服务内容为：社保公共服务系统维护包含自助终端系统、公共服务辅助系统、业务查询和业务办理接口平台、短信发送平台、信息发布平台、对接省系统有关业务接口和数据等公共服务系统的日常维护工作、相关功能完善，以及新增功能程序开发。

1.2.1.公共服务系统软件维护内容

成交供应商须做好公共服务系统软件的日常维护、业务新增以及系统完善，日常跟进采购人提出的业务需求和系统改进，要求成交供应商在各系统的运维中可以提出改善性建议，并做好实施跟进，确保公共服务类系统的建设能满足日新月异的采购人需求。具体维护的系统由下表所示：

成交供应商负责为采购人提供软件服务，包括公共服务各类软件系统（包括自助查询终端系统、自助打印终端系统、公共服务辅助系统、查询平台接口工程、内部信息发布平台、短信发送平台等）的日常维护、业务新增以及系统完善。具体包括但不限于以下内容：

1.2.1.1.自助终端系统（查询）

（1）系统现状

自助查询终端是通过社会保障卡及其密码进行认证。参保人凭社会保障卡登录主功能界面，通过点击终端触摸屏进行相关操作。自助查询终端系统包含的功能主要有以下7类：

1)信息查询与业务办理

提供基础信息类查询，包括个人的参保信息。如个人登记的基本资料、参保简历、缴费情况、待遇明细等信息类查询。

2)单据打印（卷纸）

提供缴费票据打印，缴费票据使用76MM×156MM卷纸打印，确保以后新上线功能能够满足。

3)社保卡业务

包括社会保障卡基本资料查询、修改密码、一代社保卡个帐圈存等社保卡相关业务。

4)办事指引

提供业务办理的咨询信息。参保人可以在此功能区中查询到所有社会保险业务的办事流程、所需材料等信息。

5)服务信息

提供社保对外服务的基本信息。包括各镇区人社分局、门诊基本医疗就医点等机构的地址，自助终端的分布情况，社保药品目录等便民信息。

6)数据统计报表

提供前台业务服务访问情况的查询与统计，可以通过后台进行按月统计报表，并能导出汇总信息。

7)自助服务后台管理

（2）现有各大业务的结构图如下：

图二各大业务的结构图

各大功能下级子业务分别如下图：

图三自助服务系统软件功能结构图

（3）系统维护需求

1)做好新功能的规划和扩展，在现有系统中接入新的业务查询、业务办理等功能，能预留不同业务接口，允许新业务的快速接入，维护第三方已接入系统（如税务局等）的接口；

2)根据省局接口对接方案，不断调整和优化系统业务接口的稳定性，优化相关业务的用户交互界面，提升用户体验。

3)系统构架优化与调整，不断优化现有的系统，使系统高效运转，优化以前陈旧的流程，不断提升用户满意度。

4)构建并完善好自助服务系统后台管理系统，实现自助服务集中管理、运维功能；包括服务器监控完善、升级任务管理、表格打印报表等功能；

5)监控并日常维护各业务功能点，完善实时监控终端所依赖的三方系统，如人社局公共服务接口平台服务情况，做好实时告警通知；

6)处理其他软件更新带来的系统兼容性问题，提高整个终端系统的服务能力。

7)做好日常系统运维工作，监控系统运行状况，进行故障排除、版本更新、日志清理、参数配置及其他相关工作。

1.2.1.2.自助终端系统（打印）

（1）系统现状

为提高市民的办事效率和减轻前台业务人员的压力，建设了自助打印终端系统，功能包括个人参保证明打印、个人权益单、养老待遇表单打印（基本养老金核定表，基本养老保险个人账户退款核定表，基本养老保险退休死亡待遇核定表）、工伤业务打印（工伤保险伤残待遇核定表，工伤保险工亡待遇核定单，工伤保险一次性医疗补助金核定表，工伤职工住院伙食费补助核定单表）、养老保险参保缴费转移凭证打印（省外养老保险参保缴费转移凭证打印，省内养老保险参保缴费转移凭证打印）、失业保险参保缴费转移凭证打印（省外失业保险参保缴费转移凭证打印，省内失业保险参保缴费转移凭证打印）等。

功能说明如下：

1)个人参保证明打印

参保人员通过插卡或者身份证打印参保证明，证明内容主要是个人的参保简历情况，包括参加险种、缴费金额或缴费工资、缴费年月、参保单位编码等。

2)个人权益单打印

参保人员通过插卡输入需要打印的年度后点击查询按钮,主要内容包括个人基本信息、缴费情况、个人账户情况。

3)养老待遇表单打印

进行基本养老金核定表、基本养老保险个人账户退款核定表、基本养老保险退休死亡待遇核定表，参保人通过在终端机器上插入社保卡，查询本人的养老信息查询后进行直接打印。

4）工伤业务打印

参保人通过在终端机器上插入社保卡登陆系统后，可直接打印工伤保险伤残待遇核定表、工伤保险工亡待遇核定单、工伤保险一次性医疗补助金核定表、工伤职工住院伙食费补助核定单表。

5)养老保险参保缴费转移凭证打印

包括省内养老保险参保缴费凭证和省外养老保险参保缴费凭证，参保人通过在终端机器上插入社保卡登陆系统后，进行查询本人的养老保险参保缴费信息，并进行打印取表。

6)失业保险参保缴费转移凭证打印

包括省内失业保险参保缴费凭证和省外失业保险参保缴费凭证，参保人通过在终端机器上插入社保卡登陆系统后，进行查询本人的失业保险参保缴费信息，并进行打印取表。

7)机关事业单位职工养老保险类打印（机保类打印）

参保人通过终端机，进行机关事业单位职工养老保险类表单打印（简称：机保类打印），主要涉及到养老保险参保证明打印、养老保险参保缴费凭证打印、个人权益记录单打印、养老保险关系转业接续申请表打印、退休人员领取基本养老金证明打印。

（2）系统维护需求

1)监控当前各业务的运行情况，确保业务正常运作，日常对业务打印量进行统计，监控系统性能并做好系统优化相关工作。

2)完善并规范各业务的打印记录，便于统计和查询。

3)根据省局接口对接方案，不断调整和优化系统业务接口的稳定性，优化相关业务的用户交互界面，提升用户体验。

4)业务功能拓展，可以在原有的系统上根据业务需求进行快速开发，并实现新业务表单打印功能的上线使用，在现有框架基础上扩展部分新的业务表单打印功能。

5)系统构架优化与调整，不断优化现有的系统，使系统高效运转，优化以前陈旧的流程，不断提升用户满意度。

1.2.1.3.自助服务后台管理系统

自助服务后台管理系统实现自助服务集中管理、运维功能；包括业务菜单配置、终端信息维护、终端监控、数据统计报表等功能。

（1）菜单配置

通过配置业务菜单，可以动态调整各自助终端的访问界面；

（2）终端信息维护

管理并维护终端设备信息，包括机器基础配置信息、负责人信息、设备归属信息、项目管理信息等；

（3）终端监控

实现后台集中监控功能，可以实时有效的查看设备运行状况，记录日常运行信息，并可以通过系统配置设备保障的提醒方式，如短信、警告音、页面图形指示灯等；

（4）数据查询统计

可以查询各种业务访问报表，提供详细的按系统、按业务功能、票据打印等数据报表。

1.2.1.4.公共服务辅助系统

（1）系统现状

为提高前台业务的办事效率和满足不断新增的业务需求，建设了本辅助系统，系统主要用户为市属和镇区的前台业务人员、科室办事员及信息管理员，总体功能包括特殊证明打印、短信发送、业务办理、查询统计、基础数据统计等。

1）证明打印

提供证明核查、协查证明、死亡待遇证明、特殊证明等证明打印；

2）业务办理

包括单位经办人管理、网上业务办理和审核、权益单的查询与邮寄、养老缴费登记、网上预约管理等；

3）查询统计

可以维护各种统计指标、发布统计数据、提供统计数据分析界面；数据查询业务配置，可以灵活通过配置SQL实现各种业务的查询；业务量汇总，如工伤待遇统计、拆账进度统计、综合费率各镇(区)每月拆账统计打印、各镇区前台参保凭证打印量统计、综合费率各镇(区)每月拆账统计打印、参保证明月/年报表、参保凭证自助打印量统计等。

（2）维护需求

1)基于符合J2EE 软件开发标准的B/S 软件架构，采用面向对象的分析和设计方法，在符合需求和可实现的范围内适当采用先进的技术架构对辅助系统做好优化设计。

2)做好新功能的规划和扩展，在现有系统中接入新的业务，能预留不同业务接口，允许新业务的快速接入，针对省系统的业务接口开发辅助业务模块，如证明打印统计、查询统计分析等。

3)对批量处理大量数据的业务功能进行日常跟踪监控，可优化数据处理流程，分解批量数据处理的压力，提高批量数据处理速率，保证系统的稳定性。

4)做好日常辅助业务系统运维工作，监控系统运行状况，进行故障排除、版本更新、日志清理、参数配置及其他相关工作。

5)完善及优化查询统计模块，优化统计算法，提高统计语句运行速度。

1.2.1.5.短信发送平台

（1）系统现状

短信发送平台可通过配置业务短信模板，提供业务短信、内部通知、计划短信的生成、审核、发送流程；并可通过短信管理模块进行短信的查询、统计、月报表、对账等功能。目前短信平台提供单条实时、大批量实时和定时短信的发送。

（2）维护需求

1）对批量处理大量数据的业务功能进行日常跟踪监控，保证系统的稳定性；

2）做好日常短信发送平台的运维工作，监控系统运行状况，进行故障排除、版本更新、日志清理、参数配置及其他相关工作。

3）短信发送流程的完善和优化，包括发送流程、通讯录、定时任务、短信三方接口、统计查询等。

4）根据运营商提供的对接方式的不同，作适应性改造。

1.2.1.6.新公共服务接口平台接口工程

（1）系统现状

由于人社局发起建设，已于2019年开始投入使用。该系统的主要用于接口统一配置管理与对外提供统一业务接口，自助终端或外单位等系统发起的查询请求。系统以HTTP方式提供查询接口。

（2）公共服务涉及接口维护

1）对社保局公共服务类子系统涉及的接口进行性能分析，对处理时间过长的接口进行改造，优化算法，保证接口整体的处理时间与数据精度能满足需求；

2）维护现有接口，监控接口日志信息，跟踪处理好接口异常，确保各子系统正常运行；

3）为自助服务新业务新增接口服务，开发和配置该部分新增的接口。

4）规范接口开发，做好接口功能注释及完善接口版本更新记录。

1.2.1.7.查询平台接口工程

（1）系统现状

查询平台隶属金保工程公共服务的子系统，其主要建立一个统一的核心查询平台，接收手机短信、12333自助查询、自助终端或外单位等系统发起的查询请求。系统以webservice和socket两种方式提供查询接口。webservcie和socket请求处理流程描述如下：

1)查询请求权限检测：检测webService和socket查询请求是否有合法权限，如果没有查询权限就结束返回，否则进入下一步计算请求优先度。

2)计算请求优先度：根据请求来源的不同和请求查询业务的内容的不同计算出查询请求的优先度值，这个值用于请求队列排队。

3)请求队列是否已满：查询请求计算得到优先值后就进入请求队列排队等待执行，socket请求和webservice请求分两个队列排队。进入队列前检测队列是否已满，如果已满就结束返回，否则进入队列排队。

4)socket请求队列排队：socket请求进入socket请求队列排队，排队超时的请求将结束返回。

5)webservice请求排队：webservice请求进入webservice请求队列排队，排队超时的请求将结束返回。

6)socket处理线程池：从socket请求队列取出的队头请求交给socket处理线程池处理。

7)web容器线程池：从webservice请求队列取出的队头请求由web容器本身的线程池处理。

8)是否有缓存：线程处理请求查询的时候判断是否有缓存数据。

9)查询数据库：没有缓存就直接查询数据库。

10)读取缓存数据：有缓存则读取缓存数据。

11)返回结果：返回查询结果给请求。

目前的接口包括自助服务、计生证明、社区版服务、劳动查询服务等接口，各类接口分别编定在各个动态类中，接口量多，需对各个接口的查询性能进行优化处理。

（2）公共服务涉及接口维护

1）对社保局公共服务类子系统涉及的接口进行性能分析，对处理时间过长的接口进行改造，优化算法，保证接口整体的处理时间与数据精度能满足需求；

2）维护现有接口，监控接口日志信息，跟踪处理好接口异常，确保各子系统正常运行；

3）为自助服务新业务新增接口服务，开发和配置该部分新增的接口

4）规范接口开发，做好接口功能注释及完善接口版本更新记录。

1.2.1.8.内部信息发布平台

（1）系统现状

内部信息发布平台包括通知公告、政策法规、制度规范、通报动态、复审情况、业务规程、下载中心的查询、创建、审核、发布及同步社保网上服务功能。

（2）维护需求

1）保证系统运行稳定，监控系统运行情况，进行故障排除、版本更新、日志清理、参数配置及其他相关工作；

2）完善现有功能，开发新增功能。

1.2.1.9.其他技术服务类

（1）提供技术支持，各类软件应用类方案，如中间件安全、业务辅助类实现方案。

（2）协助开展省公共服务统一平台、“粤省事”微信小程序、省统一身份认证平台、省集中系统对接建设工作，及社保局自助终端系统等接入其他单位应用系统或功能的建设工作，提供社保局公共服务平台社保接口使用说明、调用、封装等技术支持。

（3）维护社保档案，处理日常镇区的报障，维护电子移交系统，处理历史存量的信息。

1.2.1.10系统架构优化与调整

优化现有系统架构，如：现有的架构是Web服务器与WAS配合请求分发，随着终端机的越来越多，已慢慢无法满足使用需求，在高峰期可能会出现繁忙的情况。采用有关技术手段，优化现有系统架构，减少服务器压力，充分利用系统资源，支持高并发请求数，能同时承受更多的访问请求。

（1）优化第三方系统业务接入，现在自助终端系统接入的系统越来越多，如现在的税务局，可能后期会加入医保局的等等，优化提升用户体验。

（2）根据省局接口对接方案，目前终端部分业务的数据来源已做相应的切换，对接了省局数据接口，后续需要不断调整和优化系统业务接口的稳定性，优化相关业务的用户交互界面，提升用户体验。

2.项目总体服务要求

2.1.运维服务工作要求

2.1.1.维护原则

（1）先进原则

整个系统的实施必须在统一性原则的指导下，按计划、有序地推进系统实施。在实用、可靠的前提下，使设计系统能够最大限度地适应技术发展变化的需要，以确保系统的先进。

（2）实用性原则

系统按照实用性原则进行建造，采用成熟的技术。遵循整合资源，互联互通的原则。加强已有软件基础、社会保险信息资源、业务系统整合，促进互联互通、信息共享，发挥已有资源最大效益。

（3）标准化原则

系统采用的技术必需统一采用一个标准，并且符合主流标准。系统构建应严格遵循国家、省统一的标准和规范；建立健全相适应的组织、制度、安全等保障体系。

（4）开放性原则

系统采用的技术必需采用开放性标准，以方便以后的扩展。

（5）兼容性原则

需要充分考虑与原有系统的兼容性，保证整个系统在扩展中可以平滑过渡，系统采用的技术必须兼容目前主流厂家产品和主流标准，以方便维护和扩展。

（6）整体性原则

系统设计必须从整体角度进行考虑，具有可扩展性。

（7）共享性原则

各个系统之间根据需要能够实现信息共享。

（8）安全性原则

保证信息系统的安全，防止各种攻击，保证整个系统在扩展中可以平滑过渡。

（9）保密性原则

保证涉密信息系统中的秘密信息不被泄露。

（10）可靠性原则

保证系统必须运行稳定可靠，保障业务的顺利开展。根据系统变换扩建的定位，系统的建造和运行必须保持业务系统的相对独立性，其建造并不会影响目前各业务系统的正常运行。

（11）经济性原则

在满足使用需要和留有余量的前提下，必须尽量采用经济的技术和方案。遵循统一规划，分步实施的原则。总体设计应对信息系统作全局统一规划、统一标准，如果受到资源或其它因素制约，可以采取分步建造的方式实施。

（12）可扩展性原则

有充分的机制方便各业务量和业务种类的扩展，保证建造完成后在向新的技术更新时，能保护已有的投资。立足中山实际，结合人社部关于金保工程的整体规划，根据社保业务需求，突出应用、稳步推进，提高工作效率。

（13）可维护性原则

系统必须按照易于维护和管理的原则进行建造。

2.1.2.技术要求

2.1.2.1.设计要求

1）系统整体采用J2EE体系结构，兼容B/S/S、C/S/S两种混合模式来构筑软件系统；

2）社保信息系统维护开发，采用B(C)/S/S和T/S灵活结合的软件体系结构，为了便于管理和维护，统一整个金保工程业务系统的标准，社保业务管理系统尽可能的采用 B(C)/S/S的体系架构，但对于一些计算复杂的业务，为了提高工作效率，充分利用A/S 400 的效能，采用T/S（指的是外部调用A/S 400内部存储过程）的体系架构。

3）维护开发要符合金保工程系统建造的总体规划和关于信息系统建造的有关要求，遵守各项数据、技术标准；

4）采用模块化、一体化等先进可行的分析和设计方法。代码要满足高质量、高性能、易移植、易升级、易维护的需求，能和已有业务财务一体化、业务档案一体化融合。

5）程序应具有主动智能提醒，引导操作人员办理业务，具备业务感知及导航功能，可根据前台操作人员输入的条件参数完成业务的模拟计算。

6）采用操作留痕的设计，在业务系统中实现多重审核功能，保留每一用户对数据的操作记录，在业务尚未终结前能够逐级回退，实现系统状态和数据的回滚。

7）符合国家和省人社法规目前或以后的发展要求。

2.1.2.2.软件工程要求

1）本项目所涉及的软件及数据库设计开发，要遵守软件工程的原则和采用软件工程的方法，以确保软件系统预期开发目标的实现，确保工程质量和产品可靠性。完成的应用软件应与所确定的软件功能和性能需求相一致；与相关的开发标准相一致；并与所有专业开发的软件所期望的特性相一致。

2）本项目所涉及软件的维护以及社保数据应用处理服务，承建商要充分了解中山市社保局的需求、熟悉社保有关业务、必须完成且不限于社保局各科室已有业务。

3）软件设计要内容全面、结构合理、功能完备。

4）遵循中山市社保局、人社局信息办的合理要求和建议。

5）本项目所开发系统的知识产权归采购人所有（除成交供应商开展本项目前已获得知识产权专利的技术资料外）。成交供应商向采购人提供针对本项目开发的源代码（含所有后续升级版本），版权为采购人所有，采购人有权自行或委托第三方对系统进行二次开发和修改。

2.1.2.3.性能要求

1）系统精度要求。金额类数据计算中间结果保留至少4位，最后结果的精度保留2位，非中间结果和其它数据类可根据实际情况确定。

2）系统稳定性要求。系统能够全年7天×24小时连续稳定运行，由于系统故障导致业务连续停止时间不超过6小时。

3）系统响应速度。系统的响应时间是从询问或请求的结束到响应的开始之间经历的时间，主要用于衡量交互式作业处理。在配置合适的软件系统环境下，根据行业经验，可以忍受的响应时间在3秒内。汇总、统计性操作，根据最大原则，以及数据量，如参保人数的多少，响应时间相应延长为5-10秒。如果要求处理的数据量特别大，如台帐、年度结算等操作，相应时间根据实际情况确定。

2.1.2.4.安全要求

1）数据库安全需求

①数据库管理系统本身的安全等级达到C2级。

②必须能够通过对主体（人、进程）识别和对客体（数据表）标注，划分安全级别和范畴，实现由系统对主、客体之间的访问关系进行强制性控制。

③必须能够对与数据库安全有关的事件进行跟踪、记录、报警和处理，供有关人员进行分析。

④必须能够按照最小授权原则，对数据库管理员、软件开发人员、终端用户授予各自为完成自身任务所需的最小权限。

2）软件系统的安全需求

①必须基于中山市金保工程数据中心的用户权限，在用户登陆之前，系统软件本身必须对当前的运行环境进行一系列的合法性检查，如果软件系统本身的配置数据被改动，系统要拒绝该用户登陆。

②应用软件必须提供一种或几种有效的加密方式，对敏感数据库的存储进行加密处理

③应用软件必须对每一位使用应用软件的操作人员，都要验证其身份和权限。

④本系统在用户管理方面须基于中山市金保工程数据中心的用户权限实现单点登录功能。

2.1.3.维护服务工作要求

1．制定和实施软件系统维护服务计划；

2．监控系统运行状况、版本更新情况，确保各镇街人社分局在用的为最新版本，保证系统正常运行；

3．系统的日常维护，如故障排除、版本更新、日志清理、参数配置、协助采购人维护数据、配合采购人进行程序的测试以及其他相关工作；

4．系统完善、优化及升级，包括：

(1)根据采购人需求进行系统的缺陷排除、适应性修改、开发新的功能模块及进行系统优化升级；

(2)按计划对系统新功能进行需求调研，系统需求分析，并对软件设计提出完善、优化方案，经采购人同意后负责实施；

(3)定期（每三个月）对应用软件系统、数据库系统、中间件Websphere的性能进行检测，提供现场优化调整服务，保证应用软件的持续、高效运行；

5．每月对系统进行安全性检查，保证系统安全；

6．程序修改完毕提供相应的程序源代码、数据表说明文档和相关修订文档；

7．定期提交维护报告及总结报告；

8．根据实际需求对采购人进行系统培训，帮助采购人熟悉软件的各项功能；

9．成交供应商应按采购人的要求为第三方在实施与本项目有关的其它各项工作中提供必要的条件和配合开展相关工作。

2.1.4.★工作完成时限要求

1．日常维护：如参数配置、故障排除等，在接到服务要求后 2 个工作日内完成。

2．对某功能模块内做适应性修改的，一般要求在10个工作日内完成开发并经采购方测试通过，特殊情况须经采购人同意后确定完成时间。

3．较大的改动或开发，如：结构性改动、涉及多个模块的改动，对系统有重大影响的改动及新增功能模块等，成交供应商先作调研，并填写任务计划书提交给采购方，再由采购人根据实际情况确定完成时间，原则上不超过1 个月。

4．对采购人提出的社保数据应用处理服务需求，一般要求在接到服务要求后1 个工作日内完成，特殊情况须经采购人同意后确定完成时间。

5．以上工作内容如不按上述要求的时间完成，采购人有权单方解除合同，不予支付余下合同款项。因工作延误造成采购人损失的，采购人有权要求成交供应商赔偿。

6．紧急情况下（如系统出现故障不能结算），成交供应商对采购人在问题报告中或电话中提出的问题要在15 分钟内响应。

说明：以上完成时间是指从提出服务要求起到工作通过验收的时间。

2.2.服务要求

1．本项目要求提供的驻场服务，驻场服务小组技术工程师不少于5人。

2．在项目组人员构成方面，成交供应商必须配备如下几类人员：

(1)系统设计和开发人员；

(2)系统实施人员；

(3)协调和管理人员；

(4)文档编写和管理人员。

3．技术服务要求

（1）驻场服务：服务小组人员要求，必须熟悉J2EE、Websphere中间件及AS/400 DB2和ORALCE 10G数据库开发；驻场维护人员必须熟悉社保业务流程和社保信息系统功能，擅长进行需求调研、分析及与采购人进行沟通。驻场维护人员需具备3年以上社保系统维护经验。

（2）值守服务：提供7×24小时服务（7天24小时响应），包括所有的节假日。提供报修联系电话和投诉电话，专人接听服务热线电话。

（3）远程支持及紧急现场服务：实时远程诊断和故障排除服务（7×24小时服务），包括电话技术支持、微信或QQ等即时通讯工具服务等，对于紧急问题不能在远程处理的，3小时内到达现场处理。

（4）故障处理服务：采购人在使用软件系统中遇到疑难问题或系统出现不稳定情况，成交供应商需提供7*24小时故障处理服务，并在规定时间内进行故障排除，及时定位故障并进行故障处理，避免或减少由于系统故障导致的损失。

（5）自备有关工具，如各种开发设计、维护工具软件，电脑、交通和办公工具等。所使用的工具软件必须是正版。否则，由此产生的纠纷由成交供应商承担。

4．维护登记制度：

（1）订立规范的维护流程和完善的文档，包括服务单和维护日志。在每次维护服务后详细记录维护单位、故障现象、维护内容、维护日期、维护结果、满意度等资料。

（2）分别按季度和年度向社保局提供电子版的维护报告和维护日志，供采购人分析，为更好地开展维护服务工作提供依据。

（3）文件应包含有关文档的模板，模板格式和内容最终由社保局确定。

5．驻场人员不得利用工作之便，进行任何非法或非本项目范围内的活动，特别是发布非法信息，留下系统后门等，驻场人员离开服务场地必须先告知社保局。

6．成交供应商须保证服务团队人员充足，队伍稳定，并由社保局审核，审核通过后才能参与维护工作。经确认的服务团队，未经社保局同意，6个月内不得更换驻场维护人员，且所更换人员须具有相应的资质证书。

7．成交供应商必须按照计算机软件维护的要求，根据社保局提出的系统使用功能，进行维护调研及分析，并形成双方确认的维护确认书。

8．定期（每三个月）对应用软件系统、数据库系统、中间件Websphere的性能进行检测，提供现场优化调整服务，保证应用软件的持续、高效运行。

2.3.人员要求

1、★要求成交供应商成立专项维护服务小组，必须保证在本项目合同期内至少有5名驻点开发人员常驻现场开展工作。成交供应商应在响应文件中提供有关人员列表，介绍维护人员的情况，包括姓名、学历、职称、资格认证、从事类似项目经验、擅长技术、职责安排等情况，并附上相关证明文件复印件。

2. 服务小组人员要求：服务小组人员包括2名中级职称人员、3名初级维护人员。2名中级职称人员为本项目的重点服务人员，必须具备软考中级职称证书（附上相关证明文件复印件），其余3名初级维护人员需具备大专或以上学历软件类专业毕业证书（附上相关证明文件复印件），均要求熟悉J2EE、Websphere中间件及AS/400 DB2和ORALCE 10G数据库开发。驻场维护人员必须熟悉社保业务流程和社保信息系统功能，擅长进行需求调研、分析及与采购人进行沟通。驻场维护人员均须具备3年以上同类系统维护经验。维护人员职责如下：

(1)中级人员工作职责

1)与采购人进行沟通，满足采购人需求；

2)对软件进行修改和完善；

3)编写软件程序设计规格说明书等文档；

4)负责软件系统的需求分析和设计；

5)指导软件工程师/程序员的开发编程工作；

6)对软件系统的进度、质量和技术负主要责任。

(2)初级人员工作职责

1)进行编制项目文档和质量记录的工作；

2)维护软件系统保持可用性和稳定性；

3)在上级的监督下定期完成量化的工作要求；

4)及时处理和解决所负责的维护任务；

5)进行程序单元、功能的测试，查出软件存在的缺陷并保证其质量；

6)对软件进行测试并记录测试结果。

3、所有驻场维护人员必须佩戴工作证,遵守采购人工作纪律以及上下班时间要求，上下班需使用手机定位、指纹识或者人脸识别的考勤机进行打卡，考勤纳入考核。工作人员及工作证必须报采购人有关部门备案。

4、成交供应商须保证服务团队人员充足，队伍稳定，并由采购人审核，审核通过后才能参与维护工作。经确认的服务团队，未经采购人同意，6个月内不得更换驻场维护人员，且所更换人员须具有相应的资质证书。

5、项目服务期间，若发现成交供应商安排的驻场人员不是成交供应商的合法员工，采购人有权中止服务合同。

6、自备有关工具，如各种开发设计、维护工具软件，电脑、交通和办公工具等。所使用的工具软件必须是正版。

7、项目开展期间，驻场维护人员须遵守采购人的工作规章制度和纪律，如果驻场维护人员多次或严重违反采购人制度和纪律的，采购人有权提出要求成交供应商更换人员，成交供应商须在一周内更换。如果驻场维护人员违反制度和纪律的行为，造成采购人产生损失的，成交供应商须承担赔偿责任。

8、维护登记制度

订立规范的维护流程和完善的文档，包括服务单和维护日志。在每次维护服务后详细记录维护单位、故障现象、维护内容、维护日期、维护结果、满意度等资料，为更好地开展维护工作提供依据。

9、驻场维护人员不得利用工作之便，进行任何非法或非本项目范围内的活动，特别是发布非法信息，留下系统后门等，驻场维护人员离开服务场地必须先告知采购人。

10、成交供应商必须按照计算机软件维护的要求，根据采购人提出的系统使用功能需求，进行维护调研及分析，并形成双方确认的维护确认书。成交供应商在实施之前，必须以书面形式向采购人提供维护方案，经双方讨论确认。

11、在成交供应商维护过程中，采购人有权实施监督检查。

2.4.培训服务要求

根据采购人实际需要，在采购人指定范围内提供针对社保局信息系统架构设计、业务数据流、模块与模块之间关系，系统数据库结构关系和对数据库、应用服务器监控、系统调优专业课程及业务系统操作等的相关培训。成交供应商需提供相关培训教材。

2.5.重特大事故报告

如发生重特大事故事件，应全力配合采购人开展信息系统应急处置工作，及时报告故障情况，在要求时间内分析故障原因，恢复系统正常，提出问题分析报告和整改方案。

2.6.安全管理要求

2.6.1.数据安全要求

1．对重要数据进行加密存储和传输，包括但不限于业务系统数据、日常维护等数据，确保数据在存储和传输过程中的保密性。

2．业务系统数据要求定期备份或者在系统更新前备份，存放备份数据的路径应与业务系统的其他文件分开存档。

3．数据恢复前，必须对原环境的数据进行备份，预防有用数据的丧失，数据恢复后，必须进行验证、确认，确保数据恢复的完整性和可用性。

4．要求运维人员对用户的数据享有绝对保密的义务，不得复制、打印、泄漏、存储或以任何形式使用用户数据，除非得到明确的授权。

2.6.2.运维人员安全管理

1．根据岗位职责，为运维人员分配相应的权限，禁止运维人员越权访问系统资源。

2．制定严格的访问控制策略，限制运维人员访问敏感数据和资源。

3．实施最小权限原则，即只授予运维人员完成工作所需的最小权限。

4．成交供应商定期为运维人员提供安全培训，提高安全意识，培训内容应包括但不限于密码安全、漏洞管理、应急响应、保密培训等方面。

5．运维人员应认真履行保密责任，对所接触的一切信息和数据都要保持严格的保密态度，并签署保密协议，明确保密责任。

2.6.3.系统运维安全要求

1．服务器、数据库等登录密码应符合复杂性要求。同时合理配置运维人员用户权限和访问控制列表，防止未经授权的访问和操作。

2．定期对应用程序如数据库、中间件等进行漏洞扫描和评估，发现漏洞应及时修补，避免被恶意利用。

3．及时更新操作系统的补丁和安全加固，对修补后的系统进行重新评估，确保漏洞已完全修复。

4．限制不必要的服务和端口，并定期检查服务器的运行状态和日志文件。

2.7.落实市政数局政务信息系统安全认证登录改造工作要求

l 根据市政数局《关于进一步做好政务信息系统安全认证登录改造工作的函》要求，成交供应商在2024年9月底前必须完成系统安全认证登录改造工作。未按期完成登录改造工作的，采购人有权取消合同或进行相应扣款。

2.8.落实市政数局统一运维工作规范要求

按照市政数局的统一运维规范要求，成交供应商除了按本项目的运维要求执行外，还需按以下市政数局的运维管理要求执行（如两者的运维要求有冲突，按较高一方的服务标准执行）。

2.8.1.项目总体要求

为进一步推动统一运维工作的规范管理，提升统一运维的服务水平和工作效率，按照全市统一运维的战略规划思路，形成运维工作全市“一盘棋”，各部门协力合作，步调一致，通过规范统一、运作统一，实现运维效率提升，财政资金节约的战略目标。

2.8.2.运维服务工作要求

成交供应商需使用市政数局提供的全市统一运维平台开展日常的运维服务工作。（1）采购人不再新建运维平台、不允许成交供应商使用除全市统一运维平台之外的其他运维平台开展运维管理工作。（2）所运维的项目应用系统需与全市统一运维平台对接，实现应用系统用户使用量、访问量等使用效益指标及时推送；（3）实现系统部署资源运行情况的监测、告警。采购人的机房视频监控需汇聚接入到全市统一运维平台，实现应用统一监控、统一管理、统一调度。成交供应商协助采购人做好以下基础运维服务，基础运维服务要求包括但不限于：

（1）落实政务信息系统以及相应资产梳理工作，做好资产台账登记、资产编码、标签分类、标签标识等工作，及时将相关信息录入到统一运维管理平台；

（2）落实政务信息系统以及相应资产的网络拓扑图绘制以及定期更新，确保实际运行状态和拓扑图相符；

（3）落实政务信息系统以及相应资产的网络架构优化、调整、整改实施工作，并定期给业主提供优化建议；

（4）落实与市电子政务外网安全运维中心安全联动工作，包括但不限于及时处置安全运维中心下发的各类安全风险核查、应急处置、漏洞修复、安全加固、应急演练、模拟演练等工作；

（5）落实市重大节假日、重大活动的安全值守工作，包括但不限于节假日值班人员安排、值班排班表上报、线上考勤、安全应急响应处置等工作。

2.8.3.运维人员服务要求

成交供应商运维服务人员由采购人实行管理，同时需遵从和配合全市统一运维管理工作，接受统一运维管理平台人员考勤、服务评价等管理，无条件响应重大节假日、重要活动等重保工作期间的值班值守工作。

2.8.3.1.服务人员要求

成交供应商运维服务人员需具备包括但不限于以下能力要求：

（1）具备良好的沟通协调能力；

（2）熟悉掌握常用办公软件的使用；

（3）熟悉操作系统及软硬件的安装、诊断和维护；

（4）熟悉服务器及主流数据库的安装及配置维护；

（5）熟悉常用编程语言，能够对数据库进行操作；

（6）遵守采购人的工作纪律，服从采购人的工作安排；

（7）运维人员资质必须经采购人审核合格后（提供复印件备查），才可上岗工作；

（8）若实际运维人员不符合工作要求，采购人有权要求更换；若运维人员有变更，需提前1个月书面通知采购人，经采购人审核同意后才可更换；

（9）运维人员必须签订保密协议，不得泄露系统数据、操作用户密码、系统设计思路、软件工作模式、系统设计、操作资料等内容；

（10）驻场运维人员的办公环境、场地、桌椅由采购人提供，其余办公所用设备及资料，如办公电脑、交通工具等由成交供应商自行承担；

（11）驻场运维人员需自备电脑（本条所称的电脑主要指：主机、显示器、打印机、以及所有的电脑网络产品和附属设备，各类应用软件等），并按采购人网络信息安全和业务设备管理的要求进行管理，当驻场运维人员调岗或离职时需移交个人电脑中与本项目相关的运维资料，未经允许不得对外透露因运维过程知悉的包括但不限于代码、业务等。

2.8.3.2.服务形式

（1）驻场服务

按照项目的需求提供驻场服务（具体人数结合项目而定），按质、按量、按时提供包括但不限于日常巡检、疑难解答、故障定位、故障排除、功能调整等服务。为完成采购人布置的任务，成交供应商应视情况安排项目运维人员驻场加班服务。

（2）远程支持

成交供应商通过电话、粤政易、远程协助等方式为采购人提供每周7*24小时电话技术支持服务，7*24小时技术咨询服务，协助采购人进行故障定位和故障排除。

（3）紧急现场服务

实行每天（含重要节假日）24小时紧急现场服务机制，成交供应商接到采购人的维护需求后，属于维护服务范围的，指派具备相应能力的技术工程师在约定时间内到达故障现场，处理在服务期内出现的重大故障或重大事件。

（4）故障处理服务

采购人在使用软件系统中遇到疑难问题或系统出现不稳定情况，成交供应商提供7*24小时故障处理服务，并在规定时间内进行故障排除，及时定位故障并进行故障处理，避免或减少由于系统故障导致的损失。

（5）值守服务

日常运维人员参照正常工作时间，实行工作日每天8小时运维制，重要节假日、活动（重大会议、重大活动、敏感时间段）期间，成交供应商需按项目需求实行7*24小时值守服务。

2.8.4.数据服务要求

2.8.4.1.数据汇聚及目录维护

（1）根据《广东省公共数据管理办法》和《中山市政务数据管理办法》，信息系统运维的成交供应商需将部门系统产生的公共数据按“应编尽编、应汇尽汇”原则编目汇聚到市政务大数据中心及省一网共享平台。

（2）对于已接入市政务大数据中心的数据，成交供应商需按时推送更新数据，按照市政务大数据中心给出的问题清单，配合整改，包括数据目录的日常更新、维护、质量提升等工作。

（3）对于未接入市政务大数据中心的数据，成交供应商需按照市政务大数据中心要求开展数据编目归集工作，及时将系统全量数据汇聚到市政务大数据中心。

（4）成交供应商开展运维工作同时需摸清每个业务系统的业务数据表底数，参照《广东省政务大数据公共数据元规范》、本行业的数据标准等规范要求，检查源头数据质量，保证数据符合标准规范。

（5）运维系统已完成对接市政务大数据中心工作的，成交供应商需将业务数据表相关联的字典表、附件表（并与业务数据表有关联字段）提供到市政务大数据中心。

（6）各单位存在用数需求，数据未推送至市政务大数据中心的，成交供应商需配合沟通并按照市政务大数据中心要求，进行数据资源编目挂接，共享发布至市政务大数据中心，以便各单位申请。

（7）历史目录或在编目录，成交供应商需要关联正确信息化系统，如存在一部分目录关联中山市核心交换平台或未关联系统的，需要与所属单位核实，规整目录对应系统，将该系统录入省普查系统，进行重新关联，目录变更发布。

（8）当部门数据发生变动时，成交供应商应主动通知市政务大数据中心，并配合进行资源目录的变更，以及数据的重新推送。

（9）成交供应商应保障部门数据与市政务大数据中心对接的稳定以及数据更新质量，当发生系统故障、网络波动、业务调整等原因导致数据无法按时更新时，或发现数据推送存在问题时，应主动与市政务大数据中心联系，并及时处理故障问题。

（10）成交供应商应充分运用市政务大数据中心平台技术能力及工具开展数据比对、数据核查等数据治理工作来满足所属部门业务需求，并将治理后的数据进行编目归集到市政务大数据中心。

2.8.4.2.数据共享

推动数字政府的建设，采购人以坚持“业务推动、技术拉动”原则，围绕实际应用、辅助决策及行政监督，挖掘丰富数据应用场景，通过业务系统申请政务数据，推动业务办理、减轻群众提供材料免填写等工作，成交供应商需提供部门申请数据和使用数据的技术支撑。

2.8.5.云资源管理服务要求

成交供应商需配合采购人对各项目落实云资源监测、云资源缩容等日常运维工作，具体工作内容如下。

1.云资源缩容工作，包括但不限于以下工作：

（1）成交供应商需配合中山市政务云平台确定缩容需求、配合执行缩容工作。

（2）成交供应商需在进行缩容操作之前，备份重要数据以防止数据丢失或损坏，备份包括但不限于所有关键数据和配置信息。及时通知相关方了解缩容计划并准备好回滚操作措施。

（3）缩容操作完成后，成交供应商需要对系统业务验证和进行持续的监控和调优，包括但不限于监控系统性能、资源利用率、业务负载等，并根据实际情况进行调整和优化，配合业主高效使用云资源。

（4）成交供应商需要记录关键的操作和步骤，以及遇到的问题和解决方案，缩容完成后，进行总结和评估，并形成记录整合到运维报告中。

（5）成交供应商应当采取必要措施（程序代码优化、数据库调优等），降低不合理，不完善，不健壮的程序代码而导致云资源被异常占用的情况。

2.云资源监测和基础运维工作，包括但不限于以下工作：

（1）明确监测需求，包括但不限于监测对象（如CPU、内存、存储、网络等）和监测频率。

（2）选择并配置合适的监测工具，包括但不限于设置监测指标、阈值、告警方式等。

（3）收集云资源的使用数据和性能数据并对其进行分析，识别出异常数据和突发事件，及时进行处理。

（4）根据数据分析的结果，制定相应的优化策略，包括但不限于调整资源配置、优化系统架构、改进应用程序等。

（5）按照优化策略实施相应的优化措施，密切关注系统的状态和性能，确保优化措施的有效性。

（6）定期生成监测报告，记录关键的数据和事件，以及实施的优化措施和效果，向相关方汇报云资源的使用情况和性能表现。

（7）在服务期限内，根据采购人需求，按时完成系统的漏洞修复，数据备份，数据迁移、安全加固、系统重新部署等日常运维工作。

（8）对历史时期建设，仍未迁移上政务云的系统进行台账梳理，制定系统迁移上云计划，并负责实施系统迁移上云工作。

2.8.6.应急响应要求

成交供应商需要根据本项目突发事件的影响程度，将服务响应的事件分为4个等级，并对不同等级的事件作出恢复、解决时间的要求，其中1级事件需在故障出现后30分钟内恢复系统正常，2级事件系统恢复时间为1小时内，3、4级事件需在2小时内恢复系统正常或给出应急处理办法；1级事件在8小时内分析故障原因，并提出问题分析报告和整改方案，2、3级事件在24小时内分析故障原因，并提出问题分析报告和整改方案，4级事件在48小时内分析故障原因，并提出问题分析报告和整改方案，各突发事件响应要求详见下表。

在突发事件发生后，为不影响业务办理，成交供应商应及时排除故障恢复系统正常，分析原因避免类似问题发生。如成交供应商多次（3次以上,不含3次）无法在规定恢复时间内（1级事件需在故障出现后30分钟内恢复系统正常，2级事件系统恢复时间为1小时内，3、4级事件需在2小时内恢复系统正常）或长时间（超过规定恢复时间的3倍）无法恢复系统正常，采购人有权单方解除合同，不予支付余下合同款项。因工作延误造成采购人损失的，采购人有权要求成交供应商赔偿。

2.9.其他要求

2.9.1.项目文档要求

1．成交供应商应订立规范的维护计划和工作流程文档，包括服务单和维护日志。在每次维护服务后详细记录故障现象、维护内容、维护日期、维护结果等资料。

2．分别按月份、季度和年度向采购人提供维护报告和维护日志，供采购人分析，为更好地开展维护服务工作提供依据。

3．维护期结束之日起30日内提交本期维护报告和对系统修改过的文档说明，包括系统架构、数据库结构、程序代码、用户需求等。

4．成交供应商项目文档管理职责：

（1）负责所辖项目文档的实时管理，负责建立文档配置库；

（2）按照合同等要求移交项目文档。

5．成交供应商应于验收后向用户提供验收报告、技术文档的归纳、整理、提交，并提供完整的软件技术资料。技术资料包括验收报告、技术文档、完整的软件技术资料。

6.成交供应商还应定期向采购人提交项目运维月报、运维年报、重大故障运维报告等。

2.9.2.工作交接要求

本项目服务期限届满，采购人如需对本项目进行重新公开招标的，在新的成交供应商进入交接工作之前，原成交供应商必须按本合同约定的服务条款继续履行，采购人按约定支付费用。否则，采购人无需向原成交供应商支付最后一期维护服务费，并保留追究原成交供应商因其未能及时完成交接手续所带来损失的权利。待采购人书面确认成交供应商已协助其完成交接手续后，采购人、原成交供应商双方进行维护服务费结算工作。

2.9.3.数据备份要求

本项目涉及的系统数据分为两部分，即省系统回流数据（由省人社厅部署）和本地数据（部署于市人社局机房）。部署在省系统的数据采用T+1数据回流，由省人社厅建立备份机制，本项目不考虑该部分数据备份问题；部署在市人社机房的本地数据，分存放于IBM AS400服务器数据和存放于公共服务器、档案服务器ORACLE数据。存放于IBM AS400服务器数据，市人社局已建立备份机制，依托于市人社机房的远程灾备和双机热备机制进行备份。存放于公共服务器、档案服务器ORACLE数据由本项目运维人员协助进行备份、检查等维护工作。

2.9.4.系统国产化信息技术应用创新适配改造要求

在本项目运维服务期间，如有政府统筹开展的国产化信息技术应用创新适配改造项目（与本项目为两个不同项目），需要采购人配合开展涉及本项目运维系统相关信息化工作的，本项目成交供应商需要免费协助其推进国产化改造，例如配合搭建运行环境，经授权后开放业务系统数据结构或开放系统源代码等辅助工作。

因改造后的系统运行环境发生变化，原有运维方案可能不适用于新系统，采购人有权根据市政数局要求，终止本项目运维服务合同，或根据市政数局分批改造上线的工作要求，对已完成国产化改造并上线使用的本项目所运维的系统从上线的次月起不予支付该系统余下月份的运维费用。

3.项目详细运维服务要求

3.1.社会保险业务信息系统维护要求

3.1.1.业务需求系统维护

业务需求系统维护包括社保核心业务信息系统、与社保核心业务信息系统实现一体化的档案一体化系统和财务一体化系统，以及其它关联系统和接口的维护。运维内容及要求如下：

3.1.2.提供社保数据应用处理服务

社保数据应用处理服务包括数据统计分析等应用工作、关联业务数据问题处理工作、运行中数据问题处理工作、完善补充数据问题处理工作、新增需求导致数据转换的处理工作等。运维内容及要求如下：

3.1.3.维护数据稽核功能

根据省系统每天下发的业务数据，维护原业务风险监控平台，维护业务风险点校验方法库的检查语句，实现通过数据检查比对，对业务进行稽核检查，防范业务风险的管理目标。运维内容及要求如下：

3.1.4.数据库、中间件等维护

社保局社保信息系统使用到的数据库类型主要为DB2和Oracle。中间件维护是指对Websphere中间件的日常维护管理和监控工作，提高对中间件事件的分析解决能力，确保中间件持续稳定运行。运维内容及要求如下：

3.2.社会保险公共服务系统运维要求

3.2.1.公共服务系统软件维护

公共服务系统软件维护包括公共服务各类软件系统（包括自助查询终端系统、自助打印终端系统、公共服务辅助系统、查询平台接口工程、内部信息发布平台、短信发送平台等）的日常维护、业务新增以及系统完善。运维内容及要求如下：

4.运维服务要求

4.1.项目运维变更流程

项目运维变更流程指在需求变更后或系统出现故障、缺陷后，对软件系统进行变更操作的流程。

需求变更时，驻场运维人员需记录用户需求并填写《需求变更记录表》，交由项目负责人确认后，由项目负责人在项目管理系统上建立新需求并指派人员实施。

而出现系统功能模块缺陷问题时，由接到用户报障的运维人员记录用户反馈问题并及时上报给项目负责人，项目负责人在项目管理系统上新增缺陷处理任务并指派开发人员进行修复，同时由测试人员跟踪缺陷修复情况。

具体系统更新/发布流程如下：

（1）驻场运维人员接收到采购人反馈后记录下反馈给项目负责人；

（2）项目负责人新建并指派任务给运维人员完成；

（3）运维人员完成任务后反馈给项目负责人；

（4）项目负责人安排测试人员/通知采购人进行测试；

（5）测试通过后反馈项目负责人，项目负责人填写系统测试/上线确认表并交由采购人签字确认，确定系统更新/发布时间；

（6）项目负责人进行版本迭代并按照采购人规定的时间进行系统的更新/发布。

如果是软件开发项目的运维阶段产生的需求变更，项目负责人需要汇总需求变更记录表并进行工作量评估，最终明确系统更新发布的时间。

4.2.项目运维管理规范

系统在运行过程中，会发生各种各样的问题，通过问题清单的流程化处理方式，可以提高各类问题的解决效率，确保系统的正常运行，并能够更好的对运行中出现的问题进行集中整理、对比、分析，以挖掘系统运行隐患。具体的问题处理过程如下：

（1）故障清单记录：故障的发现途径有多种情况，如用户提报、系统自动警告、预警、日常维护人员发现等等。在本项目中统一由日常维护的值班人员进行故障清单的填报，详细记录故障现象、维护内容、维护日期等，根据问题严重程度，进行等级划分，包括一般问题、故障、事故、重大问题。

（2）故障清单转发：根据问题的严重程度，将问题转发至相关部门。如：故障类问题直接由运维人员处理；事故及重大事故需要转发给项目经理并汇报给用户。

（3）故障处理分派：项目负责人协调各个成员组，共同分析问题所产生的原因，制定解决方案，明确责任分工，进行分派处理。

（4）问题清单反馈及跟踪：问题在处理完毕之后，进行结果验证，明确问题的解决情况，并进行跟踪。

（5）订立规范的维护流程和完善的文档，包括服务单和维护日志。在每次维护服务后详细记录维护单位、故障现象、维护内容、维护日期、维护结果等资料。定期向采购人提供电子版的维护报告和维护日志，供采购人分析，为更好地开展维护服务工作提供依据。

（6）定期向采购人提供维护报告和维护日志，供采购人分析，为更好地开展维护服务工作提供依据。

（7）驻场运维人员不得利用工作之便，进行任何非法或非本项目范围内的活动，特别是发布非法信息，留下系统后门等。

5.付款方式及考核办法

5.1.付款方式

1)成交供应商在与采购人签订合同后，在满足以下支付条件下，成交供应商须同时提供相应付款额的发票正本一份及付款申请书一份，成交供应商未提供发票及付款申请书的，付款时间相应顺延，顺延至采购人收到成交供应商提供发票和付款申请书之日起30个工作日内。

2)本项目合同款，由采购人分期支付成交供应商。

3)具体支付方式和时间如下：

1.本项目服务期共36个月。

2.合同款分6期支付，服务期开始后每满6个月之日起30个工作日内，采购人分别向成交供应商支付合同款总额的六分之一。

4)付款方式：银行转账。

5.2.考核方式

l ★服务期开始后15天内为试用期。若成交供应商在试用期内未能配齐符合采购人需求的维护人员，则视为成交供应商主动违约，采购人有权终止合同。

l 在服务期间，成交供应商调走驻场维护人员、驻场维护人员不符合项目要求、维护人员辞职或被成交供应商辞退等，而成交供应商在一个月内未能及时补齐符合项目要求的人员时，则视为成交供应商主动违约，采购人有权终止合同，并有权拒绝支付当期合同款。

l 因成交供应商维护人员误操作造成重大故障、蓄意破坏信息系统设施、发布非法信息或造成泄密事件的，一经查证，则视作成交供应商严重违约，采购人有权终止合同，并扣除当期维护费作为罚款，追究其法律责任。

l 若成交供应商在单月内违反其服务承诺或本磋商文件要求三次或以上，则视为成交供应商违约，采购人有权拒绝支付当月维护费。

l 成交供应商应建立和健全质量保证体系，加强程序维护人员的管理工作，确保所提供的程序能够按采购人需求准确和稳定运行。如果因为成交供应商原因（如程序维护人员不认真负责编写和测试程序），造成采购人出现社保基金多支错支的情况，多支错支金额超过合同金额的10%，则视作成交供应商严重违约，采购人有权单方解除合同，无需向成交供应商支付剩余合同款项，并可进一步追究成交供应商赔偿责任。

5.3.运维达标考核细则

为提升本项目系统运维服务的质量，特制定了相应的考核管理制度。通过采用不同的考核维度、不同的测评指标，从而从不同角度、不同方面对考核对象实现公平公正公开的考核。

对于目标值越大越好的指标，当实际值大于或等于目标值时，得100分；当实际值小于目标值，但大于或等于目标值的90%时，得80-95分，每偏差0.5个百分点降1分；当实际值小于目标值的90%，但大于或等于目标值的80%时，得60-79分，每偏差0.5个百分点降1分；当实际值小于目标值的80%时，得0分。

对于目标值越小越好的指标，当实际值小于或等于目标值时，得100分；当实际值大于目标值，但小于或等于目标值的110%时，得80-95分，每偏差0.5个百分点降1分；当实际值大于目标值的110%，但小于或等于目标值的120%时，得60-79分，每偏差0.5个百分点降1分；当实际值大于目标值的120%时，得0分。

关键考核评价指标

为了进一步加强采购人的维护管理工作，提高系统运维技术的质量和水平，成交供应商须每半年接受一次对运维工作进行的运维评价，将每项评价结果进行统计考核，考核细则如下：

每项评价总分为100分，评价结论分为良好、合格和不合格。

l 评价得分≥90分时，成交供应商的评价属良好；

l 90分>评价得分≥60分时，成交供应商的评价属合格，并对扣分项进行通报批评，如同一扣分项连续出现通报批评的情况，采购人将在支付费用时按照当次支付运维费用扣除10%作为罚款；

l 评价得分≤60分时，成交供应商的评价属不合格，采购人将在支付费用时按照当次支付运维费用扣除30%作为罚款。

6.项目验收

1）成交供应商完成技术服务工作的形式：成交供应商按合同要求提供服务，合同服务期满，整个项目验收时，按照合同要求移交全部项目文档（包括验收报告、技术文档、完整的软件技术资料等），由采购人书面验收合格。

2）技术服务工作成果的验收标准：成交供应商按合同要求提供服务，按照合同要求移交全部需求过程文档。

3）技术服务工作成果的验收方法：成交供应商应于服务期结束后7日内提交验收书面申请。采购人收到验收书面申请后7日内组织验收并签署《项目验收报告》。                                    

4）如采购人对成交供应商某次提供服务的质量有异议，须在成交供应商提供当次服务后的7日内以书面方式向成交供应商提出，成交供应商将根据合同要求进行整改。

5）验收的时间、地点和人员：运维服务期届满后7日内成交供应商应向采购人提交书面验收申请，采购人同意后进行验收，验收小组成员应包括项目相关各科室负责人员，必要时可邀请专业技术人员参与验收。

6）本项目需按要求提供以下项目验收资料（包括但不限于以下材料）：

7.安全生产要求

1）成交供应商是外包业务安全生产管理主体，对所承包业务安全生产管理工作负全责。

2）成交供应商负责日常安全生产管理，采购人只负责对成交供应商进行考核和必要的监督检查。

3）按“谁聘用、谁负责”原则，成交供应商负责从业人员安全教育培训工作。

4）劳动保护用品发放由从业人员劳动关系所属单位负责。即由成交供应商负责采购及发放。

5）工伤保险是国家强制险种之一，工伤保险应由成交供应商负责购买。

6）若外包业务发生生产安全事故，事故处理及赔偿由成交供应商负责，采购人予以必要协助。

7）成交供应商执行采购人关于营业制服、外勤工作服款式、颜色的规定，采购及发放由成交供应商直接负责。

8）业务外包所涉及的安全生产费用由成交供应商负责，采购人的委托维护价格已含从业人员安全教育培训、劳动防护用品费用等。

8.保密条例

1）应遵守采购人各项规章制度、工作流程和安全保密规定, 接受采购人日常工作管理，做好安全检查与防范工作。驻场人员应按照采购人要求签署保密协议，承担安全保密责任和义务，并通过人防和技防手段确保运维过程中产生的各类交易信息数据安全保密。

2）数据保密。在本项目中涉及到用人单位和个人的隐私资料，按照《中华人民共和国社会保险法》规定应当依法为用人单位和个人的信息保密，不得以任何形式泄露。成交供应商必须做好相应的安全保密措施，确保数据不外泄。成交供应商必须保证项目中的所有数据信息仅用于本项目，未经采购人书面同意，不得直接或间接以告知、公布、发布或者其他任何方式使用本项目的有关数据。成交供应商应保证参与项目的本方工作人员严格遵守此保密规定，如违反此保密规定，应承担由此引起的一切责任。成交供应商须采取相应的安全措施以遵守和履行上述条款所约定的义务。

3)成交供应商对采购人所提供的所有资料以及在合同签订、履行过程中所接触到的采购人及其关联公司的商业秘密、技术资料信息等资料和信息(统称“保密资料”)负有保密义务。未经采购人书面许可，成交供应商不得向任何第三方披露，不得将保密资料的部分或全部用于本合同约定事项以外的其他用途。成交供应商有义务对保密资料采取不低于对其本身商业秘密所采取的保护手段予以保护。成交供应商可仅为合同目的向其内部有知悉保密资料必要的雇员披露保密资料，但同时须指示其雇员遵守本条规定的保密及不披露义务。

4)成交供应商仅可以在履行合同之目的对保密资料进行复制。成交供应商不得以任何方式（如软硬盘、图纸、彩样、照片、菲林、光盘等）留存保密资料。成交供应商应当在完成委托事项或本合同终止或解除时将保密资料原件全部返还采购人，并销毁所有复制件。成交供应商应当妥善保管保密资料，并对保密资料在成交供应商期间发生的被盗、泄露或其他有损保密资料保密性的事件承担全部责任，因此造成采购人损失的，成交供应商应负责赔偿。

5)当出现下述情况时，本条对保密资料的限制不适用。当保密资料：

1.并非成交供应商的过错而已经进入公有领域的。

2.已通过该方的有关记录证明是由成交供应商独立开发的。

3.由成交供应商从没有违反对采购人的保密义务的人合法取得的。

4.法律要求成交供应商披露的，但成交供应商应在合理的时间提前通知采购人，使其得以采取其认为必要的保护措施。

6)如成交供应商违反合同关于保密的约定，成交供应商应赔偿因此而给采购人造成的一切损失。

7)本保密条款自保密资料提供或披露之日起至永久有效。

9★报价清单：

中文大写金额用汉字，如壹、贰、叁、肆、伍、陆、柒、捌、玖、拾、佰、仟、万、亿、元、角、分、零、整（正）等。

投标报价的小数点后保留两位有效数。

此表须附在响应文件中。

备注：本项目要求总报价及各分项均需进行报价。

说明

打“★”号条款为实质性条款，若有任何一条负偏离或不满足则导致投标无效。

打“▲”号条款为重要技术参数，若有部分“▲”条款未响应或不满足，将导致其响应性评审加重扣分，但不作为无效投标条款。