数字化保险平台系统方案-系统介绍

数字化保险平台面系统方案

目录

1项目建设方案..................................................................................................... 4

1.1系统架构设计.......................................................................................... 4

1.1.1指导思想....................................................................................... 4

1.1.2建设原则....................................................................................... 5

1.1.3保险行业规范文件....................................................................... 6

1.1.4信息技术标准规范....................................................................... 7

1.1.5技术路线....................................................................................... 8

1.2网络拓扑设计.......................................................................................... 9

1.3系统安全设计........................................................................................ 10

1.3.1总体建设任务............................................................................. 10

1.3.2网络框架设计............................................................................. 10

1.4业务管理系统........................................................................................ 12

1.4.1项目管理..................................................................................... 12

1.4.2合同管理..................................................................................... 19

1.4.3财务收付管理............................................................................. 33

1.4.4承保管理..................................................................................... 35

1.4.5理陪管理..................................................................................... 37

1.4.6分支机构开发............................................................................. 39

1.4.7反洗钱管理................................................................................. 39

1.4.8统计报表..................................................................................... 43

1.4.9非功能性需求............................................................................. 43

1.5保险中介从业人员管理系统................................................................ 44

1.6企业客户服务系统................................................................................ 44

1.7互联网保险业务平台............................................................................ 44

1.8数据分析中心规划................................................................................ 44

1.8.1景区应用..................................................................................... 44

1.9软硬件要求............................................................................................ 44

1.9.1景区应用..................................................................................... 44

1.10技术实现方案...................................................................................... 44

1.10.1系统接口总体设计................................................................... 44

1.11项目实施方案 ...................................................................................... 47

1.12云狐软件著作权.................................................... 错误!未定义书签。

1 项目建设方案

1.1 系统架构设计

1.1.1 指导思想

作为国家电投系统内唯一的保险中介服务机构，公司始终秉承“产融结合、注重服务、立足集团、面向市场”的管理理念，坚持服务集团和开拓市场二者并重，依托金融平台充分挖掘市场潜力，发挥电力能源风险管理的专业优势，为电力、煤炭、铝业等多个行业提供了保险经纪、风险咨询和产权经纪服务，是国内具备核电运营期保险安排经验仅有的三家公司之一，是国内海上风电全流程保险安排经验最丰富公司之一，是国内最大的光伏综合保险中介服务商。

系统建设目标：

通过平台建设推动科技化转型。通过数字化保险平台建设推动科技化转型，利用前沿的金融科技手段，满足集团产业发展的保险需要，探索新的保险营销及服务模式，推动公司从传统业务向互联网等新型业务转型发展。

满足精细化保险管理需求。建立完善的数据收集和分析平台，通过数据对接，将保险基础数据进行自动采集，并利用大数据及人工智能等技术，细化收集到的基础信息，实现保险数据的实时分析和可视化管理（智能驾驶舱），提升数据应用能力，为公司精细化保险管理提供数据支撑。

将保险经纪品牌做大做强。搭建包括咨询、投保、理赔、培训、风险管理等全流程的线上服务，为客户在保前、保中及索赔等各个环节提供优质的保险服务，从而提高客户体验度。同时，通过平台构建各类型客户全景图像，通过综合性数据分析，有针对性的开展营销工作，强化公司整体营销能力及工作效率。

提高公司业务管理水平。通过平台实现公司所有业务线上化、标准化、智能化管理，保证公司所有业务的合规性和数据完整性，提升公司业务管理的整体效率和风险防控能力，降低管理人员成本。同时，通过业务数据智能分析，为公司战略发展决策提供数据支撑.

1.1.2 建设原则

系统设计阶段是将系统需求分析阶段确定的逻辑模型转换为物理模型。系统设计阶段是软件工程项目开发的重要阶段，系统设计的完善程度对系统实现阶段的工作具有决定作用。因此，系统设计阶段工作必须按照系统需求分析阶段确定的需求，采用系统设计技术全面的完成设计方面的各项工作。本章将保险业务管理系统需求分析阶段确定的功能与非功能需求，完成系统的设计工作。

系统的整体设计思路：主要考虑系统的稳定性、安全性、可维护性、重用性、扩展性、开放性、先进性，确保在系统稳定的前提下，使系统具有较强的生命力。

1．合适性，合适性是指系统设计的内容是否符合系统需求分析阶段确定的功能与非功能需求。因此，在对保险业务管理系统进行设计时，必须严格按照《保险业务管理系统需求规格说明书》中所确定的功能与非功能需求展开设计。例如，对系统体系结构进行设计时，在需求分析阶段无法确定系统采用何用体系结构，所以在系统设计阶段必须考虑系统的功能与非功能性需求，以及结合当前主流的软件体系结构，发挥程序员的主观能动性，综合各方因素，设计合适的系统体系结构。

2．可复用性，可复用性是指开发的管理信息系统源代码、体系架构等可复用到新的管理信息系统开发中。这样使得开发新管理信息系统的成本便会降低。同时被复用的系统由于经过长期的运行，在系统稳定性方面有保证，使得新系统的开发风险降低。随着保险公司信息化程序的提升，会采用更多的管理信息系统

实现全面信息化管理，为降低后续系统开发的成本，在对保险业务管理系统进行开发时，应充分考虑保险公司经营中的共性问题，设计出一种通信型的软件体系结构，这样便能保证保险公司后续开发管理信息系统时能被有效复用。

3．可扩展性，可扩展性是指系统现阶段开发完成后功能扩展的容易度，如果系统后续扩展功能容易则说明系统可扩展性强，表明系统适应技术变化、用户需求变化的能力强。可扩展性是衡量一个系统质量的重要指标，特别在现代信息技术与用户需求变化越来越快的背景22下，管理信息系统必须能具有极强的可扩展性，能快速的适应各类变化，以降低因对系统扩展功能所造成的机会成本。基于可扩展性原则，保险业务管理系统进行设计时，必须综合考量所选择的开发技术、体系结构等，首先要保证在技术上具有一定的领先优势，以适应技术更新变化所带来的冲击。其次，在体系结构方面应采用多层结构，以保证系统在对某项功能进行扩展时，不会对整个系统运行造成影响。同时，系统模块间要保持低耦合，以保证系统模块间的关联度低，使得系统在对某个模块进行扩展时，对其它系统模块的影响最小。

4．准确性原则，保险业务管理系统存储着保险公司大量的保险业务数据，涉及到企业财务数据与客户个人信息，所以对数据的准确性要求较高。因此，系统设计时必须考虑准确性原则。在系统设计过程中必须保证系统输入与输出数据的准确性，同时还必须具有相应的纠错机制，以保证用户输入数据的准确性与系统输出数据的准确。

5．标准化原则，为了提高系统的可扩展性与灵活性，系统设计必须遵守标准化原则。例如在数据库设计时必须符合数据库管理系统的设计标准与规范；在使用第三方控件与工具时必须采用符合标准的控制与工具等等，这样才能有效的降低项目风险，也有利于系统功能的扩展。

6．安全可靠性，系统应保证7*24小时持续、稳定、安全地运行。要求对关键数据进行加密存储，设定用户对系统不同模块的不同级别操作权限。建立日志文件，跟踪记录用户对系统每一次操作的详细情况。制定可行的重要数据备份恢复策略、安全控制机制、运行管理监控和故障处理手段。对紧急情况应有相应的应急处理措施，具备灾难恢复等功能。

1.1.3 保险行业规范文件

相关法律和司法解释：

(1) 《中华人民共和国保险法》

(2) 《中华人民共和国海商法》

(3) 《中华人民共和国道路交通安全法》

(4) 《中华人民共和国交通安全法实施条例》

(5) 《中华人民共和国外资保险公司管理条例》

(6) 《保监会规章》

(7) 《保险行政规章制定程序的规定》

(8) 《法定分保条件》

(9) 《分红保险管理暂行办法》

(10) 《投资连结保险管理暂行办法》

(11) 《人身险法定分保条件实施细则》

(12) 《人身保险产品定名暂行办法》

(13) 《长期健康险法定分保条件》

(14) 《向保险公司投资入股暂行规定》

(15) 《财产保险条款费率管理暂行办法》

(16) 《保险兼业代理管理暂行办法》

1.1.4 信息技术标准规范

（1）GB50174-2008《电子信息系统机房设计规范》

（2）GB50174-2008《电子信息系统机房设计规范》；

