财政监督系统开发项目建设意见

财政监督系统开发项目建设意见

一、项目背景

略。

二、项目建设目标及原则

本项目的主要目标是：

实现“智慧财政”财政内控体系，基于“智慧财政”应用支撑平台，建设财

政内控系统，涵盖“1+10”内部控制制度体系，将风险防控融入日常工作。实现

“全过程控制、全过程留痕、全过程共享、全过程追踪问责”体系，形成财政部

门“全员参与、全程控制、全面覆盖、全部关联”的财政内控机制。实现财政部

门内控程序化和常态化，有效管控风险，实现硬化约束，提高财政资金分配与使

用的规范性、安全性、时效性，为全市财政内部控制管理建设积累经验。建设内

容包括统一门户、财政内控数据中心、财政内控基础平台、财政业务风险监控预

警平台等。

实现“智慧财政”财政监督体系，建设财政监督系统，将财政监督检杳的选

案、计划报批、检查执行过程、意见反馈、处理决定等业务进行梳理和规范，配

合相关操作规程，明确专项检查过程中各个岗位的工作职能，优化工作流程，完

善财政“大监督”体制机制，使财政监督检查工作走上制度化、规范化的轨道。

本项目建设需要遵循以下系统建设原则：

1.标准规范原则

本项目建设作为“智慧财政”（一期）重要内容，须遵循财政部《规范》和

《技术标准》以及XX“智慧财政”设计规范、开发规范、技术规范、集成规范

和安全规范。

2.实用可靠原则

系统建设应该面向实际要求，面向应用，使业务应用人员能够充分、方便、

快捷地使用各项系统功能.

3.先进性原则

系统设计应充分考虑国内外先进的软件设计理念和软件开发技术，使本项目

能够最大限度地适应技术发展变化的需要，以确保系统的先进性。

4.国产化和安全原则

系统建设应支持国产化，保证系统的安全性。遵照信息安全等级保护要求以

及国家、地方相关规定，采用安全措施，建立安全机制，防止安全性问题发生。

本项目安全建设必须实现:一是防止外部非法用户访问；二是防止用户越权访问；

三是确保数据的保密性、完整性、不可篡改性。

5.一致性和完整性原则

本项目作为“智慧财政”建设的重要组成部分，应充分利用“智慧财政”系

统已有的建设成果，实现与“智慧财政”生产系统有机融合，降低系统复杂度，

包括：用户统一、权限统一、门户统一、界面统一、架构统一、部署统一、与外

系统交互统一等。供应商需对系统功能的实现提供完整的设计方案，体现对需求

的深入理解，系统各项功能设计要具有充分的可实现性。

三、项目建设要求

1.遵循XX“智慧财政”总体设计要求

要求按XX“智慧财政”概设中的总体设计和建设要求，全面、深入理解财

政数据的特征，通过成熟、高效的方式对财政监督需求进行清分，梳理内控管理、

财政监督业务流程，设计和实施科学、合理的应用框架及技术框架，完成项目建

设目标。

2.实现与业务系统微服务化衔接

要求供应商将业务应用分解到服务层面，构建财政监督应用与“智慧财政”

业务微服务之间的集成关系，支持核心技术组件的统一版本升级，实现微服务的

一致性；通过对底层元素的配置和封装实现底层和表层分离，为上层业务功能提

供稳定的技术支撑。

3.支持财政监督系统和生产系统衔接

财政监督系统作为XX“智慧财政”项目（一期）的建设内容，将财政监督

系统中运行出来的监控结果信息，通过服务方式，与“智慧财政”生产系统进行

衔接，实现有效的业务关联、数据稽核和消息提醒。

4.实现监控规则分类

本项目重点是完成内控管理、财政监督系统的框架和已确认的功能建设，同

时实现目前采购人已提出的监控规则。

风险监控信息的分类，包括日常监控类、数据质量类、业务合规类、技术风

2

险类、环境风险类、内控管理类、财政部考核类、表组间逻辑校验类等类型。

四、项目建设内容

（一）建设内容概述

专承机构（«.■«）(IB.■£)（市.县（S.乡）

企宓个人单位主管MD

财政外部平台财政内肥平台

应用层

应用支部

应用占务业劣电件

支厚层

友成族务S«««

数据资源层

本项目建设需要遵循“智慧财政”统一集成规范，用户通过财政外部平台、

预算单位服务平台、财政内部平台统一登录使用系统，确保全市各级财政、预算

单位及外部用户都能使用本项目建设成果。

应用层建设内容：财政内控系统包括基础信息配置、风险监测服务、风险事

件处理、内控检查、内控考评、内控台帐及查询管理、内控综合门户、内控操作

平台、内控系统资源建设等功能。财政监督系统包括监督检查计划、财政监察通

知书、财政检查管理、财政检查处理、资料存档管理、检查文书模板、离线填报

等功能。供应商需要进行合理的应用分类，体现本项目和现有“智慧财政”生产

系统关联性。同时，优先利用现有的建设成果，根据统一集成规范，进行系统的

构建和集成。

（二）建设内容需求

本项目建设围绕“财政内控系统、财政监督系统”两大块内容开展，在项目建

设期内，通过系统功能实现责任部门提出和确认的内控及财政监督具体财政业务管

理规则，建设需求如卜.：

3

1.财政内控系统

以内控制度为指导、以风险管理为核心、以业务流程为重点、以自动化采集

监控、预警为手段，建设全过程全覆盖的财政内控信息化综合管理平台系统，全

面监督、检查内控制度和各类专项风险防控管理的实施和执行情况，对监控预警

和监督检查发现的疑点及问题，提出处理意见和整改建议，建立有效、畅通的内

部以及财政部门与外部之间的沟通协调机制，充分发挥财政职能的监督与制衡作

