受四川省农村信用社联合社委托，四川五洲招标代理有限公司将对四川省农村信用社稽核管理系统（二期）采购项目 (招标编号：SCWZDL-201304-SCNX01)进行邀请招标。为了保证采购当事人合法权益，确保采购程序公开、公平、公正，现就该项目的资格条件和技术需求广泛征求意见。
一、招标编号：SCWZDL-201304-SCNX01
二、项目名称：四川省农村信用社稽核管理系统（二期）采购项目
三、项目简介：详见附件
四、资金来源：企业自有资金，已落实
五、投标人应具备的资格条件：
1、具有独立法人资格，注册资本金不低于500万元；
2、投标人应是产品的原厂商；
3、有较好的本地化服务支持。
六、投标人在报名时须携带：
1、经过年检的营业执照副本；
2、组织机构代码证；
3、税务登记证（国税、地税）；
4、法定代表人授权书；
5、投标邀请书。
七、项目简介及技术要求：详见附件。
八、征求意见截止时间：2013年4月22日17:00（北京时间）。
九、如您认为该项目的资格条件和技术需求存在倾向性或不合理性，请具体指出存在倾向性或不合理性的内容，并进行说明。所提意见请在2013年4月22日17时前，以书面形式反馈至招标代理机构。非常感谢您的参与。
十、采购代理机构：四川五洲招标代理有限公司
地 址：成都市武侯区星狮路511号大合仓C区415
联 系 人：何先生
联系电话：028-85446608、85445511-8802；
传 真：028-85431100
四川五洲招标代理有限公司
2013年4月16日
附件：
项目简介及技术、服务要求
本招标文件提出的技术规格及要求，是根据四川省农村信用社稽核管理系统（二期）规划和建设实际需求编制的。投标人应仔细阅读。
一、概述
我社稽核管理系统一期项目于2008年3月立项，2010年1月全面上线至今，充分发挥了计算机的数据处理优势，提高了稽核风险预警和排查能力，改进了稽核手段，进一步规范了稽核操作，促进了稽核效率和质量的提高。
目前随着我社业务规模的不断扩大，新的金融产品和服务不断推出，相应的业务系统陆续上线，稽核管理系统依托的数据环境发生了巨大变化，原有系统不能完全覆盖财务、信贷、资金、清算、电子银行等业务系统数据，数据挖掘、分析的深度和广度受到限制，亟需提高。同时稽核工作模式也出现了较大的变革，对稽核审计业务管理的科学性和规范性提出了更高的要求。为了尽快适应审计客体和审计主体的变化，保障审计工作质效，提高审计工作效率，需通过稽核管理系统二期建设对一期系统进行优化升级，以满足当前审计工作需要。
稽核管理系统是专为农村信用社稽核审计人员定制的系统，系统二期项目的建设需严格遵循我社信息系统建设的相关要求，同时，还需充分考虑与正在使用的一期系统的兼容性和已开展审计工作及审计成果的延续性。
2.1 总体要求
稽核管理系统二期主要是基于我社一期系统进行扩展和升级，建立单独的审计中心数据库，引入核心系统、财务管理系统、贷款业务系统、小额农贷系统、评级授信系统、账户管理系统、ECIF系统、报表报送系统、身份核查系统、集中报送系统、客户关系管理系统、渠道类系统等多个系统的数据，并利用灵活的建模工具和高效的数据分析处理引擎，按照先进的审计思路，对引入数据进行分析，及时、科学、准确地发现业务办理和日常管理中存在的风险隐患和问题线索，为现场审计提供详实的线索和依据，进一步提高审计质效，降低审计成本。
系统总体要求包括：
1. 根据信用社业务种类、业务特点和业务风险程度，通过灵活的系统配置，采用“T+1”或“T+N”的模式，自动抽取包括核心系统、财务管理系统、贷款业务系统、小额农贷系统、评级授信系统、账户管理系统、ECIF系统、报表报送系统、身份核查系统、集中报送系统、客户关系管理系统、渠道类系统等在内的各系统原始数据。
2. 建立覆盖全面、重点突出的风险监控规则，根据信用社业务种类、业务特点和业务风险程度，通过灵活的系统配置实行“T+1”或“T+N”的监控方式；建立强大的业务查询体系，满足审计人员对所有业务数据多角度、自定义的数据查询需求；建立丰富的风险模型体系，按既定规则筛查风险线索和可疑问题。
3. 面向审计人员提供便捷易用的模型探索与开发工具，支持审计人员自主开发和管理审计模型。
4. 提供完善的任务调度功能，对审计模型的运行进行灵活调度管理，并支持对风险模型按照一次性、日、周、旬、月、季、年等不同频率的自动运行管理。
5. 结合四川省农村信用社多级法人体制、业务特点以及未来发展要求，借鉴国内外同行成熟的技术和经验，建设一个较完善的项目管理，风险评估、预警、监测和防范的平台。
6. 按照我社审计准则和审计程序要求，提供审计项目流程自定义功能，实现审计项目的标准化与流程化管理，通过标准审计文书模板定制，使工作底稿、问题事实确认书、审计报告等审计文书的内容规范、格式统一，提高文档质量。
7. 系统主要功能包括工作台、现场审计、非现场审计（含监控、查询和风险模型）、审计整改、内控评价、综合管理、审计知识库、系统管理等几大部分。
8. 系统需根据审计工作需要提供覆盖我社各项业务的审计工作指引功能及配套内容。
9. 系统需具备强大的信息安全保障，多方位防范数据泄密风险。
10. 系统需支持对文档的在线编辑，保留文档编辑痕迹，实现版本化管理。
11. 系统需具备在线与离线相结合的版本，使用便捷合理的数据同步机制满足脱离网络环境下的现场审计工作的需要。
12. 系统需支持多级审核审批机制，并可实现灵活调整。
13. 系统需体现界面友好性、操作人性化及可个性化设置，关键功能支持图形化展现。
2.2 工作台
2.2.1 待办任务
待办任务中提示当前操作人员待处理的工作，包括待审批的申请、待实施的审计项目等等。
2.2.2 消息通知
系统以信息推送的方式，将包括模型运行结果、预约查询结果、指标监测预警信息、最新待办任务、系统公告等消息，及时醒目地提醒当前操作人员，并提供对已阅信息的查询功能。
2.3 现场审计
按照审计准则、相关审计规范，实现现场审计作业的规范化、标准化、流程化以及审计文档的在线审核和传递；实现从审计计划、审计实施、审计报告、问题整改、质量控制、审计成本等环节的规范管理。
a)
2.3.1 审计计划
审计计划是审计项目实施的前提。审计计划需提供计划编制、维护、调整及跟踪等功能，并支持审计计划与审计项目之间的关联，查看计划的具体实施情况。
2.3.2 审计实施
实现审计项目的管理，包括但不限于常规审计、专项审计等多种类型的审计项目。能够为审计管理人员提供项目立项、审计准备、审前调查，审计实施、审计报告、现场整改、审计终结、后续审计等功能，实现项目流程化管控与实时调整，支持现场审计项目的业务数据配置及相关数据预处理，提供多元化的审计抽样工具，提供审计工作指引，审计步骤、审计方法检索，制度标准、罚则的自动引用；非现场可疑数据、待查事项、历史审计成果可引入现场立项查证，使审计项目管理规范化、科学化、系统化。
审计实施过程强调现场审计与非现场审计的彼此结合，系统必须支持将非现场审计的结果引入至现场审计项目中，作为现场审计的数据依据。
在项目实施过程中提取非现场数据时，系统需支持数据预处理，支持实时提取、非实时提取和外部导入业务数据等，支持对待配置的业务数据进行夜间跑批，减轻系统在白天的运行压力。
2.3.3 审计专题
系统支持按照标准业务条线进行专题分类，可将常用的审计模型，根据审计重点的不同，灵活组合，提供多角度的审计模型的组合模板，建立不同的审计专题，如年终经营真实性审计、领导干部经济责任审计、财务费用审计、固定资产管理审计等。审计专题中配置的待查业务的风险模型既可以在立项时直接调用，也可以作为风险监测模型自动定期运行。
2.4 非现场审计
1、查证分析
利用系统提供的自定义查询、定制查询、指标监测、风险模型、抽样模型等查证分析工具将原始生产数据进行多角度灵活分析、疑点问题核对，对交易流水、日志、明细账、总账、报表、进行自动勾稽，对总账关系、资金流向、关联关系、客户信息等进行分析，查找违规行为、潜在风险及异常情况，通过多维分析模型分层次筛选、钻取与综合预测分析，实现快速审计目的。
系统的查询分析过程要求实现图形化的拖拽式简便操作。
2、预警监测
预警监测功能支持审计模型按设定的频率对监测事项进行定期检查，并将风险监测的结果以图表、消息推送等预警的形式展现给审计人员，同时审计人员也可通过模型单跑实现对特定事项的一次性、临时性的监测。审计模型可按地区、机构、业务条线、业务品种进行分类，运行的周期和频率可手动进行设定；并可根据需要自动生成风险提示报告及非现场审计报告。
3、风险地图
系统根据预警监测的结果，以地图的表现形式，按地区、机构、业务条线、业务种类、风险类型等多角度多维度进行直观展现，用于确定审计方向和审计重点，指导审计项目的选择，同时也支持常态化审计监控，并能通过点击风险地图按机构进行逐层钻取。风险地图能够按省、市、县三个层级进行设置，体现不同层面的业务范围和关注重点。
4、疑点处理
系统支持审计专题及预警监测运行结果的全流程处理，包括疑点库管理、相关后续处理及疑点结果跟踪等功能，实现非现场审计结果流程化管理，并支持疑点信息结果反馈和自动生成疑点处理报告。
2.5 审计整改
对于审计检查工作中发现的问题，系统提供两种方式对整改情况的追踪反馈。一是对可量化的问题台账，由系统自动识别整改情况，更新整改状态；二是对不可量化的问题台账，提供整改情况录入接口，并支持相关附件的上传。除此之外，系统还需提供从机构、审计人员、违规人员、业务种类、违规问题等多维度的问题整改率的查询统计功能。对屡查屡犯、久拖不改的违规问题，系统可自动生成处罚意见，交由人事部门进行处罚。
2.6 内控评价
按照监管机构相关要求及四川农信内控制度，依托系统建立全社内控评价体系，灵活制定内控评价规范与标准，并可根据我社实际情况进行灵活调整。可以实现评价分值汇总算法及权重关系进行灵活定制，支持部分评价指标自动计分，实现定量与定性有机结合。
支持内控评价项目的流程化管理及项目流程配置，支持内控评价流程的图形化展现，系统可为内控评价项目提供丰富的数据配置工具，支持历史审计结果及评价结果的引入运用，支持内控评价配置预处理，自动生成评价底稿、评价报告等。
b)
c)
i. 评价项目
内控评价项目的实施流程可进行配置，一般来说，包括项目立项、评价方案准备、任务分配、过程评价、结果评价、内控评级和报告以及项目结项等几个环节。在过程评价环节中，可利用以往审计发现作为评分的参考依据，结果评价可利用系统运算的指标结果对各项结果评价指标进行自动评分。
ii. 评价模板
内控评价模板是进行内控评价的标准，评价模板由各个评价点组成，评价点中描述了具体的评价内容、评分方法、评分标准等等，针对不同类型的评价对象可设置不同的评价模板。
2.7 综合管理
d)
2.7.1查询统计
系统需能够按审计机构、审计人员、审计项目、被审计机构、业务种类、审计问题、违规人员、审计整改、审计覆盖率等不同维度对审计项目、工作底稿、问题台账、审计报告等进行查询和统计，并可实现从审计项目、业务种类、业务环节、控制点、问题台帐等层次查询结果的钻取。
系统应具有完善的综合查询功能，对各类预警监测信息提供便捷的关联查询以及灵活的自定义查询，用户在使用查询功能时，可根据实际情况自行确定采用实时查询或预约查询的模式，同时，针对农信业务特色和审计业务特色，系统还应初始化提供各类高效的常用查询主题，为审计人员提供常用查询服务。
除此之外，系统还应具备与其他系统如影像管理平台、后督系统、远程视频监控的调用接口，实现对票据影像、实时业务场景等信息的远程调阅查询。
2.7.2报表服务
报表服务功能为审计人员提供了一套便捷的报表配置工具，可实现审计所需的各类复杂格式报表编辑配置，并根据不同的报表类型及组织机构级别进行报表分类，对不同类别的报表赋予独立的查阅权限，并能够将报表自动转换为文字报告。
2.7.3考核评价
系统能够根据四川农信相关的规章制度，设定和维护量化的考核评价指标和内容，实现对联社审计部门、审计人员工作情况以及审计项目质量的考核评价。
2.7.4积分管理
系统能够提供员工违规积分管理功能，并可按业务条线、岗位进行统计违规积分，积分结果审核后，自动推送人事部门执行。
2.7.5流程配置
为各类流程化的工作提供流程的配置管理，包括审计项目流程、内控评价流程、项目质量评价流程、考核管理流程等等。
2.7.6模型管理
系统提供可视化的建模平台，将审计思路转化成审计模型，对我社各项业务数据进行全面、深入的分析，发现审计对象存在的问题、疑点和异常情况。模型定制平台应至少具备数据提取、两表关联、多表关联、数据采样、数据排重、数据分层、取唯一值、字段维护、分组汇总等模型开发工具，在关键步骤实现拖拽等图形化简便操作，支持模型中间步骤的插入删除、模型步骤调整、模型脚本汉化处理等，具有完备可行的模型跑批效率优化方案。
模型管理由模型探索、模型验证、模型投产以及模型单跑四大部分组成，需支持对模型质量的验证审核过程，并支持提交投产后的参数调整，能够对模型运行结果的有效性和实用性进行查询统计。
模型支持对外部数据导入和分析功能。
2.7.6.1 模型探索
审计人员通过模型探索功能，利用模型开发工具，将审计业务思路落地转化为审计模型，并可对审计模型按步骤根据结果进行探索与调整，逐步修正审计模型思路，达到提交验证和投产的条件。
2.7.6.2 模型验证
支持对一个待验证审计模型的名称、描述、风险级别等基本信息进行修改。在模型验证阶段，有验证权限的用户可以对模型基本信息进行修改。若验证不通过，将待验证模型退回到探索中状态，由模型创建者对模型基本信息、步骤、参数等进行调整。若验证通过，可直接提交投产。
2.7.6.3 模型投产
支持对已投产模型的维护，实现版本化管理，能够查询模型的更新轨迹。可以将已经过期无效，不再有使用价值的已投产模型设置为已失效状态。失效后的模型只能查看基本信息、查看步骤、在探索过程中另存。失效模型可以通过激活重新启用。
2.7.6.4 模型单跑
支持将模型单独执行，实时查看单跑结果。模型单跑需建立严格权限限制。
2.7.7数据管理
实现对我社核心、信贷、财管等各系统、各环节业务数据的的自动抽取和加载，并预留数据接口，满足对新增业务系统数据抽取分析的需要，形成审计需要的基础数据中心，同时，还应提供对Excel、TXT等常用格式数据文件的临时导入功能。
2.7.8在线授权
操作人员通过在线授权申请功能，向管理员申请数据导出下载、敏感信息查看、流程调整等操作权限。
2.8 审计知识库
2.8.1模版库
知识库须提供包括审计思路、审计方案、工作底稿、事实确认书、审计报告、处理决定书、整改报告等各类型的文档模版，以支持现场和非现场审计项目,审计人员在实施审计项目时，可直接调用文档模版生成相关文档。
e)
2.8.2资料库
提供问题词条体系维护、内外法规规章制度库维护、审计资料库、案例库、专家经验库、审计工作指引库的维护等功能，并支持各类信息栏目的分类与文章发布管理、审计管理过程中文件档案和知识经验的维护与管理。
2.8.3词条库
问题词条是用于准确定义审计发现问题的标准化词语，问题词条体系是将问题词条和以业务流程为核心的风险矩阵结合而成，整个问题词条体系按照业务种类、业务单元、业务环节、风险控制点、问题词条来构建。问题词条应进行风险等级分类和版本化管理。问题词条体系在知识库中梳理完毕后，审计人员在工作底稿中记录审计发现的问题时系统自动关联标准问题词条，审计人员审核后引用。系统在审计报告和查询统计的时候能够自动按照不同的业务种类、业务单元、业务环节、风险控制点、问题词条来进行分类汇总，在内控评价模块就可以按照风险控制点进行量化打分。
2.8.4学习平台
系统为审计人员提供相关业务知识的在线学习与考试平台，平台中的学习内容可由管理员进行定制管理，审计人员学习完之后，系统自动记录、统计汇总学时学分，学习情况和考试结果作为对审计人员考核的参考依据。
2.8.5信息交流
为审计人员提供一个开放的交流平台，促进审计人员之间相互学习、取长补短、增长知识。
2.9 系统管理
1.1
1、机构管理
系统中将机构划分为审计机构和被审计机构两大类，机构管理功能提供对这两类机构的基本信息维护，机构的维护须遵循我社机构员工主数据的规范与标准。
2、用户管理
提供针对审计人员及部分高管人员的系统用户基本信息维护，用户维护须遵循我社机构员工主数据的规范与标准。
3、权限管理
用户权限分为系统功能权限和数据访问权限两部分，系统功能权限控制用户对系统功能的使用，数据访问权限控制用户只能看到被授权的数据信息，包括审计业务数据以及引入的各系统原始业务数据。
4、任务调度
后台任务调度管理功能为系统管理员提供可视化的后台任务监控及调度功能，后台任务包括数据加载任务、风险监测任务、审计模型任务、预约查询任务等等，系统管理员可根据情况对任务队列中的具体任务进行启动、停止、优先级调整等的调度管理。
5、监控管理
系统监控管理功能通过可视化界面向系统管理员提供系统后台硬件资源的监控，包括表空间、存储空间、CPU、内存、系统文件目录等的使用情况，并且系统管理员可配置各项监控内容的预警临界值，如超过预警临界值，系统将通过短信平台接口向系统管理员发送预警短信。
6、参数配置
系统管理员通过参数配置功能对系统基础参数进行维护配置，如风险地图配置、数据导出条数配置、系统运行监控配置等等。
1.2
2.10 其它功能
2.10.1脱机支持
考虑到现场审计工作的特点和实际网络情况，系统必须配套提供离线版本的单机工作平台，满足在脱离网络环境下的审计工作的需要。
单机工作平台的功能必须包括底稿编制、复核、事实确认书管理、问题台账管理、项目文档管理等功能，并支持在具备网络环境下自动与稽核管理系统后台数据库进行数据同步。
2.10.2智能化的文档处理
系统以完善的问题词条为核心，贯穿审计将项目任务查证的全生命周期，可准确生成各类审计统计报表，自动整理生成事实确认书、违规人员初步处理意见书和审计报告等规范性文档。
2.10.3个性化界面管理
提供可调整、可配置的个性化界面设计，体现审计人员的操作习惯。
三、技术要求
3.1系统总体架构
稽核管理系统面向全省范围内的稽核审计人员提供日常稽核工作管理、稽核项目实施以及针对各源系统业务数据的分析与查询服务，其中针对各源系统数据的模型运算、数据分析与查询通过数据运算处理引擎，基于稽核管理系统独立的审计中心数据库完成，审计中心数据库中的数据通过ETL工具定期从数据仓库系统、核心业务系统、贷款业务系统等各源系统抽取，并且ETL需支持方便地对数据源进行扩展。
审计管理系统的应用通过办公网络、VPN进行访问，并且从技术架构上须支持对移动终端的扩展，同时，系统还需实现与已有员工门户系统、机构员工主数据系统、短信平台的数据接口以及对影像平台的实时调阅查询接口。
3.2总体技术要求
1. 系统设计必须符合SOA整体架构规范，按照标准J2EE框架进行开发和部署，具备跨平台特性。程序开发、部署应按照我社的《J2EE集群应用技术架构规范》执行。
2. 支持主流操作系统平台（本项目中必须支持AIX、HP-UX、Linux）、数据库产品（本项目中必须支持DB2）、中间件平台（本项目中必须支持weblogic平台上的应用集群部署）及主流硬件厂商设备。
3. 统一的系统架构和应用平台。
4. 界面开发必须严格遵循我社的《B/S架构系统用户界面规范》执行。
5. 机构的管理必须严格遵循我社的《机构编码及层级汇总规范》执行。
6. 系统必须按照我社的《门户系统整合开发规范》与我社的门户系统进行整合。
7. 数据抽取、转换、装载的设计和实现必须严格遵循我社的《ETL编程规范》执行。
8. 业务流程定制方便快捷，能够根据不同业务需求实现各类分级任务流程的定制和管理；
9. 系统具备良好的扩展性、可配置性、开放性、可用性，能对新增或变更需求快速响应，提供完整的接口，二次开发等相关文档资料，进行全面的技术转移。操作界面统一、简洁、友好，响应时间合理可控，符合我社员工操作习惯；
10. 系统必须提供良好的用户管理、运行监控及日志管理，易于管理人员维护、排错。
11. 系统必须具有严密的安全体系，传输的数据应安全可靠，实现数据的一致性及无差错运行。
12. 系统必须实现表级、记录级、字段级的数据访问安全控制，并提供灵活方便的数据访问权限配置功能。
13. 随着系统数据的增加，系统必须提供良好的海量数据处理的能力，有效提高系统的性能。
14. 系统支持客户端零维护、自动安装升级。
15. 系统必须从技术架构上支持对移动终端的扩展。
16. 我社新一代核心业务系统计划于明年上半年切换上线，贷款业务系统计划在今年内陆续完成全省范围的推广上线，稽核二期项目建设时必须实现对这两个系统的数据引入和风险业务监控覆盖。
17. 系统应具备良好的扩展性，能够灵活、快捷地接入新业务或新系统数据。
3.3模型开发工具要求
针对稽核审计人员需要自行进行审计模型探索的需求，稽核审计系统需要提供一套方便易用的可视化的模型与指标的开发工具，帮助稽核审计人员完成从业务思路到实际审计模型的落地实现。
3.4用户及机构体系构建要求
我社已建立统一的用户、机构数据体系，形成唯一的机构员工视图，并通过主数据系统进行统一管理。要求系统在开发过程中严格遵循我社的统一规则和标准构建系统内部机构、用户体系，实现与机构、员工主数据系统之间的服务交互和数据同步。
3.5系统数据存储与处理要求
针对我社业务数据量较大，要求具备科学实用的存储设计，支持10-15T规模数据的存储及高效运用。系统对业务数据的保存时间要求，按照业务特点和审计关注点具体分析、区别对待，以确保保存的数据能充分满足审计需要，并在此基础上，合理采用分表、分区等方法，提高模型运算、数据查询的效率，同时还应提供灵活便捷的针对历史数据的临时加载导入的技术手段。
稽核管理系统将根据信用社业务种类、业务特点和业务风险程度，通过灵活的系统配置，采用“T+1”或“T+N”的模式对数据仓库等各个源系统的数据进行采集和分析处理，实现对业务的风险监控，系统提供对后台数据处理任务的界面化监控及调度管理功能。
数据处理必须遵循我社ETL编程规范和数据仓库建设相关标准与规范，每天的ETL、风险模型监控等日终处理时间要求保证在6个小时之内完成，默认情况下日终处理任务在非工作时间运行，系统管理员可根据需要，通过后台任务调度管理功能在工作时间调度任务运行。
3.6系统性能要求
系统在全省上线后，日使用人数约1500人左右，因此在系统设计时，必须充分考虑多用户并发操作时的系统性能，在操作响应时间和响应正确率等技术指标上达到我社要求，正常情况下，除针对大数据量（单表数据量在百万级以上）的业务数据的查询、统计之外，其余操作响应需在1秒内完成（以应用服务器接收到前端请求到向前端发出响应为准），操作响应的正确率需保持在99.5%以上。
对于针对大数据量的业务数据的查询、统计等耗时较大的操作，系统在设计时还需充分考虑用户的使用体验，采用包括异步处理、预约查询、消息推送等机制，提高系统用户在使用此类功能上的感受以及工作效率。
系统必须保证在后台进行大数据量查询、分析等处理时，对系统资源进行合理的分配使用，避免因后台数据处理任务占用系统资源过多，影响到前台业务功能的正常使用。
3.7与外部系统接口要求
系统需要实现与我社已有员工门户系统、机构员工主数据系统、影像管理平台、短信平台的数据与服务接入，还需考虑并预留接口扩展。
3.8系统运行监控要求
稽核管理系统对资源的占用要求比较高，在使用的过程中，容易出现表空间、磁盘空间不足、后台任务占用资源过多等造成前台应用服务响应速度缓慢的情况，系统除提供对后台硬件资源的界面化的监控功能之外，还需具备对资源占用达到临界点时的短信预警功能。
3.9对离线工作的支持
考虑到现场审计工作的特点和实际网络情况，系统必须配套提供离线版本的单机工作平台，满足在脱离网络环境下的审计工作的需要。
3.10系统容错性要求
系统设计时必须充分考虑容错性，避免出现因高并发的查询操作导致后台应用服务停止响应等问题的出现。
3.11系统兼容性要求
稽核管理系统设计开发时必须考虑到对一期系统的兼容性和已有审计成果的延续性，系统上线时，实现对一期系统的无缝切换。
3.12后续建设要求
稽核管理系统建成后，为应对业务发展带来的变化，在投标文件中需详细阐明系统后续建设的思路，并给予落地实施的方法。
4.1项目建设周期要求
本项目建设周期要求从进场实施到开始上线试运行，最长不超过10个月。
4.2项目实施人员要求
本次项目建设必须提供稳定的人员团队保证，投标人须以前期参加POC测试的核心人员为班底针对本项目成立一个项目组，项目控制主管和项目经理不允许变动，其他项目组成员变动必须提前一周向招标方提出正式的书面申请，经招标方代表同意并签字确认。要求提供详细的实施人员清单，针对人员角色、背景经验、相似项目经历、技能特长、负责实施范围等进行详细说明，项目实施人员中至少应包括如下角色：
1、项目控制主管：负责指导、控制系统各阶段的业务、技术工作（包括对其公司内部人员、业务、技术问题的统一协调、管理），并进行相关的咨询顾问支持工作。
2、项目经理：项目经理必须具有相似项目的项目管理经验，具有很强的项目组织能力和管理能力，直接对项目的实施负责。同时，通过对工期、成本、质量的控制（包括总体制定、执行、跟踪、调整相关计划，协调项目可用资源），确保按要求完成。
3、技术专家：技术专家应具有相似项目的设计或实施经验,至少包含应用设计及数据处理专家。
应用设计专家负责系统技术框架设计，指导项目成员按规范进行设计、开发、测试等。要求熟悉AIX 、HP-UX、Linux操作系统、WebLogic集群环境、DB2数据库系统，具备J2EE系统设计开发能力。
数据处理专家应参与过ODS或数据仓库建设，具备丰富的海量数据（单表数据量上亿规模）处理及优化经验，负责系统数据组织设计，相关数据环境搭建，数据处理等，指导项目成员按规范进行设计、开发、测试等。要求熟悉AIX 、HP-UX、Linux操作系统、DataStage、DB2数据库系统等。
4、业务专家：熟悉相关业务，协同招标方业务人员完成包括：需求分析、需求评审、设计评审、系统操作培训等各项任务，并配合开发人员负责准备测试方案、测试计划，协助完成测试阶段相关工作等。
5、系统开发人员：整个项目工程实施的主体，参与项目各个阶段的工作，完成项目的实施任务。
6、模型开发人员：熟悉银行业务，具备一定的数据库知识，具有丰富的模型开发和调试经验，负责协同招标方业务人员完成模型需求的分析、评审以及模型的开发验证工作。
7、测试人员：负责系统测试。
8、运行支持及维护人员：负责系统上线后的客户应用支持、后台系统稳定运行支持等。
各角色人数要求如下：
|
角色 |
人数要求 |
备注 |
|
项目控制主管 |
1名 |
|
|
项目经理 |
1名 |
|
|
技术专家 |
1-2名 |
可兼任 |
|
业务专家 |
至少1名 |
可兼任 |
|
系统开发人员 |
至少6名 |
包括前台应用开发人员4名和后台ETL开发人民2名 |
|
模型开发人员 |
至少2名 |
可兼任 |
|
测试人员 |
至少2名 |
专职测试人员 |
|
运行支持及维护人员 |
2名 |
由开发人员兼任 |
要求投标人提供本项目实施人员的详细资料（包括身份证及缴纳社保证明材料，如是外籍人士，需提供护照及工作证明）。投标人应按以下表格对项目实施人员情况进行详细介绍。每张表格必须加盖投标人公章，以确认投标人对其真实性负担全部法律责任。
|
姓 名 |
|
国籍 |
|
学历及毕业院校 |
|
|
身份证号码 |
|
|
项目角色 |
|
现场实施时间（周） |
|
|
项目经历 |
项目名称 |
项目时间 |
承担角色 |
主要负责工作 |
|
**项目 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注：投标人提供最近六个月为上述角色缴纳社保证明的材料（复印件）。
4.3项目开发要求
1、本次项目由招标人与投标人合作开发，开发的软件归双方共同所有。投标人必须提供应用软件全部源程序及相应开发工具、自有产品及开发平台等，并保证其合法性，由此产生的所有争议、法律问题和全部费用由投标人负责。
2、招标人有权全方位参与系统开发过程。投标人不得对招标人以任何形式进行技术保密或限制。
3、投标人负责提供《业务需求分析书》蓝本并对招标方业务需求人员和测试人员进行需求分析方法的培训，同时配合招标人共同进行需求分析和梳理，形成《业务需求分析书》并通过需求评审。
4、投标人在招标人的配合下共同进行系统设计，系统设计方案需取得招标人的认可，并通过招标人的技术评审。
5、投标人须遵循招标人制定的开发、测试规范，并按双方确定的项目进度进行开发、测试工作。
6、投标人须配合招标人完成系统安装调试工作，并在系统运行期间提供必要的性能调优、缺陷修复、功能完善等维护工作。
7、投标人须配合招标人对项目实施严格的质量管理，确保本系统的质量。
8、在项目实施完毕时，投标人须向招标人完成系统所有源代码、技术文档等的移交。
本节的目的是规定有关系统测试的各项要求。要求投标人必须遵循所有这些规定。
4.5测试范围
测试的范围包括经评审确认的《业务需求分析书》和相关设计文档中明确的每个需求。
4.6测试要求
投标方开发的系统及其应用的软件平台环境，在提交招标方验收前，必须组织全面、完整、详细的系统测试，至少应包括功能测试、性能测试和其他必要的测试项目。测试方案需取得招标方认可。测试过程应在招标方监督下进行，并在测试结束后向招标方提交完整的测试文档。在上线运行后，若出现明显性能或功能问题，双方不能在合理时间内解决问题，招标方有权要求第三方测试，测试结果若确认是因投标方原因导致的，所需费用由投标方承担。
4.7测试规范
投标人必须为每一项的测试编写测试手册。测试手册的内容包括：
1、测试目的
2、测试所需环境
3、测试手段
4、测试过程的描述
5、测试结果及分析
4.8 项目验收要求
本节旨在阐述系统验收方面的要求。投标方应无条件完成各项服务，直至验收合格，交付使用。
4.9验收方式
1、阶段验收：项目各阶段任务完成后，可进行阶段验收;
2、终验：项目全部建设完成，全省上线并稳定运行三个月后，进行终验。
4.10验收流程
投标方向招标方提出验收申请后，招标方应在30个工作日内启动验收程序。若招标方无正当理由未在规定期限内启动，则视为验收通过。。
招标方根据最终确认的《业务需求说明书》、《业务需求分析书》、《需求变更申请书》等所述之系统功能及性能要求，对系统行验收。验收时，投标方应提交项目各阶段的管理文档、技术文档及程序代码。
4.11验收责任
在各阶段的验收过程中，如果招标方认为投标方提供的系统存在重大功能、性能和质量问题不能满足应用及实际要求，或投标方提交的文档资料不全，招标方有权拒绝提交验收合格报告，由此造成的项目延迟责任由投标方承担。
4.12项目文档和培训要求
本节旨在阐述系统建设对文档和培训方面的要求。投标人提交的文档应该是一套可保存的并容易查阅的文件。所有的培训应围绕满足招标人的具体需求而进行组织。
4.13文档和培训的范围
投标人应确保在系统建设中所提供的文档和培训是全面的、免费的。培训的主要对象是系统的使用者和招标人的技术人员。培训费用由投标人自行承担。
4.14文档要求
1、文档的内容
投标人提交的文档至少包括：
·要求提供系统的规划、开发、安装和调试计划
·系统的业务需求说明书、业务需求分析书
·系统的概要设计、详细设计说明书
·系统的数据库设计说明书
·系统的用户手册、操作手册
·系统的运行维护说明书
·系统验收测试方案
·系统的测试报告
·系统技术、业务培训方案
·系统试运行和正式运行方案及报告
2、规范性、完整性和准确性
投标人所提供的文档必须满足招标人的相应规范，招标人将分析投标人所提供文档的完整性和准确性，这是验收过程的一部分。系统终验前，投标人至少免费提供2套完整的文档硬拷贝和2份完整的文档电子拷贝(光盘)。
3、复制和散发文档的权利
招标人有权利自由地复制文档供自己使用。
4、语言需求
所有文档都应用中文。
4.14.1培训要求
1、培训人员
根据招标人需求，由投标人对下列人员进行相应的技术培训，并提供教材：
·数据中心的开发人员；
·数据中心的运维支持人员；
·省联社和市州农信社的系统管理员；
·最终用户。
2、培训地点
招标人要求所有的培训在招标人指定地点进行。
3、 教材
对所有的培训，投标人除提供完备的书面教材外，还应提交2套光盘演示资料，以便招标人进行电子化教育。
4.15服务和技术支持要求
本节旨在阐述在项目建设和上线后的运行中，投标人应提供的服务和支持。在项目实施过程中，投标人应提供足够的支持来确保项目的完成和平稳运行。
投标人至少应在下述领域提供服务和支持，并在投标应答文件中提出详细的方案：
1、系统的安装和调试
2、试运行和正式运行维护
3、试运行和正式运行问题处理和软件升级
4、与系统相关的业务和技术咨询
4.16开发环境要求
本项目由招标人与投标人的相关人员进行合作开发，由招标人负责提供项目开发所需的场地，其他开发设备由投标人自行准备。
本节旨在阐述在项目终验后，投标人应提供的服务和支持。
5.1服务和支持的范围
投标人应在下述领域提供服务和支持，并在采购应答文件中提出详细的方案：
1、解决与系统运行有关的技术问题
2、相关技术、业务培训
3、相应的售后服务
5.2服务和支持的其他要求
1、免费维护期要求1年以上，自终验通过后开始计算。
2、项目实施免费维护期内，要求公司在我社现场常驻项目实施维护人员不低于2人（其中全程参与本项目设计开发的前台设计实施人员1名，后台ETL设计实施人员1名），提供该项目的持续优化、缺陷修复及应用支持等现场服务。
3、要求公司在成都常驻技术工程师，提供7*24小时的服务，并按不同的故障级别在相应时间内现场响应。
故障的响应时间，按故障等级划分为：
1）严重：导致系统持续失效，影响业务运行，如引起停机、系统无法操作、常用或重要功能缺陷且无其它替代办法。立即响应，1小时到达现场，3小时内必须恢复生产，尽快全力排除故障点。
2）主要：经常出现系统故障，有时会影响业务运行，如常用的关键性功能缺陷等但可以用替代方法解决。立即响应，1小时到达现场，尽快全力确认排除故障点。
3）次要：偶尔出现的系统故障，未影响到业务运行，如非常用和非关键性功能缺陷等。
4）轻微：不影响用户操作的小缺陷；为提高系统的可操作性、界面的友好性等需改进之处。如提示错误、界面风格调整等。
次要和轻微故障，立即响应，定期解决（累计至一定时间或一定数量，进行集中解决），最迟不超过一周。
4、当建成的系统进行升级、更换时，投标人都必须保证配合，并免费提供相关技术和人员支持。
5、具体的服务及技术支持内容以最终合同签订为准。
四川：成都市第五十二中学专
11-23
当前位置：重庆招投标网->四川招投标网->招标信息->推荐公告
0