（3）GB50462-2008《电子信息系统机房施工及验收规范》；

（4）GB/T 21052-2007《信息安全等级保护 信息系统物理安全技术要求》；

（5）GB/T21064-2007《电子政务系统总体设计要求》；

（6）GB/T 20987-2010《信息系统灾难恢复规范》；

（7）GB/T 20984-2007《信息安全技术信息安全风险评估规范》；

（8）GB/T 22239-2008《信息安全技术信息系统安全等级保护基本要求》；

（9）GB/T 22240-2008《信息安全技术信息系统安全保护等级定级指南》；

（10）GB/T 25070-2010《信息安全技术信息系统等级保护安全设计技术要求》；

（11）GB/T 31167-2014《信息安全技术云计算服务安全指南》；

（12）GB/T 31167-2014《信息安全技术云计算服务安全能力要求》；

（13）GB/T 20281-2015《信息安全技术防火墙技术要求与测试评价方法》；

（14）GB/T 20279-2015《信息安全技术网络和终端设备隔离部件安全技术要求》；

（15）GB/T 20271-2016《信息安全技术信息系统通用安全技术要求》；

（16）GB/T 20269-2016《信息安全技术 信息系统安全管理要求》；

（17）GB/T 22080-2016《信息安全技术信息安全管理体系要求》；

（18）GB/T28449-2018《网络安全等级保护测评过程指南》；

（19）GB/T22239-2019《网络安全等级保护基本要求》；

（20）GB/T28448-2019《网络安全等级保护测评要求》；

1.1.5 技术路线

本次系统建设涉及多个应用系统的整合、涉及到与省平台的交互，系统功能复杂，稳定性要求高，为满足系统的要求，必须选择一个优秀的应用开发平台。

本方案应用系统开发选择在JAVA架构下构建系统。使用目前流行的多种web技术，包括Spring MVC4.0+,MyBatis,Apache Shiro,ehcache,Jquery,Boot

Strap,WebSocket等等，支持多种数据库MySQL,Oracle,sqlserver等。分层设计：使用分层设计，分为dao，service，Controller，view层，层次清楚，低耦合，高内聚。安全考虑：严格遵循了web安全的规范，前后台双重验证，参数编码传输，密码md5加密存储，shiro权限验证，从根本上避免了SQL注入，XSS攻击，CSRF攻击等常见的web攻击手段。

1、基于微服务理念的扁平化设计架构

以微服务理念为基础、扁平化涉及架构为主导方向设计思路下的产物，使得监测汇聚平台在现场部署、功能开发方面与传统架构相比具有松耦合、即时扩展、易于管理、方便部署的先天优势。

2、高可用分布式部署

支持高可用分布式部署，具有应用分布式部署、应用/模块/功能集群化部署、功能/模块冗余、灾备恢复、标准工序自动化执行等功能，使得用户在系统运维方面有得天独厚的优势。

2、支持多屏联动

支持单屏、双屏、三屏、异形屏模式，实现4K、8K、异形屏等高分辨率下的各种展示模式下，均可支持各屏之间的联动。

4、支持多租户模式

支持不同租户的同一功能实现可以配置为功能服务组的不同选项。

5、支持标准WebRtc协议

支持通过标准的WebRtc协议进行音视频码流的传输。

6、支持GB28181国标协议

支持通过GB28181国标协议对接目标上级或下级平台。

7、支持chrome浏览器无插件浏览

传统监控客户端浏览监控图像之前需要安装各种软件、插件以达到能解码不同厂家音视频码流的目的，但是用户查看图像时常会出现图像无法正常显示的情况。系统支持chrome浏览器无插件浏览，从根本上解决用户监看音视频图像之前安装的种类繁多插件的痛点。

8、支持标准RTP/RTCP协议

RTP/RTCP协议是目前行业内使用的最多的多媒体流实时传输协议。监测汇聚平台基于RTP/RTCP协议提供码流传输、音视频同步、传输质量反馈等功能，达到优秀的码流传输体验。

9、提供Restful接口

Restful是一个基于http的功能强、性能好、适宜通信的架构风格，监测汇聚平台提供Restful API供第三方使用，真正的实现了前端和后端完全的分离设计，大大降低了开发难度。

10、支持RTSP协议、RTMP协议

RTSP/RTMP协议是常用的网络直播流协议，视频汇聚模块作为音视频资源处理平台，支持处理各种主流网络直播流协议，能在更多场景下提供更好的音视频资源。

1.2 网络拓扑设计

保险业务管理系统采用三层C/S体系结构，在物理上分为客户端、应用服务端与数据库服务端。因此，系统网络结构设计除包括这三层外，还必须有网络设备与网络支持，同时为了提高系统的安全性，在网络中还必须配备相应的网络安全设备，例如防火墙、入侵检测系统等等。保险公司下面有分公司与保险业务代销机构等机构，所以客户端必须分布在各级管理单位内。因此，系统将运行在局域网与Internet网内，为提高系统运行网络的安全性，分布在分公司与保险公司

代理公司的系统客户端将采用VPN方式与应用服务端进行连接与通信。

1.3 系统安全设计

1.3.1 总体建设任务

随着政务业务的快速发展政务业务数据流量的迅速增加，使得业务网络变化和设备增加，令网络变得连接混乱，功能区域不明显。加上建设数字政府项目，对现有的网络系统带宽和转发能力、传输网络的带宽及安全性提出了更高的要求。为适应数字政府建设发展需求，必须对现有的网络进行万兆升级改造。

通过升级核心网络来完善统一的县级大数据共享中心共享平台，为各种业务提供高可靠、高性能、可扩充的基础网络平台；并将各个接入单位的带宽提升到万兆，消除信息交换的瓶颈；通过高性能的交换机搭建数据中心，同时对服务器群提供负载均衡功能；利用网络管理软件实现集中的网络服务和网络管理；通过重新的统一规划，完善现有数字政府网络系统。

1.3.2 网络框架设计

本期项目采用VLAN、链路聚合、网络虚拟化、OSPF、MPLSVPN、SDN等网络优化部署手段确保电子政务外网网络的可靠、稳定传输。

1.3.2.1网络虚拟化

虚拟化技术的核心思想是将多台设备连接在一起，进行必要的配置后，虚拟化成一台设备。使用这种虚拟化技术可以集合多台设备的硬件资源和软件处理能

力，实现多台设备的协同工作、统一管理和不间断维护。

1.3.2.2SDN（软件定义网络）

SDN（软件定义网络）是一种新型网络创新架构，将网络资源统一资源池化并集中管理，使得资源随需而动、应需而变。其核心思想是：

控制层面与转发层面分离：无须依赖底层网络设备，屏蔽了来自底层网络设备的差异，降低总体投资成本。

集中的控制层面：从全局角度出发，进行统筹控制，实现整网行为一致，对网络流量实现灵活、集中、细粒度的控制，网络所见即所得。

开放的编程接口：应用和网络的无缝集成，通过公开的、开放的编程接口，用户可以自行开发网络新功能，实现对网络资源的按需调配和应用创新。

SDN的关键益处如下：

面向业务：可容易地与计算功能整合，便于开展资源管理和维护。它可以更好地使网络与业务目标保持一致。

可定制：任何一名开发人员都可编写软件，在网络的使用方式、操作方式上实现灵活性。

更敏捷：用户能够以更快的速度获得想要的功能，无需等待供应商后续提供。根据业务需要按需部署，即时上线。

更简单：通过一个控制点就可以对整个IT作业情况进行管理。降低管理复杂度和减少人工操作可能带来的错误，从而减少网络故障时间，因为可自动进行网络配置，减少人工配置的数量。

SDN相比传统网络有了革命性的变化，不再是原有体系结构的修补和提升，而是从根本上改变了网络。SDN将传统网络设备的控制功能从网络设备的“盒子”里提取出来用进行集中控制，并向上层的业务系统（应用系统）开放接口，可以由上层应用系统直接调度网络资源，创造了真正能“随业务需求而动”的自定义式网络。

ONF是一家非盈利的组织机构，成立于2011年。ONF致力于SDN的发展和标准化，是当前业界最活跃、规模最大的SDN标准组织。成员范围涵盖运营商、网络设备厂商、IT厂商、互联网服务提供商等不同领域。ONF提出的SDN架构如图所示。

ONF SDN架构图

1.4 业务管理系统