用。

LL基础信息配置管理

(1)制度规范管理

提供内控制度规范、财经法规政策、内部规章制度等制度文档的知识库管理,

支持制度文件信息维护、版本更新和发布管理。提供在线查询、检索功能，可在

线查看制度规范文件正文、条目和历史版本记录，提供下载功能。

(2)内控策略管理

需明确内控的目标和要求、对应的风险控制点、风险防范的手段和方法、风

险监测、风险识别和预警、以及发生风险后的处理方法和预案流程等内容。

内控策略以内部控制制度为目标要求，根据内控制度和专项风险内部控制管

理办法中的要求，逐条对应并制定各类专项风险的内部控制策略。支持对制度规

范进行细化分解，实施条目化管理，并对制度条目解读，设置相应的风险点和风

险防控措施，细化设置风险点的基本信息、风险分析、改进建议，并提供风险识

别依据、风险处理方法、风险处置预案等。

(3)内控岗位配置管理

内控岗位管理实现对各单位岗位人员参与业务活动的岗位职责、不相容岗位

分离、授权控制管理。支持对市局组织结构、各单位工作岗位设置、岗位人员、

不相容岗位设置、岗位职责授权设置。

(4)内控业务活动配置管理

提供业务活动内控基本信息、内控目标清单、管控环节清单、管控事项要求

清单、管控风险清单的配置功能。可支持配置业务活动基本信息和使用范围，业

务活动内控目标清单，以及目标对应的指标和评价规则。可支持配置业务活动各

环节的风险管控条目以及量化规则。

4

1.2.风险监测服务管理

风险监测管理应实现对财政各类业务活动可能发生的专项风险进行数据采

集和风险预警功能。提供对风险管控清单进行风险控制点监测、风险预警判断、

风险警示的管理功能，提供风险监测指标管理服务、监测任务管理服务、监控调

度服务、内控规则服务和风险预警服务。数据来源包括财政各类业务系统数据、

关键业务流程数据以及定期统计上报的各类财政业务报表等信息。同时支持人工

检查、巡视、审计、监督等发现上报的信息。

1.3.风险事件处理管理

风险事件管理应实现对内控总体风险、内控环境风险、内控专项风险中的风

险预警、风险应对处理及风险分析统计等功能。主要如下：

（1）风险清单展现

实现风险清单中的业务风险点、业务风险事件或违规事件的多角度、多维度

的展现、查询及统计功能。风险清单由内控总体风险、内控环境风险、内控专项

风险中的各项风险组成。内控专项风险包括但不限于预算编制风险、预算执行风

险、债务管理风险。其中，预算编制风险包括但不限于部门预算、转移支付、预

算绩效等风险事项；预算执行风险包括但不限于预算批复下达、预算变更、资金

拨付、*府采购、资金和账户管理、部门决算、非税收入执行等风险事项。

（2）权力清单展现

实现权力清单中的廉政风险点、廉政风险事件或违规事件的多角度、多维度

的展现、查询及统计功能。权力清单是风险清单中涉及廉政风险或权力应用风险

的事项清单。

（3）风险应对处理

风险点经识别和预警后，实现对风险预警信息和线索进行风险核查和处理功

能。各专项风险牵头单位、各单位在工作职责范围内，按照XX市财政局内控基

木制度、专项风险内控办法和单位内控操作规程（1+104-X）明确的风险应对流程

进行办理。包括：风险点升级为风险事件或直接处理、解除；风险事件经流程处

理后解除或经判别后升级为违规事件；违规事件按流程处理等。内控办对各类风

险问题处理、违规业务处理进行监督、督办。

5

L4.内控检查

实现内控风险检查和内控考核评价工作管理功能，以及对内控指标体系的统

一管理。

（1）内控风险检查

提供内控风险检杳的任务管理、自查与审核管理功能。内控检杳由内控办及

内控专项风险牵头单位（以下简称：牵头单位）发起，限据内控基本制度及内控

考核管理办法进行定期或不定期的总体检杳、专项检查，以及日常的监督、检查、

巡视等活动。牵头单位可制定内控风险检查计划，各单位作为被检查单位按计划

执行内控风险自查任务并报牵头单位，由牵头单位对各单位的自查结果进行审核。

检杳内容包括内部控制及专项风险防控制度建设、落实和执行情况，内控薄弱环

节，风险事件及应对情况等。检查表格可支持动态调整。检查反馈的方式包括定

期检查、单位或个人自查填报、日常监督检查、巡视、内审、纪检监察、审计等

发现的疑点问题上报等。

（2）内控检查指标管理

提供设置、管理内控检查指标体系的功能。指标可逐级分解展开，对末级指

标可设置量化规则。可以关联绑定量化的统计指标或风险指标。可设置自动评价

规则，支持按百分比打分逻辑，支持按“满分xx,发生一件扣x,扣完为止”

的逻辑算法。

L5.内控考评

（1）内控考核评价

提供内控考核自评任务管理、自评、审核评价功能。牵头单位定期组织内控

考核评价，制定内控考评计划，各单位按计划执行内控考核自评，牵头单位对各

单位的自评结果进行审核和评价。提供对业务活动内控目标执行情况的自动评价

功能。

（2）内控考评指标管理

提供设置、管理内控考核评价指标体系的功能。指标可逐级分解展开，对末

级指标可设置量化规则。可以关联绑定量化的统计指标或风险指标。可设置自动

评价规则，支持按百分比打分逻辑，支持按“满分xx,发生一件扣x,扣完为

6

止”的逻辑算法。

1.6.内控台账及查询管理

(1)内控执行记录台账

提供重点业务全过程的内控合规记录、内控业务全貌、业务经办过程记录和

标准规范过程的合规记录功能。通过内控台账记录发现风险线索。

