以风险管控为导向的业务数据分析方法与流程

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.图1为本公开实施例提供的一种以风险管控为导向的业务数据分析方法流程图；
30.图2为本公开实施例提供的业务问题类型划分与业务问题对应关系图；
31.图3为本公开实施例提供的存储空间存储的业务数据图；
32.图4为本公开实施例提供的另一种以风险管控为导向的业务数据分析方法流程图；
33.图5为本公开实施例提供的另一种以风险管控为导向的业务数据分析方法流程图；
34.图6为本公开实施例提供的业务问题数量与时间的对应关系的二维图形图；
35.图7为本公开实施例提供的整改过程信息图；
36.图8为本公开实施例提供的一种以风险管控为导向的业务数据分析装置的结构示意图；
37.图9为本公开实施例提供的一种电子设备的结构示意图。
具体实施方式
38.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
39.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
40.通常情况下，很多机构从制度出发解决屡查屡犯的现象，对员工进行培训，增加考核机制，最后导致对于屡查屡犯问题的管理收效甚微；或者部分机构可以记录存在的问题，但是并不能系统的对问题进行划分并统一管理，导致无法准确定位屡查屡犯问题。针对该问题，本公开实施例提供了一种以风险管控为导向的业务数据分析方法，下面结合具体的实施例对该方法进行介绍。
41.图1为本公开实施例提供的一种以风险管控为导向的业务数据分析方法流程图，该以风险管控为导向的业务数据分析方法可以由以风险管控为导向的业务数据分析装置执行，该装置可以采用硬件或者软件实现，并可集成在任意具有计算能力的电子设备上，例如终端，具体包括掌上电脑、平板电脑、带显示屏的可穿戴设备、台式机、笔记本电脑、一体机、智能家居设备等。图2为本公开实施例提供的业务问题类型划分与业务问题对应关系图，下面结合图2对图1所示的方法流程图进行介绍，该方法包括的具体步骤如下：
42.s101、获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则。
43.具体的，在本实施例中，以风险管控为导向，收集并整合需要关注的、并且可能存在屡查屡犯问题的业务问题，根据搜集到的问题，在同一体系下，对业务问题等进行分类。其中，同一体系是指将业务类型、业务问题类型、业务问题按照相同的业务线进行划分。
44.其中，业务类型是指对不同业务线进行划分，得到的不同的业务类型。示例性的，根据业务线，将业务类型划分为：授信业务、贷款业务、抵质押业务等。
45.业务问题类型是指可能存在屡查屡犯问题的业务问题，所对应的业务类型。示例性的，存在屡查屡犯问题的业务问题为：流向银行的贷款资金异常、处理贷款业务的相关人员非工作需要经常主动加班、私自调班，因为上述业务问题均与贷款业务线相关，因此，将该业务问题对应的业务类型归属到贷款业务。
46.可以理解的是，相关人员可以根据实际需要对业务问题类型划分不同层级。示例性的，可以根据实际需要对上述贷款业务进行二级划分，例如划分为贷款资金流动异常、相
关人员考勤异常；进一步的，可以对上述贷款资金流动异常进行三级划分，例如划分为贷款资金流向房地产异常及贷款资金流向银行异常；对相关人员考勤异常进行三级划分，例如划分为迟到早退及非工作需要经常主动加班、私自调班。可以理解的是，如果按照上述三级划分，上述流向银行的贷款资金异常这一业务问题，其对应的业务问题类型为贷款资金流向银行异常；处理贷款业务的相关人员非工作需要经常主动加班、私自调班这一业务问题，对应的业务问题类型为非工作需要经常主动加班、私自调班。上述业务问题类型与业务问题对应关系如图2所示。
47.其中，上述划分只是本公开实施例提供的一种划分示例，具体应用时可以根据不同的业务类型及问题类型进行不同层级的划分，本公开实施例对此不做限制。
48.在本实施例中，监测规则是指对不同的业务问题类型设置的不同的模型。
49.可选的，在对业务问题类型设置模型之前，首先需要建立业务问题类型对应的模型。示例性的，上述模型可以包括模型名称、模型规则、执行频率等信息。例如模型名称为：贷款资金流向银行异常。模型规则是：一天内贷款资金流向银行金额超过100万元。执行频率为每天执行一次。
50.又例如，模型名称为：处理贷款业务的相关人员非工作需要经常主动加班、私自调班。模型规则为：在一周内加班次数大于3次、调班次数大于2次、执行频率为每周执行一次。
51.可选的，获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则之前，需要预先配置业务类型与业务问题类型之间的第一对应关系以及业务问题类型与监测规则之间的第二对应关系；相应地，基于所述第一对应关系和所述第二对应关系，获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则。
52.s102、获取所述业务类型下累积的业务数据。
53.具体的，在本实施例中，现有的业务数据可以是之前办理的业务的相关数据或者是记录的操作日志或者是其他金融机构提供的数据等其他方式。
54.具体的，获取问题业务数据之前，需要将业务数据存储到存储区域中。可选的，针对不同业务类型，可以将不同业务类型下的业务数据存储到不同的存储区域；相应地，从业务类型对应的存储区域中获取所述业务类型下累积的业务数据。示例性的，存储区域存储的业务数据信息如图3所示。
55.进一步的，在本公开实施例中，还可以通过建立失步映象区对象来描述对应存储区域中数据的变化信息，仅用较小的空间来记录变化，避免了开辟缓冲区来直接存储变化记录时的如何开辟缓冲区大小的难题，同时在这种机制下用较小的空间可以存储所有变化信息，避免了因数据同步导致数据丢失的问题。
56.示例性的，针对上述贷款资金流向银行异常的这一类型的业务问题，可以通过查询保存在存储区域中的办理相关业务的记录及交易流水信息，获取到业务数据；针对相关人员非工作需要经常主动加班，私自调班的这一类型的业务问题，可以通过查询保存在存储区域中的员工的考勤数据，获取到业务数据。
57.s103、响应于触发问题定位操作，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到至少一个业务问题。可选的，在本实施例中，响应于触发问题定位操作，包括响应于触发问题定位控件的操作和/或响应于定时器定时触发问题定位的
操作；其中，所述问题定位控件为问题定位页面中显示的控件，所述定时器为配置页面配置的定时器。
58.当触发问题定位操作采用定位控件的方式触发时包括：终端用户根据自身需求，单击问题定位页面中显示的问题定位按钮触发问题定位操作；当触发问题定位操作通过定时器定时触发问题定位操作时包括：在配置页面配置定时器执行的频率，设置间隔固定时间或者到达指定时间触发问题定位操作。示例性的，设置间隔固定时间触发问题定位操作可以是固定时间可以是每6小时、每天、每周等；到达指定时间可以是每天晚上12:00、或者是每周一12：00等，本公开实施例对定时器的执行频率不做限定。
59.可以理解的是，上述触发问题定位操作的两种方式可以使用一种方式触发，也可以使用两种方式交替触发，或者是使用其他方式触发，本公开实施例对此不做限定。
60.触发问题定位操作后，利用模型探索技术，对业务数据进行监测，利用设定的监测规则与现有业务数据匹配，确定业务数据是否存在问题。当获取到的业务数据满足设定的监测规则后，得到业务问题。示例性的，通过查询保存在存储区域中的贷款资金流水信息，当一天内，贷款资金流向银行的流水的和大于上述设置的100万时，会生成流向银行的贷款资金异常的业务问题，可理解的是，上述生成的流向银行的贷款资金异常业务问题所对应的业务问题类型为贷款资金流向银行异常；通过查询保存的考勤数据，如果获取到一周内员工加班次数大于3次、调班次数大于2次，会生成处理贷款业务的相关人员非工作需要经常主动加班、私自调班的业务问题，可以理解的是上述生成的处理贷款业务的相关人员非工作需要经常主动加班、私自调班的业务问题所对应的业务问题类型为非工作需要经常主动加班、私自调班。可以理解的是，因为不同的业务问题类型对应不同的监测规则，当触发问题定位操作时，根据监测规则，获取到业务问题后，可以将获取到的业务问题归属到该监测规则对应的业务问题类型下，当再次触发问题定位操作，根据相同的监测规则，获取到相同的业务问题后，可以将获取到的相同的业务问题归属到相同的业务问题类型下。
61.可选的，在本实施例中基于每个业务问题类型对应的监测规则，对业务数据进行监测，得到的业务问题为疑似问题。对于疑似问题，需要相关人员进行确认该问题是否真实存在。示例性的，针对上述流向银行的贷款资金异常的业务问题，相关人员可以对每笔交易进行调查，确定每笔交易是否真实存在；对于处理贷款业务的相关人员非工作需要经常主动加班、私自调班这一业务问题，可以找相关人员进行沟通，确定问题是否真实存在。对于人员确认的问题为实际存在的问题，可以进行后续的统计或者整改等操作。
62.本公开实施例通过获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则；获取所述业务类型下累积的业务数据；响应于触发问题定位操作，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到至少一个业务问题，从而可以将业务问题归属到业务问题类型中，因此当再次出现相同业务问题时，可以在同一业务问题类型下对相同的业务问题进行监控，保证了业务问题归属的统一性，进而可以确定业务问题是否存在屡查屡犯问题。
63.图4为本公开实施例的另一种以风险管控为导向的业务数据分析方法，该方法包括如下几个步骤：
64.s401、获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则。
65.在本实施例中，该步骤与s103相同，本实施例在此不再赘述。
66.s402、获取所述业务类型下累积的业务数据。
67.在本实施例中，该步骤与s103相同，本实施例在此不再赘述。
68.s403、响应于触发问题定位操作，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到至少一个业务问题。
69.在本实施例中，该步骤与s103相同，本实施例在此不再赘述。
70.s404、获取录入的业务问题，基于录入的业务问题及所述得到的至少一个业务问题，得到业务问题出现次数。
71.具体的，在本实施例中，获取业务问题的可以采用现场检查的方式获取。
72.其中，现场检查包括，相关人员对于可能存在屡查屡犯问题的业务问题，到工作现场进行问题排查，排查后对于确认存在的业务问题录入到终端。示例性的，相关人员通过现场排查，确认存在流向银行的贷款资金异常、处理贷款业务的相关人员非工作需要经常主动加班、私自调班的业务问题，相关人员将上述业务问题录入到终端设备。
73.其中，在将上述确认的问题录入到终端时，需要选择业务问题所对应的业务问题类型；示例性的，上述由相关人员现场确认的业务问题，分别选择对应的业务问题类型为贷款资金流向银行异常、非工作需要经常主动加班、私自调班。录入完成后，终端记录并保存上述存在的问题。可选的，相关人员会对上述存在的业务问题持续关注，只要上述问题出现一次，就会录入到系统，再次出现会再次录入到系统。因此，相关人员可以通过该业务问题出现的次数，确定该业务问题是否存在屡查屡犯问题。
74.可以理解的是，本公开实施例可以通过现场检查将确定的业务问题录入到系统中，也可以采用s102中通过非现场检查方式获取到业务手数据，通过响应于触发问题定位操作，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到业务问题。因此，该业务问题出现的次数，包括录入到系统中的次数及通过s103得到的业务问题出现的次数，本公开实施例对得到业务问题的两种方式的顺序不做限定。
75.可选的，在一些其他实施例中，还可以只根据录入到系统中业务问题出现的次数确定该业务问题是否存在屡查屡犯问题。
76.本公开实施例通过获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则；获取所述业务类型下累积的业务数据；响应于触发问题定位操作，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到至少一个业务问题获取业务问题；获取录入的业务问题，基于录入的业务问题和/或所述得到的至少一个业务问题，得到业务问题出现次数，使得即可以通过监测规则对业务数据进行监测得到业务问题，也可以通过相关人员录入得到业务问题，根据该业务问题出现的次数，确定该业务问题是否存在屡查屡犯问题。
77.图5为本公开实施例提供的另一种问题定位流程图，该流程图包括以下几个步骤：
78.s501、获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则。
79.该步骤与s101步骤相同，本公开实施例不再赘述。
80.s502、获取所述业务类型下累积的业务数据。
81.该步骤与s102步骤相同，本公开实施例不再赘述。
82.s503、响应于触发问题定位操作，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到至少一个业务问题。
83.该步骤与s103步骤相同，本公开实施例不再赘述。
84.s504、基于所述至少一个业务问题，确定预设时间内每个业务问题类型下的业务问题数量；针对任一业务问题类型，建立业务问题数量与时间的对应关系；基于业务问题数量与时间的对应关系，得到业务问题的变化趋势。
85.具体的，在本实施例中，预设时间内为自定义设置的，需要统计业务问题数量的时间。可选的，上述统计业务问题数量可以通过定时器定时触发，也可以通过点击统计按钮触发。示例性的，预设时间为一周、一个月等。
86.因为不同的业务问题类型对应不同的监测规则，当触发问题定位操作时，根据监测规则，获取到业务问题后，可以将获取到的业务问题归属到该监测规则对应的业务问题类型下，当再次触发问题定位操作，根据相同的监测规则，获取到相同的业务问题后，可以将获取到的相同的业务问题归属到相同的业务问题类型下。因此，可以统计得到预设时间内每个业务问题类型下业务问题数量，并建立业务问题数量与时间的关系。其中，时间可以是指统计业务问题数量的时间。
87.示例性的，根据s101中描述的模型名称为：贷款资金流向银行异常的模型，该模型执行频率为每天，因此每天会触发问题定位操作，判断是否存在流向银行的贷款资金异常的业务问题。预设时间为每月1号统计该业务问题出现的次数，因此每月一号可以得到上一个月时间内该业务问题数量，例如2020年2月1日统计得到2020年1月该业务问题数量为5次，2020年3月1日统计得到2020年2月该业务问题数量为10次，建立2020年2月1日与5次、2020年3月1日与10次的对应关系。可以理解的，根据上述对应关系，可以判断该业务问题的变化趋势。
88.s505、针对问题数量超过数量阈值的业务问题类型，进行整改提醒。
89.具体的，在本公开实施例中，会对各个业务问题类型设置预警阈值，示例性的，针对贷款资金流向银行异常的业务问题类型设置阈值为[0-5]，[6-10]，[10-20]。其中，上述预警阈值为区间，不同区间值代表了不同的严重程度，例如一个月内出现流向银行的贷款资金异常这一业务问题的次数为[0-5]次代表是可以容忍的程度，一个月内出现出现流向银行的贷款资金异常这一业务问题的次数为[6-10]次代表是需要关注的程度，一个月内出现流向银行的贷款资金异常这一业务问题的次数为[10-20]次代表问题比较严重的程度。
[0090]
可选的，上述不同区间值可以采用不同的颜色显示，其中，不同的颜色显示可以用于提示相关人员进行整改。示例性的，用绿色代表可以容忍的程度，黄色代表需要关注的程度，红色代表严重的程度，当业务问题数量达到红色区域，提醒相关人员需要对问题进行整改。其中，对业务问题进行整改采用相关人员线下进行整改的方式进行。
[0091]
s506、在所述整改提醒后，记录每次整改后所述业务问题类型对应的业务问题数量，并记录整改后所述业务问题数量与时间的对应关系；基于整改后所述至少一个业务问题数量与时间的对应关系，定位所述业务问题是否存在屡查屡犯。
[0092]
具体的，在整改提醒后，相关人员进行线下整改，在整改过程中及整改完成后，采用s501-s504描述的方法，可以得到整改过程中及整改完成后业务问题与时间的对应关系。在本实施例中，对于整改完成的业务问题，如果该业务问题数量再次增加，代表该业务问题
存在屡查屡犯的现象，进一步的说明对于该业务问题的整改效果不理想。其中，整改完成包括业务问题数量为0或者是业务问题数量达到可容忍区间，本公开实施例对整改完成标准不做限定。
[0093]
s507、响应于触发问题定位显示的操作，将记录后的业务问题数量与时间的对应关系进行二维图形展示。
[0094]
具体的，将s504和/或s506中的对应关系用如图6所示的二维图形进行展示。其中，上述二维图形展示了整改前，整改中，整改后的业务问题发生的数量。
[0095]
可选的，在本公开实施例中，还可以展示如图7所示的整改过程信息图，用于记录整改相关信息，例如记录业务问题、业务问题类型、整改时间等信息。
[0096]
本公开实施例通过获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则；获取所述业务类型下累积的业务数据；响应于触发问题定位操作，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到至少一个业务问题；基于所述至少一个业务问题，确定每个业务问题类型下的业务问题数量；针对问题数量超过数量阈值的业务问题类型，进行整改提醒；在所述整改提醒后，记录每次整改后所述业务问题类型对应的业务问题数量，并记录问题数量与时间的对应关系；响应于触发问题定位显示的操作，将记录后的问题数量与时间的对应关系进行二维图形展示，使得可以通过二维图形的方式展示业务问题数量及对业务问题进行整改的效果，方便相关人员进一步确定业务问题是否存在屡查屡犯问题。
[0097]
图8为本公开实施例提供的以风险管控为导向的业务数据分析装置的结构示意图。该以风险管控为导向的业务数据分析装置可以是如上实施例所述终端设备，或者该以风险管控为导向的业务数据分析装置可以是如上所述终端设备部件或组件。本公开实施例提供的以风险管控为导向的业务数据分析装置可以执行以风险管控为导向的业务数据分析方法实施例提供的处理流程，如图8所示，以风险管控为导向的业务数据分析装置80包括：
[0098]
第一获取模块81，用于获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则；
[0099]
第二获取模块82，用于获取所述业务类型下累积的业务数据。
[0100]
响应模块83，用于响应触发问题定位操作。
[0101]
监测模块84，基于每个所述业务问题类型对应的监测规则，对所述业务数据进行监测，得到至少一个业务问题。
[0102]
可选的，响应模块83，用于响应触发问题定位操作时，具体用于：响应于触发问题定位控件的操作和/或响应于定时器定时触发问题定位的操作；其中，所述问题定位控件为问题定位页面中显示的控件，所述定时器为配置页面配置的定时器。
[0103]
可选的，以风险管控为导向的业务数据分析装置还包括配置模块85，用于预先配置业务类型与业务问题类型之间的第一对应关系以及业务问题类型与监测规则之间的第二对应关系；相应地，基于所述第一对应关系和所述第二对应关系，获取业务类型对应的至少一个业务问题类型和每个所述业务问题类型对应的监测规则。
[0104]
可选的，以风险管控为导向的业务数据分析装置还包括第三获取模块86，用于获取录入的业务问题，基于录入的业务问题及所述得到的至少一个业务问题，得到业务问题
出现次数。
[0105]
可选的，以风险管控为导向的业务数据分析装置还包括确定模块87、建立模块88；其中，确定模块87用于基于所述至少一个业务问题，确定预设时间内每个业务问题类型下的业务问题数量；针对任一业务问题类型，建立业务问题数量与时间的对应关系；基于所述业务问题数量与时间的对应关系，得到业务问题的变化趋势。
[0106]
可选的，确定模块87还包括提醒单元89、记录单元810；其中，提醒单元89用于针对业务问题数量超过数量阈值的业务问题类型，进行整改提醒；在所述整改提醒后，记录每次整改后所述业务问题类型对应的业务问题数量，并记录整改后所述业务问题数量与时间的对应关系；基于整改后所述业务问题数量与时间的对应关系，确定所述业务问题是否存在屡查屡犯问题。
[0107]
可选的，建立模块88还包括展示单元811，用于建立模块88建立业务问题数量与时间的对应关系后，响应于触发问题定位显示的操作，将记录后的业务问题数量与时间的对应关系进行二维图形展示。
[0108]
图8所示实施例的以风险管控为导向的业务数据分析装置可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
[0109]
图9为本公开实施例提供的电子设备的结构示意图。该电子设备可以是如上实施例所述的终端。本公开实施例提供的电子设备可以执行以风险管控为导向的业务数据分析方法实施例提供的处理流程，如图9所示，电子设备90包括：存储器91、处理器92、计算机程序和通讯接口93；其中，计算机程序存储在存储器91中，并被配置为由处理器92执行如上所述的以风险管控为导向的业务数据分析方法。
[0110]
另外，本公开实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的以风险管控为导向的业务数据分析方法。
[0111]
此外，本公开实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机程序或指令，该计算机程序或指令被处理器执行时实现如上所述的以风险管控为导向的业务数据分析方法。
[0112]
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0113]
以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。