业务管理系统主要建设项目管理、合同管理、统计报表、财务费控等若干模块，同时需要对接从业人员管理系统的人员数据，对展业相关的经纪人、销售员进行同步和监控，以满足监管合规要求。

1.4.1 项目管理

项目管理系统，是在网络办公基础平台之上开发出的项目管理系统，该系统不仅可以提供给项目实施部门使用，而且可以扩展成为协同作业平台，涉及项目执行过程控制、项目费用综合控制等，构筑全面的项目管理综合工作平台。

软件以项目管理为核心，不仅实现成本、进度、信息、沟通协调等项目业务处理细节，实现项目全方位管理，而且实现资金、人力、资源等各个方面的统一管理。

项目管理系统主要实现项目过程的管理、项目群的管理、人才的管理、知识的管理四大部分，实现项目的可持续改进与跟踪并为管理层和决策层提供企业战略和关键项目的“地图参考”；协助企业快速成功地解决问题、精益求精、创造可持续价值。

角色功能包括：

超级管理员

管理管理员

管理用户

系统管理员

管理用户

管理项目

企业领导

项目审批

项目统计报表

项目信息

项目管理

个人信息管理

项目的评论

待办事项

其他功能

项目经理

项目信息

项目审批

项目统计报表

项目进度管理

个人信息管理

项目的评论

待办事项

其他功能

项目成员

待办事项

个人项目

项目信息录入

审批进度查阅

个人信息管理

话题讨论

其他功能

系统基本信息设置 系统基本信息设置

管理帮助信息

其他功能

管理帮助信息

其他功能

功能一览表

模块

登录

1. 人员登录

1. 项目立项

2. 项目新增

3. 项目过程管理（项目进度管理）

4. 项目进度审批

项目管理

5. 项目阶段任务分配

6. 项目收益

7. 项目评审

8. 项目群管理

9. 项目统计报表

1. 人员基本信息

2. 人员所做项目信息

人才管理

3. 人员履历信息（证书、职称等）

4. 晋级管理

5. 人员报表统计

知识管理

1. 全文检索功能

2. 文档模板管理

功能说明 备注

3. 文档管理

4. 文档分权限查看

5. 文档上传、下载

6. 文档统计报表

1.

2.

权限管理

3.

4.

5.

6.

用户信息管理

系统基础信息设置

角色管理

权限分配管理

流程管理

系统日志

1.4.1.1 项目立项

项目经理对年度需要做的项目进行立项，领导进行审批后方能进行项目基本信息的填写。

1.4.1.2 项目新增

项目新增，需要满足如下功能。

 根据项目管理的不同类型，可以采用合适的项目管理模板新建项目，这样新建项目时便可以选取模板直接使用

 提供创新研究型项目模版，可实现6Sigam项目和TRIZ项目新增

 项目新增完成后，创新研究型项目，直接带出阶段模版（包含任务和工具）

1.4.1.3 项目过程管理

1) 项目管理概念框图

流程交流项目管理文档成本缺陷客户

进度

2) 实现过程管理主要业务

 计划阶段

可实现项目经理创建项目、组建团队，制定项目计划、分配任务给相关成员。

 执行阶段

项目经理在执行在计划制定完毕后，可申请项目所需款项并实时记录项目支出情况；项目成员执行项目计划，可在执行过程中进行项目沟通，每日汇报工作任务，上传项目文档；项目经理进行工作确认，并在项目结束时进行工作总结

 监控阶段

项目经理可随时对项目的进度、成本状况进行监控；QA可以对项目进行质检，并在系统中记录检查结果；公司领导拥有查看所有项目状况的权限，可以实时了解项目状况，并设置关注项目进行重点监控。

 变更阶段

项目执行过程中可及时调整项目计划及预算计划，以保证项目的有效完成。

3) 项目审批功能

 普通项目流程审批功能，需要一个完整的工作流。包含但不仅限于：立项审批，立项评审，阶段审批，阶段评审，财务审批。

 创新研究型项目，需要财务收益的审批，项目完成后，希望继续追踪12个月的财务收益。

 可自定义审批流程

 审批操作的可视性，系统在明显的位置指引用户进行审批发起，审批通过等操作。

4）项目的阶段任务

 普通项目的阶段名称可以灵活配置。阶段状态可用对应的颜色明显表达（如：进度延迟：红色）。

 阶段任务采用卡片式设计，可灵活拖动摆放。

 阶段内任务，“我的任务”中显示自己的工作任务，“所有任务”显示的是所有项目组的项目人员的工作状况，项目阶段、项目的责任人及进展程度等。

 任务可关联附件，工时，执行人员等基本信息。

 特殊要求：任务可关联任务执行中使用的工具（如：鱼骨图，亲和图等）。

 相关人员可对任务进行评论操作。

5）项目协同功能

项目协同是项目小组的交流平台，在这里能够进行查询项目的工作任务、分享任务心得，互动评论等操作。

6）项目监控功能

 项目状态

项目立项流程、项目总结流程，无论是流转中还是已结束，反馈的是实际的项目状态；而项目基本信息变更流程，无论是流转中还是已结束，反馈的项目状态是项目执行中。

 项目进度

进度状态有2种：正常（进度偏差>0）、滞后（进度偏差<0）。

 项目人数

该项目的实际项目成员数。后期加入人员也统计在内，这里指实时统计人数。

7）项目工具集功能

 提供项目执行中使用的工具集（鱼骨图、排列图、散点图）。

 工具的产出可挂载到任务上。

 特殊工具，提供使用说明。

 特殊要求：提供TRIZ工具集。

8）项目收益追踪功能

项目收益包含如下功能：收益定义，收益度量，收益追踪功能。

9）项目综合管理

 项目综合管理包括项目的成员管理、项目风险管理、文档管理等。工具的产出可挂载到任务上。

 项目评审功能，可针对阶段任务，审核内容进行评审。

 特殊要求：项目总览功能（包含项目基本信息，项目阶段信息，项目任务信息，项目财务收益），提供打印，下载功能。

1.4.1.4 项目群管理

1) 项目群管理的框架：

2) 满足如下的项目群执行流程：

3) 多项目成本管理

 根据工时自动计算项目人工成本

 实时自动地把项目的成本关联到项目群的成本

 根据销售订单与合同自动计算项目收入

 根据采购订单与合同自动计算采购成本

 根据费用报告自动计算各项费用

 根据采购需求和采购订单自动检查供应商的发票

 开票时间与逾期管理

4) 多项目沟通管理

 项目自动预警与通知

 交付成果的查看与审批功能

 团队沟通功能，可评论互动

5) 多项目实时监控与跟踪

提供项目查询功能，方便了解企业超支项目、滞后项目、变动过的项目等，并且可以设置自己关注的项目，便于PMO宏观掌握企业项目的整体状况。监控指标如下：

 项目总概览：指定项目的开始时间范围，只要项目开始时间在此时间段内，都可查询到。

 项目阶段：按阶段分类。

 执行中项目个数：执行中的项目数之和。

 终止项目个数：已终止结束的项目个数。

 已完成项目个数：总结完成的项目个数。

 重点关注：关注项目的个数。

6) 多项目综合管理

多项目综合管理包括多项目质量管理、多项目风险管理、多项目资源管理等。

1.4.2 合同管理

目前，由于合同缺乏统一的存放管理平台，要查找某合同、补充协议或函件，可能需要到KM系统、档案管理系统、M盘、AI系统、电子邮件、业务经理个人电脑或者信件传真等纸质文件中查找，非常不方便。

1.4.2.1 合同管理现状

 合同管理制度待完善

合同定义：制度已对合同进行定义，但未能有效传达各部门，理解偏差导致合同归档的完整性得不到保证。

合同分类：未建立合同分类标准。

合同要素：合同关键信息要素模板分散化，各部门管理的程度以及需求不统一，部门间未形成要素信息共享。

合同范本：未明确合同范本的管理流程。

合同对手方库：未建立合同对手方库及相关管理规则。

合同管理细则：合同全生命周期相关管理细则有待更新完善，例如，制度中缺乏维护合同有效期的相关规定。

 合同管理组织架构待完善

组织架构：目前公司未明确合同管理职能的承担部门，整个合同管理较为松散，未建立监督及问责机制。

岗位职责：目前尚未明确前后台部门之间对于合同的传递、归档、要素化的职责分工与信息共享机制，此外，各部门业务助理兼任合同管理员，但尚未细化和明确其岗位职责。

 补充协议及函件的传递归档待规范