(2)业务信息和沟通记录台账

提供业务过程中的各类业务信息、、内部沟通和对外沟通的记录信息查询功能。

(3)内控基础信息台账查询

提供内控基础信息台账查询功能，支持内控台账基本信息、管控环节信息、

内控目标清单、管控事项清单、管控风险清单的查看，支持内控执行情况的汇总

展现。

(4)内控执行信息台账查询

提供内控执行信息的统计报表功能。

1.7.内控综合门户

内控综合门户应实现内控管理综合展现与交互功能，与“智慧财政”管理系

统实现统一用户认证。该模块应包括内控综合信息集中展示，内控重点风险点监

测信息展示，内控风险事件处置信息展示，内控督办事项或待办事项提醒，内控

通知与信息发布等管理功能。系统应实现独立界面展示，展示内容应按不同角色、

权限实现灵活配置。

1.8.内控操作平台

内控工作管理系统主要是为个人办公服务，系统将个人办公的待办事宜推送

到相应的处理人，处理人对待办事宜进行处理；同时系统提供对当前尚未响应和

尚未完成的任务进行督办功能；通过内控流程管理实现内控管理流程的分类管理、

各分类下的流程定义；通过自动派单规则管理实现风险事件可根据事件关联响应

规则自动触发规则定义的内控管理流程。

(1)待办事宜

当前登录人可查看自己待响应的工作任务和正在处理尚未完成的工作任务

清单，以及任务当前的处理状态和时限要求。可以查看流程流转过程中前期已经

7

处理过的节点处理人的处理记录信息。

（2）任务督办

提供对当前尚未响应和尚未完成的任务督办功能。系统将根据规则和流程任

务的时限要求自动向任务处理人发送督办通知，或者向任务处理人的上级领导发

送通知。

（3）内控流程管理

内控管理流程的分类管理、各分类卜的流程定义、以及具体流程的图形化建

模管理等功能。可设置各类日常工作中的管理流程，由人工或相应的条件触发各

类流程。系统将自动发送督办通知，并升级通知给处理人的上级领导。可以对各

类内控管理流程的触发、应用情况进行汇总统计和绩效评价。自动派单规则管理,

风险事件可根据事件关联响应规则自动触发规则定义的内控管理流程。

L9.内控系统资源建设

1.9.1内控数据中心

建设内控数据中心，实现内控数据汇聚。内控数据中心统一接收内控对象的

相关数据，例如XX市财政局预算管理一体化编制、执行、核算的回流数据和市

级自主开发业务系统的数据。还包括内控规则、内控依据以及内控成果等结构化

数据和电子文件，内控数据中心所沉淀的内控数据也为后续业务的内控风险识别

和财政内控等工作提供数据基础和决策辅助。

（I）法规制度库

包括财政内控基本制度、十类财政专项风险管理办法以及其他作为监督依据

的相关政策法规等。实现法规制度按条目管理和关键字索引，便于内控业务过程

中快速定位、参照和引用，

（2）预警规则库

对财政业务系统中的关键业务流程、业务环节、业务数据进行内部控制管理,

从流程性风险、时效性风险、资金安全性风险和预算执行情况等方面进行风险识

别、定级、预警及处理应对流程等•套监控规则；根据实际业务经验对预警规则

进行不断丰富和完善。

（3）内控对象信息库

以每•个被监管对象为单元，存储该对象关联的•系列监管数据，包括被监

8

管对象基础信息、所涉业务数据、监管记录、关键节点的操作记录等。

(4)内控事项库

按内控类别存储预置的监管事项，内控事项包含内控的主体、客体、内控内

容、内控周期、内控方式等信息，内控事项以任务为载体进行布置和发布，可实

现标准化内控。

(5)标准模板库

包括标准文书模板和内控内容模板两部分，熨现统一的标准模板管理和版木

变更管理；利用标准文书模板，实现各类统文书格式设置，支持标准化文书在线

编制；利用监管内容模块，实现动态表单的定义，支持在线内控数据填报。

(6)标准基础数据库

建设标准基础数据库实现对关键内控要索的统一管理和发布，存储与管理与

监管相关的标准基础数据，包括机构、人员、内控对象等，通过标准基础数据库

统一全业务系统的内控要素，从而支持集中内控和全过程内控。

L9.2内控基础平台

建设内控基础平台，实现功能配置组件化。内控基础平台提供内控功能的基

础组件，支持根据应用需要进行组件选择和扩展，包括预警规则配置组件、数据

监测组件、风险统计组件、督办核查组件、预警控制组件、分析报告组件和其他

管理类组件。

(1)数据监测组件

按照设置的监测方式和监测内容，对被监测的业务系统进行实时或定时数据

采集；将采集的数据通过统一监管消息通道提交给监管应用平台；从监管消息通

道定时获取消息，将财政风险管控中心发布的指令转发给被监测的业务系统；同

时，提供被监测业务系统通用查询服务。

(2)风险评估组件

包括两方面功能，一方面是对风险点进行评估，设置风险级别和应对措施；

另一方面是对业务系统或内控对象进行风险评估，按照量化标准计算风险指数，

形成风险评估报告，提示风险状态并给出风险应对建议。

(3)督办核查组件

实现事前督办和事后检查，发布督办或检查任务，被督办或检查时象接收任

9

务后，按照任务要求进行处理，并反馈处理结果；对督办和核查的过程文档或问

题记录进行备案登记，纳入监管对象信息库，方便后续查询和分析。

（4）预警控制组件

根据设置的预警规则，对监测到的数据进行预警分析，识别风险并记录预警

状态，并根据控制策略输出预警控制信息；接收风险处理结果，对已完成处理的

风险，记录风险处理结果，并变更预警状态。