对于部分合同后续履行阶段可能出现的补充协议及函件，存在传递不及时、未进行归档的情况，影响合同传递的时效性和归档的完整性。

 无法掌握公司合同数量及管理状况

合同归档：由于缺乏统一平台，各部门合同管理水平不一，合同存放分散，合同查找和检索的效率低下，不能随时掌握公司合同管理情况。

合同有效期：现有系统都不具备合同到期提醒功能，并且由于无法获取完整的合同清单，现阶段依靠手工管理也很困难。

 合同号的配发缺乏系统控制

目前合同号的生成依靠档案管理系统手工录入，系统无法自动配发，且合同号可删除，缺乏统一管理。

 当前系统合同管理功能不足

KM系统：承担合同审批及用印申请（部分另类合同除外）的职能，缺点是合同版本为过程版本，并非最终盖章生效版本，且合同审批混杂在其他事项审批中，不便于查找。

档案管理系统：承担获取合同号、保管合同最终用印版本的职能，缺点是合同号配发缺乏系统控制，由于合同定义不清晰使得合同归档完整性得不到保证，合同要素信息填写不完全，主从合同之间的关联关系依靠手工维护缺乏专门的系统功能。

M盘：承担部门内共享及临时存放的职能，缺点是没有操作记录，误删除等情况不易被发现，且存放混乱缺乏维护。

AI系统：目前另类投资项目从审批到投后管理已全流程纳入AI系统，但AI

系统文档管理功能较弱，仅起到归档保管作用，缺乏合同要素模板和有效期管理等功能。

AD域：AD域的用户管理未做统一用户信息的管理和验证。

1.4.2.2 业务需求

根据用户现状的梳理，以及相关业务系统的调研分析，整理出合同系统的相关业务需求。

 合同管理系统需要明确合同的定义，以及归档范围，履行合同的相关制度，明确合同的基本要素，并对基本要素进行补充和整理。

 实现对对手库的相关信息进行整理和维护，建立完善的合同管理对手库信查询功能。

 实现对合同范本的管理和使用，建立完善的合同范本库。

 完善合同的审批和流转操作，建立强大和独立的流程引擎平台，对合同以及相关第三方系统提供流程审批支持，并对合同的状态和合同的到期时间进行自能化的提醒。

 建立标准化的平台数据对接规范，实现合同系统与各业务系统的数据对接和交换。

建立主从合同的关联关系，并提供方便的查询功能。

1.4.2.3 总体结构设计

合同管理数据展现层

认证管理

组织合同管理合同审批

合同审批

合同审批

合同审批

合同管理合同审批

合同审批

合同审批

合同审批

数据库 & LDAP

合同管理合同审批

合同审批

合同审批

合同审批

邮件服务

文件服务

短信服务

加密服务

域控服务

1.4.2.4 功能描述

1.4.2.4.1 合同管理

合同管理下包含所有当前登录用户经办或代办的全部合同信息。合同管理包括我的合同、合同起草、合同签署及用印、合同履行、合同归档几大部分。

1.4.2.4.1.1 我的合同

我的合同包含合同管理下所有当前登录用户经办或代办的全部合同信息。

1.4.2.4.1.2 合同起草

1）、合同号获取超过7天未进行发布的，系统给经办人（代办人）发送提醒信息。

2）、合同发布后会显示在“合同签署及用印”列表下，发布后的合同信息不能再进行删除操作。

3）、用印形式为“不用印”的，填写完签署日期和生效日期后，部门档案管理员可以进行归档申请。

4）、合同起草可以批量生成100（手动填写份数）份以下的相同合同内容，合同号手动进行获取。

5）、公司合同管理员可以导出全部合同信息列表excel到本地（合同起草

合同管理系统

统一流程引擎

管理

账户管理

列表），字段：经办人、经办部门合同名称、

合同号。

6)、合同到期日期、合同费率（费率类型、费率种类、费率值）系统记录每次经办人（代办人）修改前后的记录。

7)、经办人（代办人）筛选到对应的主合同后（可以筛选全部的合同列表）将主合同的相关信息带入到当前合同中。带入的字段为（其它主合同信息不显示）：

合同名称、合同分类、合同主体、合同对方

8）、经办人（代办人）所填写的合同一旦在起草中发布，当前合同的状态更新为“签署中”；签署日期填写完成后再发布合同状态更新为“已签署，未生效”；生效日期填写完成后再发布合同状态更新为“已生效”。

1.4.2.4.1.3 合同数据项

数据项名称 数据类型 是否必填 数据来源 备注说明

合同起草页签

经办人（代办人）填写

登记日期 日期 必填 系统自动生成当前日期

是否代办 字符 必填 是/否 有代办人角色可见；具体见下文说明1；

代办人 字符 系统计算 有代办人角色可见；

具体见下文说明1；

经办人 字符 必填 系统默认当前登录人，可选择

经办部门

主合同编号

字符

字符

必填

系统计算

选择/手动填写

具体见下文说明1

弹出搜索页面关联查询自动带出主合同要素的相关信息

主合同名称 字符 选择/手动填写 弹出搜索页面关联查询自动带出主合同要素的相关信息

合同名称 字符 必填 手动填写 标识提醒：请填写合同名称全称

合同编号 字符 必填 系统按一定规则自动生成

点击按钮获取，校验前几项是否填写；

具体见下文说明2；

具体见下文说明1

合同一级分类

合同二级分类

是否客户指定业务

字符

字符

字符

必填

必填

必填

下拉框选择

下拉框选择

是/否

具体见下文说明3

具体见下文说明4

帮助中进行内容说明，便于选择是否；

选择“是”，页面提醒经办人将客户指定投资指令作为合同附件上传；

默认为空；

项目简称 字符 下拉框选择 弹出搜索页面

关联查询；

具体见下文说明5；

产品简称

（多个产品

需填写）

币种

币种

币种

合同币种 字符

金额（大写）

金额（大写）

金额（大写）

必填

金额（小写）

金额（小写）

金额（小写）

下拉框选择

字符 多选 弹出搜索页面

关联查询；

具体见下文说明6；

删除

删除

删除

币种为无，金额不填写；

具体见下文7；

合同金额（大写）

合同金额（小写）

字符

数值

必填

必填

根据小写金额转换

手动填写

可选无

可选无、其他，可以手动填写内容；

具体见下文8；

合同费率

（费率类型、

费率种类）

字符 必填 费率类型下拉框选择；

费率种类对应固定和浮动两种方式；

合同费率

（费率值）

合同主体

合同对方

字符

字符

必填

必填

下拉框选择

选择

具体见下文10

自动补全；

标识提醒：请填写合同对方全称；

具体见下文11；

用印形式 字符 必填 下拉框选择 各方用印；

仅我方用印；

仅对方用印；

不用印；

具体见下文12；

字符 必填 可填写具体数值；

可选无；

具体见下文9；

合同签署页签

用印管理员、经办人（代办人）填写

用印完成情况 字符 必填 下拉框选择 已完成；

我司已完成，对方未完成；（各方用印）；

具体见下文13；

经办人（代办人）填写

签署日期

合同状态

日期

字符

必填

控件选择

下拉框选择

具体见下文14

中止签署；

签署中；

已签署未生效；

已生效；

已失效；

合同生效日期

合同到期日期

到期续签情况

日期

日期

字符

必填

控件选择

控件选择

下拉框选择

具体见下文15；

到期无异议续签；

自动顺延；

其它；

具体见下文16；

合同文本 必填 手动上传 上传一个附件；

具体见下文17；

合同附件

合同附件类型选择；

合同附件手动上传；

备注

发布范围

手动填写

手动选择

可查看该合同信息的人员，具体角色待定。

转移说明

转移附件

字符

手动填写

手动上传附件

转移申请时可见

转移申请时可见

可以上传多个附件，记录上传日期；

具体见下文18；

说明：1、当前登录人有代办人的角色，可以选择“是否代办”，默认为“否”，即当前登录人自己起草合同，系统自动计算当前登录人为“经办人”，当前登录人所在部门为“经办部门”；“是否代办”选择为“是”，即代办人替经办人起草合同，选择“经办人”，系统自动计算经办人所在部门；如不具有代办人角色，“是否代办”、“代办人”字段不可见。