（5）分析报告组件

针对监管数据中心承载数据的分析和报告功能；提供图表展现、统计分析、

仪表盘等报表工具，支持按照标准文书模板进行报告生成，为应用系统提供分析

报告能力支持。

（6）其他管理类组件

实现关键数据管理和系统管理功能，支持法规、案卷、监管对象、规则、事

项以及标准模板等关键数据的统一维护和管理；支持标准基础数据、用户、流程

和权限等的分级授权管理:

1.9.3内控预警体系

建设内控预警体系，实现业务风险监控。财政业务风险监控预警实现对财政

内部和外部风险的统一监测、识别、评估和应对，对被监管对象进行嵌入式、全

覆盖监管；满足事前防控、事中管控和事后监管的要求。主要包括：一是对单位

和人员在财政业务活动过程中的关键风险点进行风险监测、识别、评估和应对;

二是对识别的风险进行管理，对产生的问题或*府督办事项进行督办，对内控工

作进行绩效考核；三是定期或不定期提供不同管理层级或不同业务类别的内控报

告。四是针对不同财政业务管理信息系统，结合内控制度，定义并加载相应的监

控预警规则，扩展出多个财政业务风险监控预警应用，实现在线自动风险监控和

预警。

2.财政监督系统

财政监督系统将财政监督检杳的选案、计划报批、桧杳执行过程、意见反馈、

处理决定等业务进行梳理和规范，配合相关操作规程，明确专项检查过程中各个

岗位的工作职能，优化工作流程，完善财政“大监督”体制机制，使财政监督检

查工作走上制度化、规范化的轨道。

10

2.1.总体流程

(1)财政各业务处室提出本处室的监督检杳需求，财政监督局通过汇总各

业务处室的检行需求，结合上级财政部门统一部署和财政中心工作任务，制定年

度检杳计划并按规定报批，统一组织实施经批准的检杳计划。

(2)根据下达的年度检查计划，财政处室人员成立检查小组，对小组成员

进行杳前培训，制定检查方案，并由系统生成检查通知书报送分管局领导审批。

财政部门实施财政检查，于3个工作口前向被检杳对象送达财政检查通知书。

(3)检查小组开展现场检查，填写签证单，发送被检查对象，单位接受签

证单并反馈意见。检查组长复核意见后，填写征求意见函并发送被检杳对象征求

反馈意见。检查小组结合反馈意见生成财政检杳报告。

(4)检查小组将财政检查报告、工作底稿及其他有关材料提交复核机构进

行复核，对于重点问题经组织论证后完善财政检查报告，经局领导同意后下达财

政监督报告。

(5)对于需要进行行政处罚的问题经集体审理后，按规定制作行政处罚决

定书，并事先告知当事人依法享有的权利，经局领导同意后下达行政处罚决定书。

(6)被检查对象依据财政监督报告或行政处罚决定书对问题进行整改，财

政处室对问题的整改情况进行监控，并对相关资料进行存档。

2.2.监督检查计划管理

财政监督局会同各相关处室，根据年度财政工作重点和上级要求，提出年度

监督检查计划，经分管财政监督局的局领导审核同意后，报局长或局长办公会议

审定。财政监督局牵头负责专项监督检查项目管理，其池日常性监督检查项目山

各相关处室负责。年中增加监督检查项目按上述流程办理。

业务流程示意：

II

财政监督检查计划管理流程图

财政处室财监局分管局长同长

?

提出洋收投ift需求

r

汇€箔成提出年度检食计划A分甘局仁审批►财长审批

「七汰口讣KtJi

•

2.3.财政检查通知书

财政部门实施财政检查，一般应于3个工作日前向被检查人送达财政检查通

知书。

业务流程示意:

2.4.财政检查管理

财政处室实施财政检查，向被检查人送达财政检杳通知书后，按财政检杳工

作规程实施财政检查。

业务流程示意：

2.5.财政检查处理

财政部门对财政检查报告和复核意见进行审定后，应当根据不同情况作出处

理。对未发现或有轻微财政违法违规行为的被检查对象作出检查结论，出具财政

监督报告；对有财政违法违规行为的被检查对象，按程序组织开展集体会审，并

依法依规作出行政处理、处罚决定；对不属于本部门职权范围的事项依法移送。

业务流程示意：

财政桂百处理、整改业务流程图

财政处完被依西单位/当小人

修之色关荒n

S〃巾如才对域孙申北

J曲!n

㈢A

理

处

、）--------Alfc&fi黑行为，事“依阳外）一►门凌导审批

电

决

。加，.巾熄"，4公。M领3丽奴卜］

下达处飞处理华位按税处罚

彦见决定

I

接收必见偶值中M-----tilt:二

—IflWWTtf

处k处及次定

报收井整改

K

2.6.资料存档管理

资料档案管理系统涉及的范围涵盖档案管理活动中需要用计算机进行管理

或处理的各个环节，包括对资料档案数字化工作中数据转换、立卷、分册、档案

查阅、查阅审核、用户管理等业务功能，以及电子数据的采集、目录设置、数据

校检、目录生成、数据统计、打印输出等基本功能，并能实现树状检索，根据主

题词（或关键词）检索查询。

业务流程示意：

资料存档济理流程

资料采集资料管理分析检索

信0塘号目录索引

专均分析

院合奏议

电子信息一“方。5%rn»蟆*音说

圣像HI：住

全文检甯

影像监料

两览记录

梏京族计

2.7.检查文书模板管理

检杳文书模板管理系统涉及的范围涵盖检杳活动中所需要的所有文书。用户

根据需要在系统中调用文书模板进行编辑并打印输出。系统提供新增、编辑、修

改模板的功能，并能实现树状检索，根据主题词（或关键词）检索查询。

业务流程示意