2、“合同编号”，通过点击按钮按照一定的规则获取，获取合同编号前校验表单中“登记日期”、“经办人”、“经办部门”、“合同名称”是否已经完成填写，如未

填写完成给与提示，否则生成合同编号。

3、“合同一级分类”为可维护字段，从系统管理数据字典中获取。

4、“合同二级分类”为可维护字段，选择“合同一级分类”后自动筛选对应的“合同二级分类”内容，从系统管理数据字段中获取。

5、“项目简称”为可维护字段，选择项目简称会弹出新的搜索页面，页面内容为项目简称、项目全称、项目类型（其他字段不可见），可以进行查询选择需要的项目简称。

6、“产品简称”为可维护字段，选择产品简称会弹出新的搜索页面，页面内容为全部的产品信息，可以进行查询选择需要的产品简称。

（1）、一个合同编号下可以选择多个产品，选中多个产品后可以填写对应的多行“币种”、“金额”信息，默认值为“无”经办人可手动修改；

（2）、选中一个产品后填写“合同币种”、“合同金额”、“合同费率”的对应信息；

7、“合同币种”为可维护字段，可选择具体币种和无；

合同币种选择“无”，对应的“合同金额（大写）”、“合同金额（小写）”字段内容为“无”；

8、填写“合同金额（小写）”后自动计算“合同金额（大写）”，可以选择“无”或“其他”选择项，选择其他可以填写具体内容。

9、“合同费率”为可维护字段，可选具体费率和无。

10、“合同主体”内容为选择项，也可填写具体内容。

11、“合同对方”为可维护字段，新增合同发布完成会将合同对方的内容自动生成一条记录，下次再次新建合同可以选择到之前生成的记录；合同对方的内容可以进行自动补全；

12、“用印形式”内容为选择，分为各方用印、仅我方用印、仅对方用印、不用印几个选项，具体分以下几种情况：

合同主体

本企业

用印形式

各方用印

说明

办公室管理员完成用印并在系统选择“用印完成情况”

本企业 仅我方用印 办公室管理员完成用印并在系统选择“用印完成情况”

非本企业 各方用印 线下完成用印后，由经办人填写“用印完成情况”、“签署日期”、“合同生效日期”、“合同到期日期”

本企业

其它

仅对方用印 线下完成用印后，由经办人填写“用印完成情况”、“签署日期”、“合同生效日期”、“合同到期日期”

非本企业 仅我方用印 线下完成用印后，由经办人填写“用印完成情况”、“签署日期”、“合同生效日期”、“合同到期日期”

本企业

其它

不用印 不显示“用印完成情况”

13、“用印完成情况”内容为选择，分为“我司已完成，对方未完成”、“已完”两个选项；

14、“签署日期”用印完成情况为“已完成”发布时需填写签署日期，否则系统给与提示不允许发布；

用印完成情况为“我司已完成，对方未完成”的发布时该字段可以为空；

15、“合同生效日期”用印形式为“不用印”发布时需填写生效日期，否则系统给与提示不允许发布；合同状态选择“已生效”，经办人（代办人）需填写合同生效日期，否则不允许发布。

16、“到期续签情况”为下拉选择框，到期无异议续签、自动顺延、其它三个选项。合同到期前30天，系统给予提示提醒一次。如为自动续签则需要填写需要续签的时间（XX年）、合同到期日期两个字段，如选其它可以填写具体内容。

17、“合同文本”上传唯一一个附件（可以上传打包文件），未上传附件发布时系统给与提示。

18、“合同附件”可以上传多个附件，可以选择上传附件的类别，附件类别在系统管理中由管理员进行维护。

19、表单中增加“帮助”的链接，用于对合同要素各字段使用说明。

1.4.2.4.1.4 合同签署及用印

包含以下几种状态：中止签署、签署中，各个状态在系统中通过不同页签进行分类管理。

1.4.2.4.1.5 合同履行

包含以下几种状态：已生效、已失效、已签署未生效，各个状态在系统中通过不同页签进行分类管理，默认页签为已生效状态列表。

公司档案管理员确认归档后，经办人（代办人）在合同履行阶段可以修改非归档字段信息。

1.4.2.4.1.6 合同归档

状态描述：经办人（代办人）填写完成“签署日期”后形成的部门档案管理员待归档和已归档的列表。

经办人（代办人）填写完“签署日期”点击【发布】后，部门档案管理员可以在“归档”列表下查看此条记录，确认系统记录与合同文本内容无误后点击【归档申请】，由公司档案管理员进行归档复核确认。

部门档案管理员可以进行批量申请归档的操作。

1.4.2.4.2 合同提醒

1.4.2.4.2.1 系统提醒

显示当前用户预先设置过时间节点且即将或已经到期的文件，主要是提醒用户及时处理相应的事宜。

提醒类型及标题样式（括号中内容为红色字体）：

【合同到期】（还有30天）+合同名称（合同编号）

【进度反馈】（合同号获取超过7天未发布）+合同名称（合同编号）

【进度反馈】（我司已完成用印，对方超过XX天未用印）+合同名称（合同编号）

提醒条件：

1、合同到期日期前30天，系统提醒经办人（代办人）一次。

2、合同号获取超过7天未进行发布的，系统提醒经办人（代办人）、部门和公司合同管理员一次。

3、合同用印状态为“我司已完成，对方未完成”，30天后合同状态为“签署中”的系统提醒经办人（代办人），每30天提醒一次。

1.4.2.4.2.2 我的提醒

当前用户可以预先定制自己的提醒信息，以便及时处理相关合同事项。

选择对应的合同，设置提醒日期、提醒内容、提醒人员（默认提醒自己）。

数据项描述

数据项名称

登记日期

合同名称

数据类型

日期

字符

是否必填

数据来源

默认当前日期

选择

备注说明

可以选择到当前用户经办或代办的合同信息列表

不选择默认提醒自己；

提醒日期

提醒人

提醒内容

日期

字符

字符

选择提醒日期

选择提醒人员

手动填写

1.4.2.4.3 合同转移

1.4.2.4.3.1 转移申请

经办人（代办人）已经发布的合同信息，可以点击【移出申请】移交给下一个人作为经办人进行后续事项的处理，转移时可填写转移说明，可以上传转移的附件到系统上。

1.4.2.4.3.2 转移复核

接收人在我的待办和转移复核下可以看到需要移入的合同信息列表，点击【移入确认】，确认后经办人（代办人）不在有查看和修改该合同信息的权限。如原经办人（代办人）想再次查看需和系统管理员做申请，由系统管理员开放查看范围后可以进行查看。

1.4.2.4.3.3 转出记录

经办人（代办人）申请移出后，系统生成一条转出记录。记录转出时间、转出人、转出部门、合同编号、合同名称、合同状态、转入人、转入部门。

1.4.2.4.3.4 转入记录

接收人移入确认后，系统生成一条转入记录。记录接收时间、转出人、转出部门、合同编号、合同名称、合同状态。可以链接到原合同信息。

1.4.2.4.4 范本管理

1.4.2.4.4.1 范本类型管理

数据项描述

数据项名称

业务类型一级

名称

业务类型二级

名称

数据类型

字符

字符

是否必填

必填

必填

数据来源

手动填写

手动填写

备注说明

与合同一级名称相同

与合同二级名称相同

1.4.2.4.4.2 范本模版管理

数据项描述

数据项名称

业务类型一级

名称

业务类型二级

名称

范本名称

日期

维护人

版本号

修订情况

最新版本号

最新维护时间

是否生效

合同范本模版

数据类型

字符

字符

字符

日期

字符

字符

字符

字符

日期

字符

是否必填

必填

必填

必填

必填

必填

必填

必填

必填

必填

必填

必填

数据来源

下拉框选择

下拉框选择

手动填写

系统默认当前日期

系统默认当前登记人

手动填写

手动填写

手动填写

系统计算

是/否

上传附件

备注说明

可多次记录

多个版本号

说明：1、选择“业务类型一级名称”后可自动显示对应的“业务类型二级名称”。

2、每次修改都记录修订情况和最新版本号，形成多行的修改记录。

3、“最新维护时间”，每次修改版本号后系统自动记录最后的修改日期。

4、“是否生效”默认为“是”，范本模版管理员修改为“否”后表示已经失效，合同范本的模版附件不可以在下载到本地。

1.4.2.4.5 合同台账

通过合同台账可以查询一段时间内所有签订合同的明细情况查询（所有状态下的合同信息列表）。