检查文书模板管理

财监局文书模板管理财政处室

检索

新增

杳询

编辑

模板库

调用

修改

打印输出

财政检查文书目录

序号文书名称使用环有否回证

16

节

1财政检查选案意见征询表选案

2财政检查举报案件登记表选案

3财政检查案件转办单选案

4财政检查异地信函复函选案

5财政检查通知书检杳有

6财政文书送达回证通用

7财政检查承诺书检查

8财政检杳基本情况表检查

9会计人员配备情况统计表检查

10银行帐户开设情况检查

11财政检查询问笔录检查

12财政检杳询问笔录（附页）检查

13财政检查调取账簿资料通知书检查有

14财政检查调取账簿资料清单检查

15财政查询存款通知书检查有

16财政延伸检查通知书检查有

17财政检查工作底稿检查

18财政查询存款工作底稿检查

19财政检查证件复制提取单检查

20财政检查报告检查

21财政检查报告征求意见函检查有

22财政检查案件审理提请书检查

23财政检查案件审理报告直理

24财政检查行政处罚告知书自理有

25财政检查行政处罚听证通知书自理有

26财政检查结论（财政监督报告）自理

27财政检查处理决定书自理有

28财政检查行政处罚决定书官理有

29财政检查执行通知书执行有

30财政检查执行报告执行

31财政检查案件卷宗目录执行

32财政检查统计表执行

2.8.系统离线使用功能

监督检查离线使用功能：适用于外出网络不能连接至财政内网的场合。

系统要求支持离线使用。

（1）第一次获取离线客户端，可以去自己部门的本级单位的在线填报的网

页界面下载此安装程序；

（2）首次运行能够下达基础数据，离线客户端能够接收基础数据；

（3）离线填报检查数据。要求填报界面功能和在线界面一致；

（4）离线数据上传，数据传送，并且在线系统有权限用户接收数据八

五、技术要求

（一）技术架构要求

L总体架构要求

符合“智慧财政”技术架构的要求，具有灵活性、先进性，能够应对系统的

变化和业务扩展，体现对当前和未来业务适应性。

项目总体技术架构，包括但不限于资源层、支撑层、应用层、表现层等多层

级，基于“智慧财政”项目（一期）已建设完成的，由“智慧财政”项目（一期）

总集成方建设并提供的开发平台和服务平台进行扩展和构建；网络安全体系、组

织保障体系、标准规范体系和过程管理体系贯穿于总体技术架构的各个层面。

支持标准云服务，如分布式缓存、分布式消息、注册中心、配置中心等；支

持公共业务能力和技术能力的服务化，支持通过标准协叹将公共业务能力发布为

云服务，并实现相应的服务生命周期管理功能。

支持自主创新的中间件、数据库、操作系统等。

供应商需要提出实现以上目标的系统架构设计。

2.数据架构要求

本项目建设的数据架构中，要体现本项目和“智慧财政”生产系统的数据衔

接，如风险监控信息的数据流和“智慧财政”的交互，实现数据监控结果数据通

过清分后进入后续管理流程。

3.展示集成技术要求

采用先进合适的技术架构，构建本项目应用，并统一集成到“智慧财政”内

外部服务平台，要求支持和使用“智慧财政”用户认证、权限、数据交换等公共

服务。要对数据进行统一汇集、加工和管理，通过数据集成、门户集成等方式汇

聚到“智慧财政”内外部服务平台。

4.技术方案要求

供应商提供的技术方案需要对以上要求进行响应，技术方案需要充分体现出

功能设计的针对性和实用性。

供应商需要针对技术架构要求对内控系统资源建设、财政监督系统和生产系

统衔接、系统离线使用功能等关键内容做详细阐述。

（二）基础服务要求

1.微服务技术要求

本项目需要充分使用“智慧财政”已建设完成的微服务平台。

（1）微服务框架:采用SpringCloud等主流微服务框架,需要利用“智慧

财政”项目（一期）总集成方提供的微服务治理平台完成服务部署；

（2）微服务拆分：遵循业务独立，边界清晰的原则，保证单个微服务内部

完成单一的业务功能。微服务之间松耦合，接口稳定，可以独立演进；

（3）层次化设计：公共微服务严格遵循服务契约定义，接口变更接受强管

控；内部微服务仅限于本业务域访问，不允许跨业务访问；

（4）服务契约:服务契约符合OpenAPI标准；公共微服务提供显式服务契

约；公共微服务的输入输出报文符合财政数据标准，支持Restful访问协议；

服务契约支持版本管理；服务契约迪过软件开发平台进行统一管理；供应商要确

保代码与契约的一致性；

（5）服务注册发现:支持服务的动态注册发现；支持对接提供的统一服务注

册中心;

（6）服务治理能力：支持服务容错、服务限流、服务降级以及服务熔断等;

（7）分布式事务一致性：支持TCC（Try/Confirm/Cancel）等分布式事务管

理，支持完整的事务逻辑；保证服务调用的容错性、事等性、可交换性；

（8）要求供应商遵循“智慧财政”统一的服务注册、服务发现、服务治理

的微服务管理平台和管理规范。“智慧财政”微服务平台能接入各种技术体系的

服务，能接入多种协议的服务。

2.容器技术要求

（1）与“智慧财政”容器平台集成，实现全流程管控，支持一键发布、版

本回滚、秒级扩容/缩容；

（2）基于容器技术实现包含但不限于镜像管理、容器服务；镜像管理包括

镜像的构建、存储、推送、同步等，容器服务包含集群创建、服务、配置秘钥并

提供调度、编排、部署等功能以及相关资源的监控管理；

（3）基于容器技术实现DevOps持续集成、持续发布、持续交付等开发运维

一体化功能。

3.流程与表单技术

（1）供应商需优先选择利用“智慧财政”建设成果，优先选用采购人已有

流程工具进行业务系统开发。实现项目中业务流程的定义、运行、监控和管理,

支持图形化的流程定义，支持通过、驳回、会签、转发、中止、挂起等核心操作，

支持自定义表单、引入API接口等，支撑流程环节建模；支持各种复杂的流程,

业务系统可以快速基于工作流平台搭建应用；

（2）供应商需优先选择利用“智慧财政”建设成果，优先选用采购人已有

表单工具进行表单的开发，实现灵活的表单定制、发布、维护，能够通过工具直

观简单地定制各种表单，并发布给有权限的人员使用。

4.通用技术要求

（1）要求支持主流的第三方控件，优先支持国产软件：

（2）符合国产化适配要求。

（三）融合对接要求

1.供应商集成要求

本项目属于“智慧财政”项目（一期）建设范围，需服从采购人和“智慧财

20

政”项目（一期）总集成方的管理，完成业务应用设计、开发、测试、联调和上

线。

具体包括但不限于以卜内容：

在项目建设过程中接受采购人、“智慧财政”项目（一期）总集成方的管理、

监督和协调；严格遵守采购人制定的标准规范要求及落地方案进行项目建设和运

维；完成项目的方案交底与跟踪、项目过程管理、工作成果考核、质量管理等工

作；根据采购人和“智慧财政”项目（一期）总集成方的熨施要求，制定项目的

具体实施计划，并按计划完成实施工作；对采购的第三方软件进行部署与集成;

完成标包间的集成、联合调试和测试工作；开展系统测评，包括功能测评、性能

测评等；制定承建项目的培训方案，并完成具体的培训工作；根据“智慧财政”

的项目验收要求通过验收；完成上线及推广应用。

完成财政内控系统和财政监督系统集成到“智慧财政”进行相关的集成工作。

“智慧财政”项目（一期）总集成方提供业务规约、技术规约、运维保障和组织

保隙推进项目建设。财政内控系统和财政监督系统集成时接受采购人领导，严格

遵守项目“智慧财政”项目（一期）总集成方制定的标准规范要求及落地方案进

行项目建设利运维。

投标文件中根据具体的实施细项进行以上工作的总体描述。

（1）根据“智慧财政”项目（一期）总集成方提供的业务规约制定的内容

包括统一业务的交互标准、统一业务分类标准、以及集成新建系统和已建系统所

有业务的技术标戕和方案，进行业务集成；

（2）根据“智慧财政”项目（一期）总集成方提供的技术规约通过制定标

准化的技术集成框架，包括资源集成、权限集成、应用集成、页面集成、数据集

成等方式，完成项目基础服务建设，完成标准规范编制和项目应用，完成开发测

试集成、项目上线等，进行技术集成。

综上，财政内控系统和财政监督系统作为XX市“智慧财政”项目（一期）

的重要组成部分，应根据总集成要求，提供应用、服务等被集成的方式，提供其

他系统应用调用和服务调用等多种业务交换方式，并可根据接口提供相关的业务

数据。

21

2.“智慧财政”系统集成要求

本项目建设的财政内控系统和财政监督系统需遵循采购人“智慧财政”系统

的UI风格要求、认证与权限管理要求、安全要求、运维与监控等要求。财政内

控系统和财政监督系统和现有的统一门户集成和对接。

本项目的微服务支持容器化部署，须接受“智慧财政”的微服务管理平台、

容器管理平台的统一调度和管控。

需要满足后台构建管理能力，遵循统一技术标准和管理，达到数据共享和业

务协同，具体需要遵循和使用的集成规范及接口有：

(1)用户权限管理

依托“智慧财政”用户体系，采用一致的用户帐号，不独立维护用户，统一

从“智慧财政”支撑平台的管理功能发起，并能同步用户更新。权限管理为财政

内部各级管理者提供统一的角色和权限配置功能，支持与财政各业务系统用户、

角色和权限的映射关系维护和管理功能。按照“智慧财政”一期已实现功能扩展

支持各场景应用授权和数据授权。应用授权控制允许访问各场景应用的用户范围,

数据授权控制用户允许查看访问的数据范围。

(2)标准规范

标准规范对加载各类数据应用场景接入提供统一标准，统一接口标准规范定

义包括请求方式、接口地址、接口参数、返回结果、使用场景等。具体接口类型

包括但不限于：

消息接口：用于各数据场景应用提醒信息时以平台统一的方式进行推送并展

现。接口要素包括应用编码、应用名称、消息类型、消息内容、消息唯一标识、

消息等级等。

•数据入库过程发现异常消息接口设计；

•应用界面加载数据分析发现'业务风险等情况需要发送预警消息接口设计;

会话验证接口：用于从数据主应用钻取进入场景应用时供场景应用验证会话

合法有效性。包括进入场景应用时地址携带会话参数，以及会话验证接口。

用户信息获取接口：月于在会话验证通过后，根据会话获取当前登录用户信

息，包括姓名、登录名等必要信息。

权限信息获取接口：月于在会话验证通过后，根据会话获取当前登录用户权

22

限信息，包括有权限访问的场景应用、数据权限范围如区划、处室（科室）、部

门等。

应用支撑平台API调取接口：用于在会话验证通过并进入场景应用后，场景

调取已发布在应用支撑平台的各业务指标API接口，接口要素包括应用编码、用

户帐号等。

法规库调取接口：用亍在会话验证通过后，根据法规条目信息获取法规库条

目，接口要素包括法规关键字、条目信息等。

数字档案调取接口：月于在会话验证通过并进入场景应用后，场景调取已发

布在应用支撑平台的各业务指标API接口，接口要素包括应用编码、用户帐号等。

（3）应用集成环境