台账统计页面如下图所示（字段为参考样式）：

数据项描述

数据项名称

标题

时间段

经办部门

经办人

合同名称

合同编号

主合同名称

主合同编号

合同一级分类

合同二级分类

项目简称

产品简称

合同金额

合同币种

合同费率

合同主体

合同对方

用印形式

用印完成情况

签署日期

合同状态

合同生效日期

合同到期日期

到期续签情况

合同文本

合同附件

数据类型

是否必填

数据来源

备注说明

说明：1、统计时可以通过选择【导出的列】来定制结果中显示哪些信息。

2、可以点击结果页面的导出excel，将统计结果以excel表形式导出到本地。

台账统计结果页面（字段为参考样式）：

1.4.2.4.6 相对方管理

新增合同发布完成会将“合同对方”的内容自动生成一条记录，下次新建合同可以选择到之前生成的记录；合同对方的内容可以进行自动补全；

1.4.2.4.7 档案管理

1.4.2.4.7.1 待复核

部门档案管理员在合同管理中点击【归档申请】后，会在档案管理【待复核】列表下自动生成一条合同信息的记录。系统档案管理员点击待复核的信息可以填写“档案编号（按规则系统自动生成）”、“归档日期”、“密级”、“保存期限”、“归档人”、“归档部门”、“备注”等信息，填写完成点击【确认归档】按钮，合同信息自动归档到对应的经办部门下。部门档案管理员可以查看本部门已归档的全部信息。

公司档案管理员可以选择批量归档，归档需要填写的字段按照默认值生成。

1.4.2.4.7.2 合同档案

合同档案按照组织结构的部门进行分类。

数据项描述

数据项名称 数据类型

部门管理员归档后系统自动生成

经办人

是否必填

数据来源

备注说明

归档以后，如果做转移，经办人和经办部门不变动

经办部门

合同名称

合同编号

主合同编号

主合同名称

合同币种

合同金额（小写）

合同主体

合同对方

合同签署日期

合同文本

系统档案管理员确认归档时填写

档案编号 数值

归档份数

归档日期

数值

日期

必填

必填

必填

按照规则系统自动生成

手动填写

系统档案管理员点击【确认归档】按钮后自动生成，可修改

下拉列表框

下拉列表框

系统计算

系统计算

手动填写

手动填写

2015-03-HT01-0001

2

密级

保管期限

归档人

归档部门

题名

备注

字符

字符

字符

字符

字符

字符

必填

必填

必填

必填

绝密、秘密、限制，默认“绝密”

永久、30年、10年，默认“永久”

经办部门档案管理员

即经办部门

默认当前合同名称；

可手动修改；

1.4.3 财务收付管理

1.4.3.1 功能划分

财务收付管理分为两大部分，一是收费管理，二是付费管理。收费管理包括保全收费、客户预存、续期预交收费、新契约收费、收费方式管理、续期催缴收费、收费日结和收费查询统计八个子模块。付费管理包括付费、付费查询和付费同结三个子模块。费用的查询都是以费用信息的录入为基础。

收费管理的主要功能有保全收费、客户预存、续期预交收费、新契约收费、收费方式管理、续期催缴收费、收费日结、收费查询统计，付费管理的主要功能有付费、付费查询、付费日结。

1.4.3.2 业务关系

交费登记类图中有实体类财务人员、界面类交费登记界面、控制类交费记录管理、实体类交费记录四个类，实体类财务人员与界面类交费登记界面的关系是多对一

的关系，界面类交费登记界面与控制类交费记录管理之间的关系是一对一的关系，控制类交费记录管理与实体类交费记录之间的关系是一对多的关系。

1.4.3.3 交费流程

交费登记时序图描述的是参与者财务人员与对象交费登记界面、交费记录管理类、交费记录之间传递消息的时间顺序关系。

1.4.4 承保管理

承保管理分为四大部分：录单管理、核保管理、出保管理和保单查询，该四个子模块在业务流程上有先后之分，即按顺序进行。录单时包括新单录入、无扫描件录入和联生投保单录入。核保管理包括保单核保、问题件通知书回收、问题件录入、投保人消炎、问题件查询打印和被保人校验六个子模块。出保管理包括保单生成和保单打印两个子模块。保单查询包括保单查询和状态查询。

录单管理的主要功能有新单录入、无扫描件录入、联生投保单录入，核保管理的主要功能有保单核保、问题件通知书回收、问题件录入、投保人校验、问题件查询打印、被保人校验，出保管理的主要功能有保单生成、保单打印，保单查询的主要功能有保单信息查询、状态查询。

界面结构：

保单录入图中有实体类承保人员、界面类保单录入界面、控制类保单管理、实体

类保单四个类，实体类承保人员与界面类保单录入界面的关系是多对一的关系，界面类保单录入界面与控制类保单管理之间的关系是一对一的关系，控制类保单管理与实体类保单之间的关系是一对多的关系。

保单录入时序图：

保单录入时序图描述的是参与者承保人员与对象保单录入界面、保单管理类、保单之间传递消息的时间顺序关系

1.4.5 理陪管理

理赔需要经过报案、立案、查勘、结算和结案五个过程。因此在设计时按这五个过程将理赔模块没计为报案管理、立案管理、查勘管理、理赔结算和结案五个子模块。报案管理包括报案信息的录入和报案信息的维护(查询、修改和删除)两个子模块。立案管理包括估损信息录入和维护、立案审核、立案和立案信息的查询打印五个子模块。查勘管理包括发起查勘、查勘录入、查勘审核和查勘信息维护四个子模块。理赔结算包括理赔计算、结算信息维护、结算审核和通融计算四个子模块。结案包括结案归档和档案查询两个子模块。

报案管理主要功能有报案信息录入、报案信息维护，立案管理的主要功能有估损信息录入、估损信息维护、立案管理、立案和立案信息查询打印，查勘管理主要功能有发起查勘、查勘录入、查勘审核、查勘信息维护，理赔结算主要功能有理赔计算、结算信息维护、结算审核、通融计算，结案的主要功能有结案归档、档案查询。

报案类信息：

报案信息录入图中有实体类理赔人员、界面类报案信息录入界面、控制类报案信息管理、实体类报案信息四个类，实体类理赔人员与界面类报案信息录入界面的关系是多对一的关系，界面类报案信息录入界面与控制类报案信息管理之间的关系是一对一的关系，控制类报案信息管理与实体类报案信息之间的关系是一对多的关系。

理陪时序图：

报案信息录入时序图描述的是参与者理赔人员与对象报案信息录入界面、报案信息管理类、报案信息之间传递消息的时间顺序关系。

1.4.6 分支机构开发

低碳公益是做好低碳宣传推广的同时将低碳行为以无偿的形式进行，通过仙居县县委宣传部组织相关低碳公益活动，系统用户可将绿币资产以无偿捐赠的方式参与，极力促进线上线下融合，改善城市生态环境，尽早防治环境污染和加强生态修复，建设可持续发展模式。

当前环保和低碳的生活理念还处于启蒙和逐步深化阶段，从企业到居民的低碳环保意识都亟待加强，一些处于低碳教育前线的政府机构、企业机构等进行的低碳活动仍较为单一分散，未能充分利用各方资源形成合力推行低碳生活。基于现状，双碳绿币系统构建一种有效的低碳公益推广模式，整合线上线下各种资源，致力于打造一个可持续发展且易于推广的低碳公益事业平台。

1.4.7 反洗钱管理

洗钱（Money Laundering）是将黑钱合法化，以隐藏资金来源为目的通过放置、培植、融合三个阶段，犯罪分子掩盖了犯罪收益的真实来源将资金以合法的形式回收。这一黑色的产业，以极快的速度成长为仅次于外汇和石油的第三大商业活动，每年给各个国家带来的损失巨大。

作为国家的中央银行，人民银行担负着维护支付、清算系统正常运转和银行结算账户监管的职能。当前，人民银行已经建成与各个金融机构畅通安全的计算机网络。每个省的银行结算账户系统也都统一了版本，建设反洗钱决策支持系统的硬件条件已经成熟。首先

将全省的银行结算账户信息适时导入反洗钱信息系统，通过给各个商业银行提供结算交易报送格式，由各商业银行自己提取符合进入反洗钱信息系统条件的账务信息，及时自动地送入反洗钱信息系统。这样，人民银行反洗钱部门能动态、全面地掌握任何关注单位或个人，资金流向。利用人民银行已经建成的“银行信贷登记咨询系统”，剔除掉合法的交易单位或个人的业务，保留可供关注的交易单位或个人的业务。实现信息的深加工，为及时发现犯罪分子提供智力支持。在人民银行内部建立反洗钱信息系统，服务器与银行信贷登记咨询系统服务器连接，及时查询反洗钱信息系统数据库中新增记录是否与信贷业务有关，以及时排除不需要的数据。另外，利用反洗钱信息系统分析结果，可以及时通知国家支付系统，以终止犯罪分子的洗钱行为。

国家反洗钱信息系统包括银行结算账户信息提取子系统、商业银行账务信息提取子系统、数据同步子系统、账务信息筛选子系统、反洗钱分析决策子系统、结算交易强制终止子系统、反洗钱报表子系统等多个功能模块。银行结算账户信息提取子系统负责实时地提取当地人民银行帐户信息。银行结算账户管理信息系统将数据库中新变动的结算账户信息传送到反洗钱信息系统数据库中。商业银行账务信息提取子系统负责实时地将各商业银行账务主机中新变动的账务信息传送到反洗钱信息系统数据库中。数据同步子系统保证提取的账户信息中账务信息始终与采集源一致。账务信息筛选子系统负责将反洗钱信息系统数据库中明显不属于洗钱业务的账务剔除掉。根据银行信贷登记咨询系统搜集的资料自动筛选，分析数据库中存在的洗钱交易。结算交易强制终止子系统及时通知国家支付系统，终止犯罪分子反洗钱交易。反洗钱报表子系统形成各种反洗钱报表数据，供公安监察等部门使用，联合做好国家的反洗钱工作。

1.4.7.1 系统建设面临的问题

1.数据采集问题

首先，反洗钱信息系统，需要金融机构、海关、税务及执法机构和商业数据。虽然我国金融机构、海关、税务已经有各自的信息系统，但还不能信息共享。执法机构和商业数据缺乏信息系统建设，还不能满足需要。其次，我国还没有制定反洗钱信息数据的格式、内容等电子数据的标准，而涉及到洗钱活动的机构数据收集也是各行其是，对将来建立反洗钱信息系统进行数据综合分析造成障碍。最后，一些机构采集的数据规范性差，由于目前海关、税务，按自己部门要求采集数据，而其他机构数据采集还处于分散状态。

2.缺乏科学的分析方法和手段

我国目前正在运行的一些相关的信息系统也都只具有比较简单的分析处理功能，不支持复杂的数学模型及人工智能分析技术，无法对金融数据进行有效的分析。对可疑金融交易有效的识别，仍然停留在依赖管理人员自身的业务素质、经验和直觉判断的基础上。

3.外部环境较差

我国反洗钱信息系统建设刚刚提上日程，与发达的欧美国家相比还有很大差距。美国已

经有大量的IT企业和技术服务企业，研发金融产品、设计方案和分析模型，为美国金融机构反洗钱提供大量支持。而我国IT业从技术上还无法达到发达国家的水平，采用技术外包方式，又因为涉及到国家部门安全、利益和法律等多方面原因，制约着我国快速建立反洗钱信息系统。

4.各个相关部门协调问题

打击洗钱犯罪涉及金融、司法、海关等多个相关部门，是一个系统工程，需要社会各界的协调与配合。中国反洗钱工作相关的各部门之间职责分工不够明确，合作机制有待完善。从现行国内外反洗钱协调机制的建立与运行状况分析，反洗钱工作既需要明确的主管机构，也需要各相关政府管理部门和执法部门的长效合作。

1.4.7.2 电子银行的洗钱风险

（一）电子银行业务的特殊性和隐敝性增加了发现可疑支付交易的难度。客户只需要拥有一台连接网络的电脑和一部电话，就可以突破时间空间的局限，随心所欲地完成转账、支付交易。犯罪分子利用电子银行的方便、快捷、可靠、无空间时间限制、客户资料隐蔽、远程操作的特点，从事洗钱活动。而各大银行从事反洗钱工作的人员却只是意力放在可疑的传统业务上，只关注大额存取款、转账等日常柜面业务，而对电子银行的流水账和分户账缺乏甄别分析，从而漏报或迟报可疑交易行为。

（二）电子银行交易信息无纸化的保存方式增加了对可疑交易监测和核查的难度。电子银行是客户通过网络或电话终端异地远程操作，故客户开户所在银行不能像传统业务受理一样，审查资金用途、金额，客户不能提供签名，也没有柜面录入。客户通过电子银行进行多笔大额资金汇划转账也不容易被察觉，且不用向银行说明资金用途。没有了原始单据，就只能通过流水账和分户账进行分析判断，加大了监测和核查的难度。

（四）电子银行的交易特点使得银行了解客户难。了解自己的客户是反洗钱工作的基础，而电子银行恰恰增加了此项工作的难度。客户不用和银行相关人员见面就可以完成操作，虽然在开设电子银行账户时有提供一些客户资料，签订过一些协议，但资料过于简单，银行也没有定期对电子银行账户客户资料进行核实审查，对于客户的资料变更也无从得知。银行系统内部对于电子银行客户交易情况的记录保存方法也不统一，保存数量不明确，造成目前交易流水记录覆盖以往交易流水记录，增加了基层监管部门对历史交易数据核查的难度，形成了资金监测的“死角”，给洗钱案件的侦破带来巨大的困难。

（五）电子银行业务因其隐蔽性特点备受犯罪分子青睐

与传统业务相比，电子银行业务采用的是账号（或者ID）验证及证书验证方式，只要客户提供正确的账户信息、客户证书和密码，甚至只需输入手机号，银行系统则认可交易操作的有效性。并且，只要在账户余额不透支的情况下，客户便可通过互联网随意地汇划资金，无须注明用途。银行很难对其资金进行事中的监控和事后的分析。

电子银行突破了时间和地域的局限，客户可以在任何时间、任何地方、以任何形式通过

互联网络或电话完成各种支付交易，实现7×24小时全天候操作，使洗钱者进行资金转移更加便捷，存在被不法分子利用进行资金快速转移的极大风险。

1.4.7.3 电子银行的对策和建议

（一）增强银行内部合力，提高对电子银行反洗钱工作的重视

金融机构首先要对电子银行洗钱的资金汇划的快捷性、身份运作的隐蔽性、操作地点的任意性给予高度重视。充实反洗钱力量，设立专职人员，确保反洗钱工作尤其是可疑交易信息核查落到实处。同时要组织相关部门对新业务进行一次重点排查,重点防范电子银行渠道洗钱风险。其次，各银行要加强反洗钱的内部组织协调工作。由于网上银行的反洗钱工作涉及银行内部诸多部门，应加强领导，提高认识，明确责任，杜绝工作中互相推诿现象发生，使银行内部相关职能部门之间形成合力，共同做好反洗钱工作。

（二）严把客户的审核关，切实履行“了解客户”义务

银行应按照反洗钱法律法规要求，认真做好客户调查工作，从源头防范洗钱风险。

首先，在银行开立账户必须通过公民身份信息联网核查系统验证，并严格审查申请人的身份证件及开户材料。各级银行要建立统一系统的客户资料库，从了解客户做起，将客户的真实姓名、住址、联系方式、工作地点、收入等涵盖在客户资料库中，并规定更新年限，对到期的客户资料进行更新。

第二，对电子银行设置严格的准入条件。经严格审核和筛选，符合条件、信誉度好的客户，才能为其提供电子银行服务，并签订规范、严密的服务协议，以明确责任。

第三，金融机构对开通电子银行业务的账户应适当提高风险等级，并对客户基本信息至少每半年审核1次，经审查认为使用网银业务理由不合理的，应拒绝受理其申请。

第四，在客户开办电子银行业务后，银行发现客户的交易行为违反协议、交易情况存在疑点，应暂停或中止其电子银行业务，从源头缩小洗钱活动的生存空间。

（三）建立、健全电子银行支付规范，完善内控机制

应建立电子银行风险评估机制，明确电子银行风险管理职能部门，建立健全电子银行业务内部审计、合规和后续评价机制，以及时发现风险隐患。并且，应针对电子银行的业务特点建立系统化的电子银行反洗钱内部工作机制，细化标准，以利于执行过程中把握政策尺度，保障反洗钱全过程有效涵盖电子银行业务。