“智慧财政”提供应用集成环境，为管理人员提供应用集成管理和配置功能，

配置新的服务接口、报文转换、内部服务处理逻辑等，各数据场景应用通过统一

接口标准，实时动态调用指标数据和预警消息。

应用信息维护一一维护数据场景应用基本信息包括名称、访问地址等，由管

理员统一维护。场景应用要求统一部署在指定应用集成服务器环境，部署包应参

照“智慧财政"docker镜像的命名、FI录结构、配置及构建规范进行构建，并

以docker形式安装运行。

六、非功能性要求

（一）可扩展性

在设计上必须具有适应业务变化的能力，当系统新漕业务功能或现有业务功

能改变时，应尽可能减少因业务变化造成的影响；系统应提供一个弹性的架构，

支持使用配置而免编程的方式对业务流程、业务表单、查询统计等功能的定制与

调整。

（二）易用性

系统运行过程中应稳定、可靠、安全、实用，人机界面友好，检索查询灵活

快捷，在图表生成、多表头的多层展现、数据的树形展现等方面要灵活美观，输

入输出方便，常用操作有提示信息和快捷键支持。系统应符合用户操作习惯，提

供人性化的用户体验。时于新用户或不常使用的用户通过简单培训即可上手使用。

23

(三)可移植性

系统设计应适用于所有常见操作系统、浏览器、应用服务器及数据库产品。

(四)稳定可靠性

在长期稳定运行状态下，业务应用系统资源占用量稳定，无突发性增长，无

慢、卡、顿现象。

系统应保证在正常情况下和极端情况下业务逻辑的正确性。包括无单点故障,

系统应不受任何单点故障的影响；系统应能够在一小时内从故障中恢复；建立硬

件、数据库集群、应用服务器集群，Web服务器集群等多项冗余提高可靠性，故

障时能够快速接管，保证访问的可靠性。

(五)可维护性

支持逐步应用成熟的商业PaaS平台及容器化管理工具等，对微服务进行全

生命周期管埋，实现微服务调度任务化管埋，自动编排任务等，切实保障各业务

支撑系统可靠、稳定、高效地运行。

(六)性能需求

采用轻量级技术，降低平台运行开销，用户界面跟应用逻辑代码分开，可以

根据采购人要求随时修改，增强操作响应速度。在合理的硬件资源支撑情况下，

满足：

(1)日常支持10000用户以上在线使用，支持1000用户并发使用；

(2)系统登录响应时间W2秒，高峰期最大响应时间小于5秒；

(3)复杂事务处理操作平均W8秒；

(4)普通应用查询平均(包含各类信息查询业务、主要页面平均响应时间等)

W3秒；

(5)统计分析类查询平均W5秒；

(6)业务流转时间不超过5秒。

七、系统安全要求

本项目对系统数据的保密性、完整性、可用性有较高的可靠性、安全性要求。

整个系统的设计、开发、上线必须遵照信息安全等级保护三级的标准进行。

24

系统的设计、开发、建设时，要充分考虑物理层安全、网络层安全、操作系

统安全、内容安全、应用层安全、PKI体系、安全集中管理的衔接，与采购人已

部署的防病毒、防火墙、入侵检测、漏洞管理、日志审计、VPN、证书及授权等

技术手段顺畅配合，构筑网络纵深防御体系，作好系统安全、平稳、高效地运行。

项目建设需综合考虑，确保项目在身份鉴别、安全审计、恶意代码防范、访

问控制、通信完整性、通信保密性、软件容错等方面达到信息安全三级等保要求，

切实提升财政重要数据在产生、传输（通信）、使用、存储和销毁仝生命周期的

安全性。在项目开发建设及运行过程中，对等级测评、安全检查等工作中发现的

设计、系统、代码等安全问题，必须及时进行整改。

依照三级等保要求，构建符合相应要求的安全计算环境，特别是对恶意代码

防范中，采用免受恶意代码攻击的技术措施或主动免疫可信验证机制及时识别入

侵和攻击行为，并将其有效阻断。例如在SQL语句的编写中，必须有SQL注入等

行为的相应防范。在开发过程中，程序员及项目经理必须有防恶意代码意识和相

应的技术水平。项FI管理中，需有相应的恶意代码检查机制和措施。

在系统开发、测试、运行过程中，除了遵循三级等保要求，亦要根据《财政

应用系统安全开发规范》，严格落实财政应用系统生命周期各阶段（包括：安全

需求分析、系统安全设计、系统开发安全、系统安全测试和系统部署上线等阶段）

需执行的安全控制及安全任务，加强应用系统的安全性，消除应用系统漏洞隐患，

降低安全风险，减少安全事件发生。包括：

（1）在安全需求分析阶段，应按照安全功能调研表进行安全需求分析和功

能调研工作，包括身份鉴别、访问控制、安全审计、软件容错、资源控制、数据

完整性、数据保密性、数据备份恢复、剩余信息保护和个人信息保护，提出应用

系统安全功能、数据和性能安全等方面的安全需求，形成《应用系统安全需求分

析报告》。对财政业务逻辑、业务特点等进行深入分析，进一步梳理安全需求，

应重点分析应用系统业务逻辑自身带来的数据被篡改或泄露后可能造成的经济

损失及其之外的社会重大影响，进而加强应用系统安全性。

（2）在应用系统安全设计阶段，应按照规范开展设计工作，形成《应用系

统安全设计报告》，报告内容包括但不限于业务功能、流程介绍、安全需求和安

全设计等。

25

（3.）在应用系统编码开发过程中，应根据开发语言、安全功能需求和所面

临的安全风险，按照规范开展相关工作，遵循整体输入验证、避免溢出、接口检

验、安全调用和规范配置的原则进行编码开发，从代码层减少安全漏洞隐患，提