(四)提高监控工作水平，加大对电子银行业务的监控力度

金融机构加强对从事反洗钱工作相关人员的培训，提高各金融机构工作人员对可疑交易的识别能力。在可疑交易数据的监控、上报工作中明确建立人工识别流程。改变单纯依靠系统提取数据上报的做法，做到系统提取与人工甄别相结合，避免上报垃圾信息。针对电子银行业务开发实时监控软件，对开通电子银行业务的账户实行实时监控，依靠现代化的监测手段增强反洗钱监测的及时性和有效性，提高可疑交易的报告水平。

1.4.8 统计报表

通过不同的维度对保险业务进行统计分析，定期实现保单业务数据汇总、业绩统计、业务量统计等，实现保险业务的增长分析、理赔分析、佣金核算分析等。

1.4.8.1 保单、保费统计

定期对系统中产生的保单、保费按时间周期进行汇总，从不同角度进行统计，提供业务部分析和决策。支持根据多个维度和汇总、聚类、下钻逻辑生成保单数量、保费规模等相关保单统计指标的统计结果，并支持导出XLS格式方便打印和汇报。

1.4.8.2 赔案统计

案件理赔决定了保险的成本开支、定期对理赔的案件进行统计分析，总结理赔案件的特点和规律、从而可以有效规避案件的发生。赔案统计支持按多个维度及汇总、聚类、下钻逻辑生成赔案数量、理赔总金额等数据指标的统计结果，并支持导出XLS格式。

1.4.8.3 渠道佣金统计

渠道佣金是保险的主要开支来源，系统定期对不同渠道的，不同产品等维度的数据进行统计分析，得出佣金开支的情况，与产品的匹配程度，可以发现佣金异常问题、从而有效控制无用的销售费用的发生。佣金统计支持按多个维度及汇总、聚类、下钻逻辑生成渠道保费、渠道佣金收入的明细或汇总统计数据，并支持导出

1.4.8.4 监管数据报送

定期生产监管部门需要的统计数据，向监管部门和领导层进行汇报。

1.支持按照银保监监管要求报送的数据模板、集团保险经纪公司要求报送的数据模板进行相关数据的导出

2.以上报表数据的导出支持时间等基础筛选条件筛选

1.4.9 非功能性需求

移动端适配

支持项目管理模块功能的移动端适配（需要评估是否支持外网访问）

再保项目数同步再保业务系统的再保单数据，以能够进行项目的管理、收据对接 入确认和结算，以及业务数据的报表统计

医责险项目对接医责险平台，同步医责险业务的保单数据，以能够进行项对接 目的管理、收入确认和结算，以及业务数据的报表统计

支持分支机支持为分支机构定制相关个性化管理需求，例如支持当地监管构版本开发机构的数据对接

和部署

根据合规要求，支持为分支机构部署专用版本

1.5 保险中介从业人员管理系统

1.6 企业客户服务系统

1.7 互联网保险业务平台

1.8 数据分析中心规划

在一期建设内容之上进行扩充和新增，使得系统形成以一期建设为框架和基础，以二期为完善和升级，以三期为全面建设和全面应用的三步走步调。

1.8.1 景区应用

1.8.1.1 电子购票

通过仙居已有购票系统，进行电子自助购票，运用系统对接的方式，获取购票数据相关数据，根据门票价格制定阶梯式兑换绿币，通过使用绿币、抵扣景区内文创产品，或兑换酒店优惠券等。

1.9 软硬件要求

1.9.1 景区应用

1.9.1.1 门票抵扣

在二期对接电子购票系统的基础上获取绿币，通过账户内绿币，并根据相应兑换折算方法，可用于门票费用的抵扣或兑换。

1.10 技术实现方案

1.10.1 系统接口总体设计

系统基于支撑平台开发建设，支撑平台的接口主要是平台提供的组件接口，主要包括：集成门户接口、工作流接口、数据交换接口、报表接口。

在总体设计时，会预留接口，以便将来可以实现统一部署的各相关应用系统的集成，包括界面集成、应用集成、数据集成、安全集成。

1.10.1.1 接口设计原则

1、松耦合、高内聚，接口间要有清晰的界限；

2、使用简单、快捷，通用性好，可靠性高；

3、充分考虑接口所涉及的各个系统的应用扩展情况，能灵活地支撑需求变化；

4、保证接口数据在接口所涉及的各个系统间的一致性；

5、接口数据能够自动导出和导入；

6、在数据交互过程中，应具有传送和接收后的确认过程。

1.10.1.2 接口设计方式

系统应提供统一的数据交换接口和应用服务接口，应采用XML作为统一的数据接口格式，使用中间件技术来封装所有的业务逻辑，服务接口应支持Web

Service技术。利用中间数据载体实现系统内部应用与外部应用之间的数据传输，采用目前业内广泛使用的XML或者Excel作为离线导入导出数据的中间数据载体。利用服务方式为其它系统提供数据服务，开发Web Service接口方式向其它系统提供数据交互的服务，信息化平台后续建设的其它功能扩展。

系统接口主要可以分为数据直接访问、Web Service、数据库同步几种方式实现，这几种方式不仅能支持现有应用的需求，而且还不会限制后续系统替换、升级、增加，并且易于向以后的先进技术实现迁移。

1.10.1.2.1 数据库直接访问接口设计实现

系统间交换数据，可采用数据库直接访问方式，这种方式实际上只需要在数据库中为相应应用授予读取或者写入的权限，使得对方应用可以直接读取或者写入应用数据库即可。

1.10.1.2.2 Web Service接口设计实现

系统应提供统一的数据交换接口和应用服务接口，服务调用接口采用Web

Service方式。Web Service的接口实现方式如下图所示。

接口提供方开发部署Web Service接口，此接口连接本系统的业务数据库，读取或者写入数据，并对外提供业务功能调用。

调用方根据接口提供方的接口定义，开发和部署Web Service接口调用程序，调用提供方发布的Web Service接口，获取或者发送业务数据，并读取或者写入本系统业务数据库。

1.10.1.2.3 数据库同步接口实现

应用系统之间交互也有采用数据库直接访问，直接同步数据的方式。这种方式可以保证数据的实时性，对接口提供方没有开发部署需求，相对较为简单。具体的实现方式如下图所示：

目标系统可以不开发和部署任何程序，只需要对调用系统开放数据库访问权限，具体权限根据不同系统的需求可以提供只读权限和写权限。

调用系统需要开发和部署数据同步调度程序，触发或者定时访问目标系统的业务数据库，将本系统的业务数据写入对方数据库，或者从对方数据库获取需要的业务数据写入本系统的业务数据库内。

1.11 项目实施方案

里程碑节点 里程碑说明

里程碑1.1 完成国家电投集团保险经纪有限公司数字化平台底层架构搭建运行、服务器网络拓扑配置

里程碑1.2 完成业务管理系统、企业客户户服务系统统保业务数据展示及报表查看

主要交付物及完成条件

（1）根据要求搭建的可运行的生产、测试环境

（2）基础微服务程序支持运行

（1）企业客户服务系统业绩统计报表及业务管理系统统计报表上线并通过验收

（2）实现集团公司保险数据可视化管理及驾驶舱展示

（3）旧业务管理系统历史统保业务（待指定范围）数据迁移至新业务管理系统

（1）集团企业单位可以登录客户端，输入本单位的相关地理位置数据，获得风险预警和灾害预警信息

（2）模型和预测结果由第三方风控预警系统提供

（1）业务管理系统基础功能通过验收并上线运行（符合银保监要求）

（1）企业客户服务系统集团内统保相关的业务功能通过验收并上线运行

完成时间

2021.11.30

里程碑1.3 企业客户服务系统客户端对接外部风控系统

里程碑2 完成业务管理系统基础功能开发上线

完成企业客户服务系统统保业务关联模块及功能开发和上线

2021.12.31

里程碑3

2022.1.30

里程碑4

里程碑4

完成业务管理系统、企业客户服务系统、数据分析中心、互联网保险业务管理平台、保险中介从业人员管理系统功能开发上线

所有系统全部上线验收并终验合格

（1）业管系统、企业客户服务系统、数据分析中心、互联网保险业务管理平台、保险中介从业人员管理系统功能通过验收并上线运行

系统验收证明

2022.3.15

2022.5.30

1.12 技术服务和质保计划