高应用系统安全性。

（4）安全测试工作应包括安全白测与上线前安全检测两部分，安全自测是

指应用系统开发完成，供应商完成安全自测后，应用系统管理部门根据《应用系

统安仝需求分析报告》、《应用系统安仝设计方案》组织开展源代码安仝检测、安

全功能测试等自测工作，确保应用系统安全设计与需求的一致性，并根据自测结

果形成《应用系统安全自测报告》。应用系统上线前检测是指在应用系统上线运

行前合理安排时间对应用系统开展安全检测工作，包括安全漏洞扫描、应用合规

性检测、渗透测试、源代码审计、基础支撑环境安全基线检测等形成相关检测报

告。供应商按照检测报告进行整改，待整改完成后进行复测验证，通过复测后方

可上线运行，未通过上线前安全检测的应用系统，不能上线运行。

应用系统安全功能自测项包括但不限于：用户管理测试、用户登录测试、渗

透性测试、系统管理测试、权限管理测试、访问控制功能测试、审计范围测试、

审计信息保护测试、审计功能测试、剩余信息保护测试、通信完整性测试、通信

保密性测试、抗抵赖测试、软件容错性测试、源代码审计等。

八、项目实施要求

（一）开发方式要求

本次系统开发采用现场开发的方式。

招标文件提出的需求是采购人当前初步的业务需求，最终以中标以后需求规

格说明书为准。招标文件图例中的各类数值为参考模拟值，非业务实际值。

对招标文件中的合同、技术需求、业务需求存在矛盾或表述不一致的地方，

供应商应在提交投标文件前要求采购人澄清如果供应商未要求采购人澄清的，

则在获得成交之后，对这些不一致之处的理解，以采购人的解释为准。在沟通配

合方面，供应商必须及时响应采购人的要求，及时排查解决问题。

26

(二)开发、测试环境要求

项目各阶段开发、测试所需的基本环境(包括工作环境、网络环境、系统软

件、硬件设备等)由供应商自行负责并承担费用。

(三)项目进度要求

供应商按照项目总体建设进度要求，分阶段制定合理的工作进度计划，并且

根据采购人要求进行调整和细化，根据“智慧财政”集成耍求，给出具体安排及

工期。

项目实施时间从双方签订合同起，供应商须在规定时间内完成本标项规定和

要求的建设内容，具体包括：

(D20XX年8月，完成内控数据中心、内控基础平台、内控预警体系等底

层资源开发。完成财政内控管理系统所包含的应用功能开发；

(2)20XX年9月，在内控系统基础上，完成财政监督系统各项应用功能的

开发，内控系统和财政监督系统投入试运行；

(3)20XX年10月至12月，完成系统优化完善及项目验收；

(4)20XX年1月，项目进入运维阶段。

(四)项目管理要求

1.供应商响应要求

(1)供应商应就如何制定科学、完整、适合本项目的项目管理规范进行阐

述。根据项目特点及应用设计制定严谨、可实施的项目计电J;

(2)供应商应提交项目组组织架构、人员名单、人员简历和人员资质证书

等材料•。提交组织及资源保障方案，组织设置合理有针对性、专业实施人员配备

齐全、保障措施全面可实施；

(3)供应商应详细说明项目管理工具；

(4)供应商应就如何实现需求变更管理进行阐述；

(5)供应商应提交版本控制及发布方案，方案合理，针对不同的版本类型

制定适合财政组织特点的制度流程，可实施；

(6)供应商应分析项目存在的各种风险，阐述应对策略和措施；

(7)供应商应阐述项目质量保证措施。

27

2.项目沟通管理

项目实施过程中，供应商须通过建立制度化的沟通渠道等方式，加强与采购

人的沟通。

首先，供应商须遵守采购人项目管理相关规定，接受采购人项目管理机构和

项目负责人的领导，指定负责人与采购人保持沟通和协调。

其次，供应商须建立项目例会制度，就项目进展情况、存在的问题、需要协

调的主要事项、下一阶段工作计划等与采购人进行适时的沟通协调。

3.项目进度管理

（1）供应商须采用科学合理的方法确定进度FI标，编制进度计划和资源供

应计划，进行进度控制，在与质量、费用目标协调的基础上，实现工期目标；

（2）供应商须向采购人提供详细、可行的实施方窠，并做好项目实施的准

备工作；

（3）供应商应按采购人要求，制定项目里程碑和进度计划；

（4）供应商制定的进度计划应细化到每个底层任务的工期不超过5个工作

日；

（5）供应商应每周提交项目进度周报，更新详细进度计划。

4.风险和问题管理要求

（1）供应商应对项目风险从识别到分析到应对措施提出完备的可行性方案,

针对可能出现的各类问题，供应商要制定有针对性的问题管理流程，保证问题顺

利解决；

（2）供应商应制定跨项目问题解决中对可能出现的争议和冲突进行协调和

解决的方案；

（3）供应商必须指定风险和问题负责人；制订和执行问题分析计划，监控

和更新问题状态；

（4）供应商必须及时发现、处理项目执行过程中的风险和问题，向采购人

汇报无法处理的风险和问题；

（5）供应商应定期汇总工程风险和问题，持续跟踪直至风险和问题关闭。

28

5.变更管理要求

变更类型主要包括：范围变更、业务需求变更、技术架构变更、进度变更、

交付物变更。供应商应对变更进行有序控制，至少满足以下要求：

（1）供应商应制定标准的变更管理规范；

（2）项目变更时，首先需要对变更的影响和范围进行评估，并评估其变更

对其他相关项目的影响，经采购人确认后方可实施变更；

（3）供应商应确保对受影响的交付物按照新基准进行相应调整。

6.软件版本管理要求

软件