CN117436691A - 一种业务管理方法、系统及相关设备 - Google Patents

Abstract

本申请提供了一种业务管理方法、系统及相关设备，该方法可以向不同角色的用户提供不同类型的看板页面，满足财经管理中不同用户角色的使用需求，同时每种看板页面包括风险分析区域和任务处理区域，风险分析区域用于向用户展示用于描述异常数据的风险分析情况的分析指标，任务处理区域用于向用户展示用于描述风险任务的处理进展的处理指标，使得看板页面不仅显示有对异常数据的风险分析的实时进展，还显示任务处理的实时进展，使得企业财经可以更加及时、高效的进行业务管理。

Description

一种业务管理方法、系统及相关设备

技术领域

本申请涉及计算机领域，尤其涉及一种业务管理方法、系统及相关设备。

背景技术

企业财经是确保企业财务健康和可持续增长的关键要素，包括财务管理、投资决策、风险管理等。企业财经是一个高度复杂和不断变化的领域，经济变化、政策法规、市场情绪等多个因素均会对企业财经产生影响，因此企业员工需要周期性(比如每周、每月或者每季度)根据企业的财经数据制作各种汇报材料，给各个领域的管理者们进行汇报，使得管理者们能够及时了解财务状况，作出风险管理决策。

但是，对于大型公司，其规模和复杂性使得企业的财经数据变得更加复杂，汇报材料制作门槛高、效率低，管理者们很难从海量数据中获取有效信息，无法及时获知风险管理的进度，出现风险管理延迟，很容易导致企业出现法律合规问题。因此，企业财经领域如何及时、高效的进行风险管理，是一个亟待解决的问题。

发明内容

本申请提供了一种业务管理方法、系统及相关设备，能够及时、高效的进行企风险管理，避免企业出现风险管理延迟的问题。

第一方面，提供了一种业务管理方法，该方法包括以下步骤：接收第一用户发起的看板获取请求，获取第一用户对应的看板页面，其中，看板页面包括风险分析区域以及任务处理区域，风险分析区域包括分析指标，分析指标用于描述分析任务的处理情况，分析指标是根据分析任务的分析状态生成的，分析任务包括对异常数据进行风险分析，任务处理区域包括处理指标，处理指标用于描述风险任务的处理情况，处理指标是根据风险任务的处理状态生成的，风险任务是业务管理系统根据分析任务的分析结果生成的，向第一用户发送第一用户对应的看板页面。

实施第一方面描述的方法，向用户展示的页面不仅显示有对异常数据的风险分析的情况，还显示风险任务处理的情况，并且该风险分析情况和风险处理情况是根据分析状态和处理状态确定的，也就是实时的处理情况，这样风险管理不再依赖于定时的人工汇报，使得风险管理能够更加全面和及时，同时通过分区显示分析指标和处理指标，使得看板页面重点突出，复杂的指标也易于理解和解读，提高用户的数据洞察力和决策效果，因此，通过本申请提供的业务管理方法，企业财经可以更加及时、高效的进行风险管理。

在一可能的实现方式中，向第一用户发送第一用户对应的看板页面之后，该方法还包括以下步骤：业务管理系统接收第一用户发起的第一任务的处理请求，处理请求是第一用户点击看板页面触发的，第一任务是分析任务或者风险任务，业务管理系统向第一用户发送第一任务，接收第一用户反馈的处理结果，业务管理系统更新看板页面中的分析指标或者处理指标。

上述实现方式，用户接收到看板页面之后，可以根据看板页面中显示的指标，选择自己需要处理的分析任务或者风险任务，提交分析任务或者风险任务的处理结果之后，业务管理系统可以实时更新分析状态或者处理状态，实时更新分析指标和处理指标，每个用户对分析任务和风险任务进行处理后，其他用户都可以及时获知处理进度，实时更新每个用户对应的看板页面，使得每个用户都可以及时获知风险分析进度和风险处理进度，避免风险延迟带来的财务危机。

在一可能的实现方式中，业务管理系统包括状态数据库，状态数据库包括多个分析任务的分析状态和多个风险任务的处理状态，获取第一用户对应的看板页面时，业务管理系统可以从状态数据库中获取每个分析状态下的分析任务数量，确定分析指标，其中，分析指标包括不同分析状态的分析任务数量，分析状态包括待分析、分析中和已分析，然后从状态数据库中获取每个处理状态下的风险任务数量，确定处理指标，其中，处理指标包括不同处理状态的风险任务数量，处理状态包括待处理、处理中和已处理，最后基于分析指标和处理指标生成看板页面。

上述实现方式，向用户显示的看板页面是根据分析任务的分析状态以及风险任务的处理状态确定的，该分析状态和处理状态会实时在状态数据库中更新，所以看板页面所显示的指标也是实时的指标，使得每个用户都可以及时获知风险分析进度和风险处理进度，避免风险延迟带来的财务危机。

在一可能的实现方式中，该方法还包括以下步骤：业务管理系统接收第二用户发起的看板获取请求，第二用户的用户角色与第一用户的用户角色不同，获取第二用户对应的看板页面，其中，第一用户对应的看板页面中显示的分析指标和处理指标所属的范围与第二用户对应的看板页面中显示的分析指标和处理指标所属的范围不同，范围包括时间范围和区域范围，第一用户对应的看板页面中的分析指标种类与第二用户对应的看板页面中的分析指标种类不同，向第二用户发送第二用户对应的看板页面。

上述实现方式，业务管理系统可以存储有不同用户角色对应的看板页面，不同用户角色对应的看板页面所显示的内容存在差异，不仅是指标种类的差异，而且指标对应的时间范围或者区域范围也不一样，这是因为管理层员工更希望看到整体性的指标，而一线员工更希望看到细节性的指标，业务管理系统基于用户角色配置每个用户的看板页面，可以一定程度满足每个用户角色的业务需求，使得企业内不同级别的员工都可以通过业务管理系统获取到自己所需的指标，有助于全面了解和评估企业风险情况，使得企业财经可以实现及时、高效的风险管理。

在一可能的实现方式中，业务管理系统接收第一用户发起的看板获取请求之前，该方法还包括以下步骤：业务管理系统接收第三用户发送的配置信息，配置信息包括指标配置信息、外观配置信息以及用户角色信息，指标配置信息包括用户需求在风险分析区域以及任务处理区域显示的指标，外观配置信息用于描述看板页面的视觉设计效果，外观配置信息包括看板页面的布局信息和交互逻辑信息，根据配置信息生成元数据信息，元数据信息用于描述用户请求配置的看板页面，根据元数据信息获得页面的低代码配置，低代码配置是基于低代码开发平台提供的配置选项生成的，基于低代码开发平台生成低代码配置对应的看板页面，记录看板页面对应的用户角色。

需要说明的，上述第一用户和第二用户指的是获取看板页面的不同角色的用户，第三用户是配置看板页面的用户，第一用户和第三用户可以是同一个用户，第二用户和第三用户也可以是同一个用户，第一用户、第二用户以及第三用户也可以是三个不同的用户，本申请不作具体限定。

上述实现方式，用户配置看板页面时，通过对用户提交的配置信息进行多层抽象，先生成配置信息对应的统一格式的元数据信息，然后根据元数据信息获得页面的低代码配置，最后基于低代码平台和低代码配置生成看板页面，这样对用户输入的配置信息进行多次抽象和归纳，使得看板页面可以被用户灵活配置，将用户需求与底层设计实现解耦，用户的需求的变更和扩展可以更加简化，系统拥有更好的可扩展性和维护性，可以适应更广泛的应用场景。

在一可能的实现方式中，分析指标还包括分析任务的分析结果，分析结果包括风险等级、风险类型、风险原因、风险影响、风险负责人中的一种或者多种。

上述实现方式，看板页面不仅显示每个分析状态下的分析任务数量，使得用户可以及时获知分析任务的处理进度，而且可以显示分析结果对应的分析任务数量，比如风险等级为1级的分析任务数量，风险原因为操作错误的分析任务数量等，使得用户可以及时获知分析任务的总体情况，及时作出决策，避免风险延迟产生的财务危机问题。

在一可能的实现方式中，该方法还包括以下步骤：业务管理系统获取第一异常数据，将第一异常数据对应的第一分析任务的分析状态修改为待分析，向分析用户发送第一异常数据，将第一分析任务的分析状态修改为分析中，接收分析用户反馈的分析结果，将第一分析任务的分析状态修改为已分析。

上述实现方式，业务管理系统可以根据分析任务的处理情况实时更新分析状态，这样用户获取看板页面时，向用户反馈的看板页面上的指标是根据实时的分析状态和处理状态生成的，用户可以及时获知风险分析和风险处理的情况，企业财经可以更加及时、高效的进行风险管理。

在一可能的实现方式中，该分析状态还包括待复核，接收分析用户反馈的分析结果，将第一分析任务的分析状态修改为已分析之后，该方法还包括以下步骤：业务管理系统将分析结果发送给复核用户，将第一分析任务的分析状态修改为待复核，接收复核用户反馈的复核结果，在复核结果为同意的情况下将第一分析任务的分析状态修改为已复核，在复核结果为不同意的情况下将第一分析任务的分析状态修改为待分析。

上述实现方式，对异常数据进行风险分析时，额外通过复核用户确保风险分析的准确性，复核用户反馈的复核结果为不同意时需要对异常数据进行重新分析，复核结果为同意时才会进入下一步的处理，避免由于分析用户的错误分析结果导致财务风险问题的出现。

在一可能的实现方式中，分析结果包括存在风险和不存在风险，风险任务是根据分析状态为已复核且分析结果为存在风险的分析任务生成的。

上述实现方式，每个分析任务一旦通过复核且分析结果为存在分析，即可自动生成风险任务，发送给对应的用户进行处理，本申请通过根据分析状态和分析结果来实时获取满足条件的异常数据来生成风险任务，可以使得风险任务能够及时生成，及时发送给对应的用户进行处理，从而避免风险延迟，企业财经可以更加及时、高效的进行风险管理。

可选地，该方法还包括以下步骤：业务管理系统接收分析用户反馈的处理计划，风险任务是根据分析状态为已复核、分析结果为不存在风险且包括处理计划的分析任务生成的。

应理解，部分异常数据可能并不会带来风险，但是仍然需要员工制定任务计划来改进业务方针。举例来说，假设一个电商公司每月的订单量通常在稳定的范围内波动，但某个月份订单量突然异常低，导致销售额大幅下降。分析用户对该异常数据进行风险分析后发现，这个低订单量是某个节假日导致的，此时订单量异常不会直接为企业带来风险，但是员工可以对此制定处理计划，比如优化该节假日期间的供货计划和库存管理，以确保能够满足消费者的需求，并提供良好的购物体验，或者基于该节假日定制特别的促销活动、优化广告投放和加强市场宣传等，以提高订单量。简单来说，对于不存在风险的异常数据，员工也可以根据异常数据来发现潜在的改进方针，优化产品和服务，因此对于分析状态为已复核、分析结果为不存在风险且包括处理计划的分析任务也需要生成风险任务进行处理。

在一可能的实现方式中，状态数据库还用于记录风险任务的处理状态，该方法还包括以下步骤：业务管理系统获取第一处理任务，将第一处理任务的处理状态修改为待处理，向处理用户发送第一处理任务，将第一处理任务的处理状态修改为处理中，接收并记录处理用户发送的任务反馈，接收处理用户发送的任务关闭请求，将第一处理任务的处理状态修改为已处理。

上述实现方式，根据每个处理任务的处理状态实时更新状态数据库，这样用户获取看板页面时，向用户反馈的看板页面上的指标是根据实时的处理状态生成的，用户可以及时获知风险处理的情况，企业财经可以更加及时、高效的进行风险管理。

在一可能的实现方式中，业务管理系统可以根据分析状态和分析结果，从多个异常数据中获取至少一个风险任务数据，然后根据至少一个风险任务数据生成一个或者多个风险任务。其中，风险任务数据包括分析状态为已复核，分析结论为存在风险的异常数据，还包括分析状态为已复核，分析结论为不存在风险但包括分析计划的异常数据。

进一步地，N个风险任务数据可以生成M个风险任务，其中，N不等于M，应理解，在风险分析中，一些异常数据之间存在相关性，所以这些异常数据的解决方案也是相似的，为了提高任务处理效率，可以将这些存在相关性的异常数据合并到一个风险任务进行处理。业务管理系统可以在获取到至少一个风险任务数据以后，根据风险任务数据的分析结果，将至少一个风险任务数据进行聚类，同一个类别的风险任务数据可以合并生成同一个风险任务。在聚类时，可结合分析结果中风险等级、风险类型、风险原因、风险影响、风险负责人等指标对风险任务数据进行聚类，比如将风险原因相似的风险任务数据进行合并生成一个风险任务，或者将处理计划相似的风险任务数据进行合并，或者将风险原因和处理计划均相似的风险任务数据进行合并生成一个风险任务，或者将风险负责人相同的风险任务数据进行合并生成一个风险任务，上述举例用于说明，本申请不作具体限定。

上述实现方式，通过将至少一个风险任务数据进行聚类，将同一个类别的风险任务数据合并生成一个风险任务，从而避免任务冗余，减少待处理的风险任务数量，降低系统处理压力和存储压力，提高用户的使用体验。

第二方面，提供了一种业务管理系统，该系统包括：看板获取单元，用于接收第一用户发起的看板获取请求，角色识别单元，用于获取第一用户对应的看板页面，其中，看板页面包括风险分析区域以及任务处理区域，风险分析区域包括分析指标，分析指标用于描述分析任务的处理情况，分析指标是根据分析任务的分析状态生成的，分析任务包括对异常数据进行风险分析，任务处理区域包括处理指标，处理指标用于描述风险任务的处理情况，处理指标是根据风险任务的处理状态生成的，风险任务是业务管理系统根据分析任务的分析结果生成的，看板发送单元，用于向第一用户发送第一用户对应的看板页面。

实施第二方面描述的系统，该业务管理系统可以向用户展示的页面不仅显示有对异常数据的风险分析的情况，还显示任务处理的情况，并且该风险分析情况和风险处理情况是根据分析状态和处理状态确定的，也就是实时的处理情况，这样风险管理不再依赖于定时的人工汇报，使得风险管理能够更加全面和及时，同时通过分区显示分析指标和处理指标，使得看板页面重点突出，复杂的指标也易于理解和解读，提高用户的数据洞察力和决策效果，使用该业务管理系统可以更加及时、高效的进行风险管理。

在一可能的实现方式中，系统还包括同步单元，看板获取单元还用于，接收第一用户发起的第一任务的处理请求，处理请求是第一用户点击看板页面触发的，第一任务是分析任务或者风险任务，看板发送单元还用于，向第一用户发送第一任务，接收第一用户反馈的处理结果，同步单元用于更新看板页面中的分析指标或者处理指标。

在一可能的实现方式中，业务管理系统包括状态数据库，状态数据库包括多个分析任务的分析状态和多个风险任务的处理状态，角色识别单元，用于从状态数据库中获取每个分析状态下的分析任务数量，确定分析指标，其中，分析指标包括不同分析状态的异常数据数量，分析状态包括待分析、分析中和已分析，角色识别单元，用于从状态数据库中获取每个处理状态下的风险任务数量，确定处理指标，其中，处理指标包括不同处理状态的风险任务数量，处理状态包括待处理、处理中和已处理，角色识别单元，用于基于分析指标和处理指标生成看板页面。

在一可能的实现方式中，看板获取单元，还用于接收第二用户发起的看板获取请求，第二用户的用户角色与第一用户的用户角色不同，角色识别单元，还用于获取第二用户对应的看板页面，其中，第一用户对应的看板页面中显示的分析指标和处理指标所属的范围与第二看板页面中显示的分析指标和处理指标所属的范围不同，范围包括时间范围和区域范围，第一用户对应的看板页面中的分析指标种类与第二用户对应的看板页面中的分析指标种类不同，看板发送单元，用于向第二用户发送第二用户对应的看板页面。

在一可能的实现方式中，系统包括配置单元，配置单元，用于接收第三用户发送的配置信息，配置信息包括指标配置信息、外观配置信息以及用户角色信息，指标配置信息包括用户需求在风险分析区域以及任务处理区域显示的指标，外观配置信息用于描述看板页面的视觉设计效果，外观配置信息包括看板页面的布局信息和交互逻辑信息，配置单元，用于根据配置信息生成元数据信息，元数据信息用于描述用户请求配置的看板页面，配置单元，用于根据元数据信息获得页面的低代码配置，低代码配置是基于低代码开发平台提供的配置选项生成的，配置单元，用于基于低代码开发平台生成低代码配置对应的看板页面，记录看板页面对应的用户角色。

在一可能的实现方式中，分析指标还包括异常数据的分析结果，分析结果包括风险等级、风险类型、风险原因、风险影响、风险负责人中的一种或者多种。

在一可能的实现方式中，系统包括数据获取单元和风险分析单元，数据获取单元用于获取第一异常数据，风险分析单元用于将第一异常数据的分析状态修改为待分析，风险分析单元用于向分析用户发送第一异常数据，将第一异常数据的分析状态修改为分析中，风险分析单元用于接收分析用户反馈的分析结果，将第一异常数据的分析状态修改为已分析。

在一可能的实现方式中，分析状态还包括待复核，风险分析单元还用于将分析结果发送给复核用户，将第一分析任务的分析状态修改为待复核，风险分析单元还用于接收复核用户反馈的复核结果，在复核结果为同意的情况下将第一分析任务的分析状态修改为已复核，在复核结果为不同意的情况下将第一分析任务的分析状态修改为待分析。

在一可能的实现方式中，分析结果包括存在风险和不存在风险，风险任务是根据分析状态为已复核且分析结果为存在风险的分析任务生成的。

在一可能的实现方式中，风险分析单元还用于接收分析用户反馈的处理计划，风险任务是根据分析状态为已复核、分析结果为不存在风险且包括处理计划的分析任务生成的。

在一可能的实现方式中，系统还包括任务处理单元，任务处理单元用于获取第一处理任务，将第一处理任务的处理状态修改为待处理，任务处理单元用于向处理用户发送第一处理任务，将第一处理任务的处理状态修改为处理中，任务处理单元用于接收并记录处理用户发送的任务反馈，任务处理单元用于接收处理用户发送的任务关闭请求，将第一处理任务的处理状态修改为已处理。

第三方面，提供了一种计算设备，计算设备包括处理器和存储器，存储器用于存储指令，处理器用于执行指令，以使得计算设备实现如第一方面描述的方法。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，指令被计算设备或者计算设备集群运行时实现如第一方面描述的方法。

第五方面，提供了一种计算设备集群，该计算设备集群包括至少一个计算设备，至少一个计算设备中的每个计算设备包括处理器和存储器，至少一个计算设备的处理器用于执行至少一个计算设备的存储器中存储的指令，以使得计算设备集群实现如第一方面描述的方法。

第六方面，提供了一种包含指令的计算机程序产品，计算机程序产品包括指令，该指令能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品，当计算机程序产品在计算设备或者计算设备集群上运行时，使得计算设备或者计算设备集群执行第一方面描述的方法。

附图说明

图1是本申请提供的一种业务管理系统的架构图；

图2是本申请提供的一种业务管理方法；

图3是本申请提供的第一看板页面的示例图；

图4是本申请提供的第二看板页面的示例图；

图5是本申请提供的一种业务管理方法中的指标管理方法的步骤流程示意图；

图6是本申请提供的一种应用场景下的风险任务生成方法的步骤流程示意图；

图7是本申请提供的业务管理方法中分析用户使用的一种界面示意图；

图8是本申请提供的业务管理方法中分析用户使用的另一种界面示意图；

图9是本申请提供的一种计算设备的结构示意图。

具体实施方式

首先，对本申请涉及的应用场景进行解释说明。

企业财经是确保企业财务健康和可持续增长的关键要素，包括财务管理、投资决策、风险管理等。企业财经是一个高度复杂和不断变化的领域，经济变化、政策法规、市场情绪等多个因素均会对企业财经产生影响，因此企业员工需要周期性(比如每周、每月或者每季度)根据企业的财经数据制作各种汇报材料，给各个领域的管理者们进行汇报，使得管理者们能够及时了解财务状况，并作出风险管理。

举例来说，全球关联交易指的是企业涉及多个国家或地区的商业交易，具体可以是跨国公司内部不同国家或地区的子公司之间进行的交易，也可以是不同国家或地区的独立公司之间进行的交易，交易内容可包括商品、服务、技术、资本等。全球关联交易涉及多个国家或地区的法律、税收政策、货币汇率、商业文化等因素，因此参与全球关联交易的企业需要谨慎规划，以确保遵守各国的相关法律法规，并最大程度减少法律风险。上述举例用于说明，除上述全球关联交易领域之外，企业财经需要频繁进行汇报的领域还有很多，这里不一一举例说明。

但是，对于大型公司，其规模和复杂性使得企业的财经数据变得更加复杂，汇报材料制作效率低，管理者们很难从海量数据中获取有效信息，很容易导致风险延迟，仍以上述全球关联交易为例，为了谨慎规划全球关联交易，企业员工需要周期性(比如每周、每月或者每季度)根据全球关联交易数据制作汇报材料，给不同的管理者进行汇报，人工汇报频繁且效率低。而且不同的交易可能涉及不同的国家和地区，制作汇报材料的企业员工以及管理者需要对各个国家和地区的法律、税收政策、货币汇率、商业文化非常了解，否则很难从海量的数据中获取有效信息，很容易导致风险延迟，同时，通过人工周期性汇报的方式，管理者们也无法及时获知风险处理进度，如果风险处理遇到问题管理者也无法及时介入，使得企业出现法律和合规问题。

综上可知，企业财经需要员工周期性制作汇报材料向各个领域的管理者们进行汇报，但是汇报材料制作效率低，很容易导致风险延迟，同时，管理者们也无法及时获知风险处理进度，如果风险处理遇到问题管理者也无法及时介入，使得企业出现法律和合规问题。因此，企业财经领域如何及时、高效的进行风险管理，是一个亟待解决的问题。

为了解决上述企业财经领域难以及时高效的进行风险管理的问题，本申请提供了一种业务管理方法、系统及的相关设备，该方法通过接收用户发起的看板请求，根据看板请求携带的用户角色，获取该用户角色对应的看板页面，该看板页面包括风险分析区域和任务处理区域，风险分析区域用于向用户展示用于描述异常数据的风险分析情况的分析指标，该分析指标是根据异常数据的分析状态生成的，任务处理区域用于向用户展示用于描述风险任务的处理进展的处理指标，该处理指标是根据风险任务的处理状态生成的，风险任务是业务管理系统根据异常数据的分析结果生成的，使用该方法向用户展示的页面不仅显示有对异常数据的风险分析的情况，还显示任务处理的情况，并且该风险分析情况和风险处理情况是根据分析状态和处理状态确定的，也就是实时的处理情况，这样风险管理不再依赖于人工汇报，使得风险管理能够更加全面和及时；同时通过分区显示分析指标和处理指标，使得看板页面重点突出，复杂的指标也易于理解和解读，提高用户的数据洞察力和决策效果，还可以根据用户角色来设置每个区域内显示的分析指标和处理指标，不同角色显示的指标类型不同，满足财经管理中不同用户角色(比如管理者和一线人员)的使用需求，因此，通过本申请提供的业务管理方法，企业财经可以更加及时、高效的进行风险管理。

下面结合附图详细介绍本申请所要保护的技术方案。

图1是本申请提供的一种业务管理系统的架构图，如图1所述，该架构包括客户端100以及业务管理系统200，其中，客户端100以及业务管理系统200之间存在通信连接，具体可以是有线连接也可以是无线连接，本申请不作具体限定。其中，与业务管理系统200建立通信连接的客户端100的数量可以是一个或者多个，本申请不作具体限定。

客户端100用于实现人机交互，可以部署于终端设备或者计算设备，终端设备包括个人电脑、智能手机、可穿戴设备、掌上处理设备、平板电脑、移动笔记本、增强现实(augmented reality,AR)设备、虚拟现实(virtual reality,VR)设备、一体化掌机、穿戴设备、车载设备、智能会议设备、智能广告设备、智能家电等等，智能家电可以是扫地机器人、拖地机器人等等，此处不作具体限定。

具体实现中，上述客户端100可以是在用户所控制的终端设备或计算设备上运行的软件或者应用程序，比如个人电脑(personal computer,PC)客户端，也可以是基于浏览器访问的web客户端，还可以是在移动终端放上的运行的应用(application,APP)客户端，还可以是云平台的控制台(console)，本申请不作具体限定。

可选地，上述客户端100可以是用于进行企业风险管理的客户端。这里的风险管理包括但不限于税务风险、市场风险、金融风险、经验风险、法律合规风险、技术风险等，本申请不作具体限定。具体可以是企业细分领域下的风险管理，比如前述内容中的全球关联交易风险管理，也可以是税务风险管理等，还可以是包括多个细分领域的总风险管理客户端，具体可根据实际的应用场景决定，本申请不作具体限定。

可选地，上述客户端100还可以是企业办公客户端中的一个插件或功能，用于实现企业风险管理。比如企业常用的(office automation,OA)客户端中的税务风险管理功能板块，或者全球关联交易风险管理功能板块等，上述举例用于说明，本申请不作具体限定。

可选地，上述客户端100还可以是云平台的客户端，比如云平台的控制台(console)，具体可以是基于万维网(world wide web,web)的console，也可以是基于应用程序接口(application programming interface,API)的console，本申请不作具体限定。该console可以向用户提供企业风险管理的云服务，用户可通过购买云服务的方式，获得本申请提供的业务管理系统的使用权限。

业务管理系统200可以部署于计算设备、计算设备集群或者终端设备，其中，计算设备包括裸金属服务器(Bare Metal Server,BMS)、虚拟机、容器或者边缘计算设备。BMS指的是通用的物理服务器，例如，ARM服务器或者X86服务器；虚拟机指的是通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在实体计算机中能够完成的工作在虚拟机中都能够实现。在计算设备中创建虚拟机时，需要将实体机的部分硬盘和内存容量作为虚拟机的硬盘和内存容量。每个虚拟机都有独立的基础输入/输出系统(basic input/output system,CMOS)、硬盘和操作系统，可以像使用实体机一样对虚拟机进行操作；容器是一种便携式软件单元，可以将应用及其所有依赖项合并为一个软件包，该软件包不受底层主机操作系统的限制，这样无需再构建复杂的环境，简化了应用开发到部署的过程；边缘计算设备是指更加接近数据源和终端用户，具有低延迟、高带宽特点的设备，比如智能路由、边缘服务器等等。计算设备集群可包括多个上述计算设备，比如数据中心，本申请不作具体限定；终端设备的描述可参考前述内容，这里不重复赘述。

可选地，业务管理系统200可以和客户端100部署于相同的终端设备上；或者，业务管理系统200部署于计算设备，客户端100部署于终端设备上；或者业务管理系统200部署于计算设备集群，客户端100部署于终端设备上，应理解，上述举例用于说明，具体可根据实际的应用场景决定业务管理系统200和客户端100的部署情况。

进一步地，图1中的业务管理系统200可进一步划分为多个单元模块，示例性地，如图1所示，业务管理系统200包括配置单元210、看板获取单元220、角色识别单元230、看板发送单元240、任务处理单元250、风险分析单元260、数据获取单元270以及同步单元280，还包括用于存储看板页面的看板数据库2901，用于存储指标的指标数据库2902以及用于存储状态的状态数据库2903。需要说明的，看板数据库2901、指标数据库2902和状态数据库2903可以部署于业务管理系统200内部，也可以部署于业务管理系统200外部，本申请不作具体限定。应理解，图1是一种示例性划分方式，业务管理系统200还可以包括更多或者更少的单元，本申请不作具体限定。

需要说明的，图1所示的结构可以是业务管理系统200部署于单个计算设备的实现方式，当业务管理系统200部署于多个计算设备组成的计算设备集群时，该计算设备集群中的不同的计算设备可以分别存储有用于实现配置单元210、看板获取单元220、角色识别单元230、看板发送单元240、任务处理单元250、风险分析单元260以及数据获取单元270的指令，比如计算设备集群中的计算设备A存储有配置单元210、看板获取单元220、角色识别单元230以及看板发送单元240的指令，计算设备B存储有任务处理单元250、风险分析单元260、数据获取单元270以及同步单元280的指令，计算设备C包括看板数据库2901、指标数据库2902以及状态数据库2903，上述举例用于说明，本申请不做具体限定。当然，不同的计算设备也可以存储有相同的指令，比如计算设备B和计算设备D均存储有任务处理单元250、风险分析单元260、数据获取单元270以及同步单元280的指令，用于组合实现任务处理单元250、风险分析单元260、数据获取单元270以及同步单元280的功能，本申请不作具体限定。

其中，为了使本申请能够更好地理解，图1只绘制出了一个客户端100与业务管理系统200建立通信连接，实际上，与业务管理系统200建立通信连接的客户端数量为一个或者多个，其他客户端与业务管理系统200进行通信的步骤流程与客户端100相同，这里不再重复展开赘述。

下面对业务管理系统200中各个单元模块的功能进行说明。

配置单元210用于接收用户发送的配置信息，生成看板页面。具体地，配置单元210可以接收客户端100发送的携带有配置信息的看板配置请求，该看板配置请求可以是用户通过客户端100提供的配置接口发起的，该配置接口可以是图形用户界面(graphical userinterface,GUI)、API、命令行界面(command line interface,CLI)等，本申请不作具体限定。

其中，看板页面可以是用户界面的一种，看板页面侧重任务的可视化，通常应用于团队协作的场景。具体实现中，看板页面可以是客户端页面、web页面、APP页面等，本申请不作具体限定。

在本申请实施例中，看板页面可包括风险分析区域、任务处理区域以及异常总览区域中的一种或者多种。每个区域可以展示一个或者多个数据，下面分别对风险分析区域、任务处理区域以及指标显示区域进行说明。

在一可能的实现方式中，风险分析区域用于显示异常数据的风险分析情况，具体地，风险分析区域可包括分析指标，分析指标用于描述分析任务的处理情况，分析任务包括对异常数据进行风险分析。可选地，分析指标可包括第一分析指标和第二分析指标。下面分别对其进行解释说明。

可选地，第一分析指标用于描述分析结果，分析结果指的是对异常数据进行风险分析之后获得的结果，风险分析通常指的是对异常数据中潜在的风险进行识别、评估和量化的过程。它的目标是从异常数据中理解可能发生的风险事件以及其对项目或任务的影响。

具体实现中，第一分析指标可包括风险等级、风险类型、风险原因、风险影响、风险负责人等指标中的一种或者多种，其中，风险等级用于对异常数据进行评估，确定其优先级和重要性；风险类型用于将异常数据按为不同的类型，例如技术风险、市场风险、财务风险等；风险原因指的是异常数据会导致风险的根本原因，以便采取相应的预防措施；风险影响指的是明确风险发生后可能对项目或任务产生的影响，如进度延误、成本增加等；风险负责人指的是负责管理和监控该异常数据的相关责任人或团队。

举例来说，看板页面可以显示风险等级，比如风险等级为1级的异常数据数量为100个，风险等级为2级的异常数据数量为200个；再举例来说，看板页面显示风险类型，技术风险的异常数据为50个，存在市场风险的异常数据为200个，存在财务风险的异常数据为200个；再比如，看板页面显示风险原因，操作错误的异常数据为100个，配额有误的异常数据为200个，上述举例用于说明，看板页面所显示的分析结果可根据用户需求进行配置，本申请不作具体限定。

需要说明的，每一个第一分析指标还可按照时间粒度或者区域粒度进一步进行细分展示，比如对于风险等级这一结果指标来说，看板页面可以展示出在不同区域、不同子公司下的异常数据的风险等级，在子公司A出现1级风险的异常数据为10个，出现2级风险的异常数据为20个，子公司B出现1级风险的异常数据为1个，出现2级风险的异常数据为30个。具体可根据用户的业务需求进行灵活配置，本申请不作具体限定。

可选地，第二分析指标用于描述风险分析进展，具体可以用于描述分析任务的分析状态，或者说每个异常数据的分析状态，该分析状态至少包括待分析、分析中和已分析。具体实现中，风险分析进展包括每个分析状态的异常数据的数量或者占比。

需要说明的，第二分析指标还可按照时间粒度或者区域粒度进一步进行细分展示，比如看板页面可以展示待分析的异常数据的数量以及所属的公司、区域等，举例来说，子公司A待分析的异常数据数量为100，子公司B待分析的异常数据数量为1000，A省内的多个子公司待分析的异常数据数量为100，B省内的多个子公司待分析的异常数据数量为100。具体可根据用户的业务需求进行灵活配置，本申请不作具体限定。

应理解，看板页面中的风险分析区域还可以包括更多用于展示风险分析情况的分析指标，本申请不作具体限定。

在一可能的实现方式中，任务处理区域用于显示风险任务的处理进展，具体地，任务处理区域可包括处理指标，处理指标用于描述风险任务的处理情况，风险任务是业务管理系统200根据分析任务的分析结果生成的。

具体实现中，任务处理区域可包括处理指标，具体可用于描述每个风险任务的处理状态，该处理状态至少包括待处理、处理中和已处理。具体实现中，处理指标包括每个处理状态的任务数量。

在一可能的实现方式中，异常总览区域用于向用户展示异常数据相关的总览指标，总览指标包括异常数据总数、异常数据总金额、风险任务总数、风险任务总金额、风险原因趋势等，总览指标也可以按照时间粒度或者区域粒度进行细分展示，比如每个子公司的异常数据总数，异常数据的总金额，每个区域的异常数据总数，异常数据总金额等。

具体实现中，总览指标还可包括用户需求展示的一些指标，应理解，企业财经可包括为多个风险领域，不同的风险领域下用户需求的重要指标存在不同。举例来说，在全球关联交易领域，该指标信息可包括但不限于关联核销数量、关联开票数量、定价率异常数量等等，在税务领域，该指标信息可包括但不限于欠税情况、欠税时长、税务罚款等等，上述举例用于说明，异常总览区域具体可根据用户的业务需求进行灵活配置，本申请不作具体限定。

应理解，在企业财经领域中，不同角色的用户或用户组需求的看板页面是不同的，举例来说，一线员工的看板页面主要展示细节性的指标，比如每周的风险分析进展以及任务处理进展，而管理者的看板页面主要展示全局性的指标，比如每季度的分析结果以及任务处理进展，因此，不同角色的看板页面中包含的区域可能不同，不同角色的看板页面中同一个区域内显示的指标也可能不同。

在一可能的实现方式中，配置单元210根据用户的配置信息生成的看板页面可存储于看板数据库2901中，并且记录有每个看板页面对应的用户角色，其中，一个看板页面可以对应一个或者多个用户角色，一个用户角色也可以对应一个或者多个看板页面，本申请不作具体限定。示例性地，看板数据库2901可包括第一看板页面和第二看板页面。其中，第一看板页面供第一角色(或者用户组)的用户访问，第二看板页面供第二角色(或者用户组)的用户访问，第一角色的权限级别高于第二角色的权限级别，比如第一角色是管理层，第二角色是一线工作人员，或者第一角色是L1管理层，第二角色是L2管理层，或者第一角色是L2管理层，第二角色是技术专家，上述举例用于说明，本申请不作具体限定。

可选地，第一看板页面和第二看板页面均包括上述风险分析区域、任务处理区域以及异常总览区域，但是第一看板页面的风险分析区域包括第一分析指标，第二看板页面的风险分析区域包括第一分析指标以及第二分析指标。应理解，第一看板页面对应的用户角色需求全局性的指标，所以直接显示用于描述分析结果的第一分析指标，第二看板页面对应的用户角色需求细节性的指标，所以需要额外显示用于描述风险分析进展的第二分析指标。

参考前述内容可知，第一分析指标可包括风险等级、风险类型、风险原因、风险影响、风险负责人等指标，所以第一看板页面和第二看板页面所显示的第一分析指标也可以有所不同。举例来说，第一看板页面的风险分析区域显示的第一分析指标为风险原因。第二看板页面的风险分析区域显示的第一分析指标为风险等级和风险原因。上述举例用于说明，本申请不作具体限定。

进一步地，第一看板页面中每个区域显示的指标对应的时间范围大于第二看板页面中每个区域显示的指标对应的时间范围，换句话说，第一看板页面显示的是较长时间范围的指标，如年度指标或季度指标，用于总结和评估较长时间段内的绩效、趋势或目标达成情况。第二看板页面显示的是较短时间范围的指标，如季度指标、月度指标或每周指标，用于具体的周期性监测和控制，帮助团队或管理者了解绩效和进展情况。

需要说明的，上述第一看板页面和第二看板页面是一种示例性的实现方式，用于表示本申请提供的业务管理系统200可以展示多种类型的看板页面，不同的看板页面可对应不同角色的用户。比如，第一看板页面也可以进一步划分为第三看板页面和第四看板页面，第三看板页面可以供L1管理层使用，第四看板页面可以供L2管理层使用。应理解，上述举例用于说明，本申请不作具体限定。按照用户角色类型来确定看板页面中每个区域显示的指标，使得业务管理系统200不仅可以提供更宏观、更长期的指标视角，而且可以提供更细节、更短期的指标视角，有助于全面了解和评估企业风险情况，使得企业财经可以实现及时、高效的风险管理。

需要说明的，看板页面中每个区域内的指标的表现方式，可以是柱状图、折线图、饼状图、表格等任意表现方式，本申请不作具体限定。

在本申请实施例中，看板页面是根据用户输入的配置信息生成的。

可选地，配置信息包括指标配置信息，其中，指标配置信息包括用户需求在风险分析区域、任务处理区域以及异常总览区域显示的指标，具体可参考前述内容中关于各个区域可以显示的指标，这里不重复赘述。用户可根据自己的业务需求输入配置信息，生成自己需要的看板页面。

可选地，配置信息还包括外观配置信息，其中，外观配置信息用于描述看板页面的视觉设计效果，外观配置信息可包括看板页面的布局信息和交互逻辑信息。其中，布局信息包括页面的布局结构、组件样式、尺寸信息、图像和图标等，其中，布局结构指的是各个组件之间的相对位置关系和层次关系；组件样式可包括组件的颜色、字体、背景、边框等；尺寸信息可包括组件的左上角坐标、宽度、高度等；图像和图标指的是网页中出现的图像或者图标元素。交互逻辑信息包括交互动作、交互组件、响应行为和响应组件，其中，交互动作指的是用户与页面进行交互时的操作，交互组件是用户所交互的组件，响应行为是页面对交互动作的响应和反馈，响应组件是实现该响应和反馈的组件。应理解，上述举例用于说明，本申请不作具体限定。

可选地，配置信息还包括数据源信息，该数据源信息可包括数据的来源或者数据存储的位置信息，业务管理系统200可根据数据源信息获取数据，然后根据用户需求的指标信息直接从数据中获取指标，或者根据数据计算出指标，然后将指标在看板上进行显示。具体实现中，上述数据源信息可以是数据库的名称、地址、密钥等信息，以便业务管理系统200可以连接到数据库并从中获取所需的数据，比如本申请中的分析指标和处理指标可以从指标数据库2902中获取；上述数据源信息还可以是API接口的统一资源定位符(uniformresource locator,URL)、身份验证凭据或者密钥等信息，以便业务管理系统200可以通过API访问和调用所需的数据；上述数据源信息还可以是文件路径、名称和格式等信息，以便业务管理系统200可以读取和解析文件中的数据；上述数据源信息还可以是实时数据流的信息，比如消息队列、流处理平台的地址、协议、访问凭证等信息，以便业务管理系统200可以读取实时数据，对其进行分析和展示。应理解，上述举例用于说明，本申请不作具体限定。

可选地，配置信息还包括用户角色信息，用户角色信息描述了各个角色或用户组的身份和权限级别，不同用户组或角色只能看到、访问和操作其对应权限级别的看板页面。具体实现中，用户角色信息包括身份信息、权限级别和角色关联等信息，身份信息定义了用户在系统中扮演的特定身份或角色，比如系统管理员、L1管理层、L2管理层、技术专家、一线员工等，具体可根据实际的应用场景确定，本申请不作具体限定；权限级别定义了用户可以访问的看板页面，不同的角色可能具有不同的权限，以控制对不同类型的看板页面访问和操作。例如，管理层可以访问的看板页面可能是年度报告、季度报告，技术专家可以访问的看板页面可能是周报、月度报告，上述举例用于说明，本申请不作具体限定；角色关联制定了用户和角色之间的关联关系，表示哪些用户属于哪个角色或用户组，通过将用户分配给特定的角色，可以对用户进行身份验证和授权，以确定他们所具备的权限和访问权限，系统可以实现精细的访问控制和权限管理，确保用户只能访问和执行其具备权限的功能和页面。

需要说明的，看板配置请求还可以包括更多的内容，具体可根据实际的应用场景决定，这里不一一举例说明。同时，用户可根据自己的业务需求输入需要的配置信息，用户未进行配置的信息可以使用系统提供的默认配置。

在本申请实施例中，看板页面可以是使用低代码开发技术生成的页面，具体实现中，配置单元210可以根据用户输入的配置信息，生成统一格式的元数据信息，然后根据元数据信息获得页面的低代码配置，最后通过低代码技术，根据低代码配置生成看板页面。

可选地，上述元数据信息是描述看板页面的数据，具体可以是用于描述和定义看板页面的属性(properties)、结构(structure)和行为(behavior)的数据，其中，属性是指页面或页面元素的外观、样式、尺寸、位置等，页面元素是页面中的基本构建块，如标题、段落、链接、图像等，例如，属性可包括背景色、字体大小、边框样式、宽度等；结构指的是页面的组织方式和布局，描述了页面中各个元素的相对关系、嵌套层次和组织结构等，例如，结构可包括页面中的头部、导航栏、正文、侧边栏、页脚等；行为是指页面或页面元素的交互动作和响应行为，其中，交互动作是用户与网页进行的操作动作，响应行为是页面对交互动作的响应和反馈。例如，用户点击一个按钮，页面弹出一个新的对话框，那么点击按钮为交互动作，弹出对话框为响应行为。上述举例用于说明，本申请不作具体限定。简单来说，属性描述了页面或元素的外观和特征，结构描述了页面的组织方式和布局，行为描述了页面的交互逻辑。

具体实现中，元数据可以包括页面的标题，用于描述页面的主题或目的；元数据可以包括页面描述，用于简要介绍页面的内容和功能；元数据可以包括与页面内容相关的关键词或标签，用于搜索引擎优化(search engine optimization,SEO)或索引目的；元数据可以包括页面样式和外观，比如背景颜色、字体样式、布局等；元数据可以包括页面所需的外部脚本和样式表的链接，用于加载和应用特定的功能和样式；元数据可以包括页面中的元素布局和结构，例如顶部导航栏、侧边栏、内容区域等；元数据可以包括页面中使用的各种组件和控件，比如按钮、表单字段、图像等；元数据可以包括页面和数据之间的绑定关系，指定将哪些数据展示在页面上的特定位置；元数据可以包括页面中组件的交互行为和事件，例如点击事件、表单提交等；元数据可以包括页面的访问权限限制，如公开访问、登录访问或特定用户角色访问等；元数据可以包括页面的整体结构和导航，指定页面之间的关联关系和导航路径等；元数据可以包括其他自定义属性，以满足特定的需求和约定，上述举例用于说明，本申请不作具体限定。

应理解，元数据信息为看板页面提供了统一的描述和定义，使得业务管理系统200可以通过修改元数据，实现对看板页面的增加、删除、修改组件信息或调整交互逻辑，而不需要修改实际生成页面的代码，从而实现页面的可配置性。通过元数据信息可以实现页面的重用和扩展，相同或类似的元数据可以被多次使用生成不同的页面，减少重复性工作，扩展元数据可以快速增加新的组件类型和新的交互逻辑，提高系统的可扩展性。同时，将配置信息抽象为元数据后，可以集中管理和维护所有看板页面，对所有看板页面的配置进行统一的更新和调整，这种集中管理和维护的方式简化了开发和维护的过程。

具体实现中，可以通过人工智能(artificial intelligence,AI)技术获得上述元数据信息。使用第一样本集对第一神经网络进行训练，获得训练好的第一生成模型。具体地，该第一样本集包括已知配置信息和对应的已知元数据信息，将已知配置信息输入第一神经网络获得输出结果，根据输出结果与已知元数据信息之间的差距对第一神经网络的模型参数进行反向传播，然后再输入下一个已知配置信息，进行下一次反向传播，循环多次直至模型收敛，获得训练好的第一生成模型。训练好的第一生成模型可以根据输入的配置信息推理出其对应的元数据信息。其中，上述第一神经网络可包括但不限于卷积神经网络(convolutional neural network,CNN)、循环神经网络(recurrent neural network,RNN)、图神经网络(graph neural network,GNN)、长短期记忆网络(long short-termmemory network,LSTM)等，本申请不作具体限定。

可选地，根据元数据生成的低代码配置包括布局信息包括页面中每个组件(component)的组件位置。一个组件可包括一个或者多个元素。应理解，使用低代码技术进行页面开发时，可将页面划分为多个可重用的部分进行开发，从而提高开发效率，这些可重用的部分即为组件。例如，一个网页上的评论框可以被视为一个组件，该组件包括文本输入框、提交按钮、用户头像等元素。

进一步地，布局信息还可包括每个组件的视觉信息，比如布局结构、组件样式、组件的尺寸信息、图像和图标等，其中，布局结构指的是各个组件之间的相对位置关系和层次关系；组件样式可包括组件的颜色、字体、背景、边框等；尺寸信息可包括组件的左上角坐标、宽度、高度等；图像和图标指的是网页中出现的图像或者图标元素。应理解，上述举例用于说明，布局信息还可包括更多的内容，本申请不作具体限定。

可选地，根据元数据生成的低代码配置还包括交互逻辑信息，该交互逻辑信息包括交互动作、交互组件、响应行为和响应组件，其中，交互动作指的是用户与页面进行交互时的操作，交互组件是用户所交互的组件，响应行为是页面对交互动作的响应和反馈，响应组件是实现该响应和反馈的组件。应理解，上述举例用于说明，交互逻辑信息还可包括更多的内容，比如页面ID、交互位置等，本申请不作具体限定。

需要说明的，上述低代码配置还可包括更多内容，比如还可包括数据源配置信息，用于将看板页面与不同的数据库、API或第三方服务等不同的数据源进行连接；比如还可包括权限和访问控制配置，用于配置用户角色、权限级别和访问控制规则，控制不同角色的用户只能访问对于应权限的看板页面，应理解，上述举例用于说明，低代码配置还可包括更多内容，具体可根据实际的应用场决定，这里不一一举例说明。在一些可能的实现方式中，上述低代码配置还可以是无码化配置，低代码配置还需要开发人员使用少量的代码完成开发，无码化配置可以供非技术人员通过无需编写任何代码的方式完成开发，无码化配置提供更高级别的抽象和工具，使非技术人员能够以更直观、易于理解的方式进行应用的设计、定制和管理。简单来说，无码化配置更强调非技术人员的可参与性，低代码配置更偏向于开发人员使用代码配置来进行更灵活的扩展和定制。两者在具体实现和使用方法上可能存在差异，但总体目标是相似的，即提高开发效率和降低技术门槛。

具体实现中，也可以通过AI技术获得上述低代码配置，具体地，可使用第二样本集对第二神经网络进行训练，获得训练好的第二生成模型，具体地，该第二样本集包括已知元数据和对应的已知低代码配置，将已知元数据输入第二神经网络获得输出结果，根据输出结果与已知低代码配置之间的差距对第二神经网络的模型参数进行反向传播，然后再输入下一个已知配置信息，进行下一次反向传播，循环多次直至模型收敛，获得训练好的第二生成模型。训练好的第二生成模型可以根据输入的元数据信息推理出其对应的低代码配置。其中，上述第二神经网络可包括但不限于CNN、RNN、GNN、LSTM等，本申请不作具体限定。

可选地，根据低代码配置生成的页面可以是一个结构(schema)文件，应理解，低代码平台的目标是让非专业开发人员也能够快速构建页面，而不需要深入编写大量的代码。为了实现这一目标，这些平台通常提供了可视化的界面，允许用户通过拖拽、设置参数等方式来配置页面的各个部分，根据这些配置即可生成页面的schema。所以schema文件实际上是一个用于描述页面结构和内容的文件，定义了页面的组成、布局、数据以及交互逻辑等信息，通常情况下，schema文件通过特定的标记语言或数据格式进行定义，例如JSON(JavaScript object notation)或XML(extensible markup language)。根据schema文件，系统可以理解页面的结构和行为，从而更高效的构建出页面，所以业务管理系统200可以将每个看板页面以schema文件的形式进行存储，每个看板页面拥有对应的用户角色信息。

应理解，配置单元210根据用户的配置信息生成统一格式的元数据信息，然后根据元数据信息获得页面的低代码配置，最后基于低代码平台和低代码配置生成看板页面。这样对用户输入的配置信息进行多次抽象和归纳，使得看板页面可以被用户灵活配置，将用户需求与底层设计实现解耦，用户的需求的变更和扩展可以更加简化，系统拥有更好的可扩展性和维护性，可以适应更广泛的应用场景。

需要说明的，业务管理系统200可包括看板数据库2901以及指标数据库2902，其中，看板数据库2901用于存储不同角色对应的看板页面，比如前述内容中的第一看板页面以及第二看板页面，指标数据库2902用于存储分析指标、处理指标和总览指标，其中，看板数据库2901和指标数据库2902可以进行对接，每个看板页面中的每个区域显示的指标可以是根据用户的配置信息以及指标数据库2902中的多个指标获得的，具体可参考前述内容中关于每个区域可以显示的指标的相关描述，这里不重复展开赘述。

看板获取单元220用于接收用户通过客户端100发起的看板获取请求。

其中，看板获取请求可包括用户的用户角色，该用户角色用于标识用户的角色和权限。参考前述内容可知，看板数据库2901中记录了看板页面和用户角色之间的对应关系，因此根据看板获取请求中的用户角色可以从看板数据库2901中确定该用户请求查看的看板页面。

角色识别单元230用于根据看板获取请求中携带的用户角色，从看板数据库2901中获取该用户角色对应的看板页面。

举例来说，如果用户角色为第一角色，那么角色识别单元230可以从看板数据库2901中获取第一看板页面。如果用户角色为第二角色，那么角色识别单元230可以从看板数据库2901中获取第二看板页面。通过不同的角色配置不同的看板页面，不同的看板页面显示相同或者不同的分析指标、处理指标和总览指标，使得企业内不同级别的员工都可以通过业务管理系统200获取到自己所需的风险指标，有助于全面了解和评估企业风险情况，使得企业财经可以实现及时、高效的风险管理。

具体实现中，角色识别单元230可以先获取用户角色对应的历史看板页面或者配置单元210生成的低代码配置，然后从状态数据库2903中获取每个分析状态下的分析任务数量，确定分析指标，然后获取每个处理状态下的风险任务数量，确定处理指标，再结合用户需求的其他看板指标，比如总览指标、分析结果等，根据分析指标、处理指标以及上述其他看板指标更新历史看板页面中的各个区域获得用户角色对应的看板页面，或者，根据分析指标、处理指标以及上述其他看板指标结合低代码配置生成用户角色对应的看板页面。

看板发送单元240用于将角色识别单元230获取到的对应角色的看板页面发送给客户端100。

通过上述配置单元210、看板获取单元220、角色识别单元230以及看板发送单元240的描述可知，本申请提供的业务管理系统200可以根据不同的用户角色，向用户展示不同的看板页面，并且每种看板页面都可以包括风险分析区域、任务处理区域以及异常概览区域，风险分析区域可以展示分析指标，任务处理区域可以展示处理指标，异常概览区域可以展示总览指标。其中，分析指标和处理指标是根据风险分析情况以及风险任务处理的情况获得的。

下面对上述看板页面中显示的分析指标、处理指标以及总览指标的获取过程进行解释说明。

数据获取单元270用于获取多个异常数据。

具体实现中，异常数据包括但不限于财务异常数据、经营异常数据、股价异常数据等，其中，财务异常数据可以是财务报表数据的异常，比如收入、利润、资产负债表等项目的异常波动或异常值；经营异常数据可以是企业的经营活动和业务表现异常，比如销售额突然下降、市场份额的大幅变动等；股价异常可以是企业股票价格的异常波动，比如股价暴涨或暴跌、股票交易量的异常变化等，上述异常数据的举例用于说明，任何可能导致财经风险的数据都可以作为异常数据，本申请不作具体限定。其中，异常数据的获取来源可包括但不限于财务报表、股市数据、经济指标、行业研究报告、新闻报道等，本申请不作具体限定。

风险分析单元260用于将多个异常数据发送给客户端100进行分析，获得分析结果。

具体实现中，业务管理系统200可记录有分析用户名单，该分析用户名单包括至少一个用于进行风险分析的用户或者用户组，举例来说，分析用户名单上的用户可以是企业内的风险分析师，用户组可以是风险分析部门。风险分析单元260可以将异常数据发送分析用户名单上记录的用户或者用户组，获得其返回的分析结果。其中，分析用户名单可以是用户通过配置单元210配置生成的。

可选地，该分析用户名单可记录有每种异常数据对应的用户或者用户组，比如A类异常数据供部门A的风险分析师进行风险分析，B类异常数据供部门B的风险分析师进行风险分析。具体实现中，用户可通过配置单元210灵活配置分析用户名单，还可为分析用户名单上的各个用户设置优先级，本申请不作具体限定。

可选地，该分析用户名单可记录有工作流信息，该工作流信息可包括多个处理节点，每个处理节点对应一个用户或用户组。一些异常数据可能需要多个分析用户给出分析意见之后才能完成风险分析，风险分析单元260可以在接收到上一个分析用户反馈的分析意见之后，按照用户配置的工作流，向下一个分析用户发送异常数据和上一个分析用户反馈的分析意见，以此类推，直至获得所有分析用户的分析意见之后，获得分析结果。具体实现中，用户可通过配置单元210预先配置好某些类型的分析任务对应的工作流。

在本申请实施例中，风险分析单元260还用于对状态数据库2903中的分析状态进行更新，其中，分析状态用于指示异常数据当前的所处的分析进度，分析状态至少包括待分析、分析中和已分析。

可选地，风险分析单元260用于将获取到的异常数据的分析状态记录为待分析；还用于按照分析用户名单将分析状态为待分析的异常数据发送给对应的客户端100，将该异常数据的分析状态记录为分析中；还用于获得客户端100反馈的分析结果之后，将该异常数据的分析状态记录为已分析，并存储该异常数据的分析结果。

具体实现中，该分析结果可包括分析结论，分析结论包括存在风险和不存在风险，对于分析结论为存在风险的分析结果，还可包括前述内容中的第一风险指标，也就是风险等级、风险类型、风险原因、风险影响、风险负责人等指标中的一种或者多种。

在本申请实施例中，风险分析单元260还用于根据分析结果中的分析结论生成风险任务，将风险任务发送给任务处理单元250。具体实现中，风险分析单元260可以根据分析结论为存在风险的分析结果，生成对应的风险任务。

进一步地，该分析结果还可包括对异常数据的处理计划，如果分析结果中的分析结论为不存在风险，但分析结果包括处理计划，那么风险分析单元260也可以根据该分析结果生成对应的风险任务。如果分析结果中的分析结论为不存在风险，且不包括处理计划，那么风险分析单元260不对其进行处理，也就是不生成风险任务。

应理解，财经领域内的部分异常数据可能并不会带来风险，但是仍然需要员工制定任务计划来改进业务方针。举例来说，假设一个电商公司每月的订单量通常在稳定的范围内波动，但某个月份订单量突然异常低，导致销售额大幅下降。风险分析师对其进一步分析发现，这个低订单量是由某个节假日导致的，在这种情况下，订单量异常不会直接为企业带来风险。但是员工可以对此制定处理计划，比如优化该节假日期间的供货计划和库存管理，以确保能够满足消费者的需求，并提供良好的购物体验，或者基于该节假日定制特别的促销活动、优化广告投放和加强市场宣传等，以提高订单量。上述例子中，对异常数据进行分析后获得的分析结论为不存在风险，但是员工希望制定处理计划来优化业务表现，发现潜在的改进方针，确保产品和服务的优化，因此对于分析结果中包含处理计划的异常数据，风险分析单元260可以生成对应的风险任务进行处理。

可选地，分析状态还可包括待复核和已复核，风险分析单元260还用于在获得异常数据的分析结果之后，将该分析结果发送给第一复核用户，获得复核结果。其中，复核结果包括同意和不同意，上述分析用户名单包括分析用户和第一复核用户，这里的第一复核用户可以是分析用户的主管，负责复核分析用户反馈的分析结果。应理解，通过复核的方式可以进一步确保分析结果的准确度。具体实现中，分析用户名单可以记录分析用户和第一复核用户的对应关系，比如分析用户A的第一复核用户为主管B，分析用户C的第一复核用户为主管D，具体可根据实际的业务需求进行配置，本申请不作具体限定。

具体实现中，风险分析单元260可以将异常数据发送给分析用户，然后获得分析结果，若分析结果中的分析结论为存在风险，或者，分析结果中的分析结果为不存在风险但分析结果包括处理计划，风险分析单元260将该异常数据的分析状态从已分析修改为待复核，然后将该异常数据和分析结果发送给第一复核用户，获得复核结果之后，若复核结果为同意，将分析状态修改为已复核，风险分析单元260根据分析结果中的分析结论生成风险任务；若复核结果为不同意，风险分析单元260将异常数据的分析状态修改为待分析，再按照分析用户名单将待分析的异常数据发送给客户端100进行风险分析。

进一步地，若分析结果中的分析结论为不存在风险，且分析结果不包括处理计划，风险分析单元260可以将该异常数据的分析状态从已分析修改为待复核，然后将该异常数据和分析结果发送给第一复核用户，获得复核结果为同意后，不对该异常数据进行处理，具体可以将分析状态修改为已结束，或者将异常数据删除；若复核结果为不同意，风险分析单元260将异常数据的分析状态修改为待分析，再按照分析用户名单将待分析的异常数据发送给客户端100进行风险分析。

应理解，图1是一种示例性划分方式，实际处理过程中客户端100的数量为多个，与各个单元进行交互的客户端100可能是不同的客户端，比如与风险分析单元260交互的客户端100为客户端A，与任务处理单元250交互的客户端100为客户端B，与配置单元210交互的客户端100为客户端C，与看板获取单元220交互的客户端100为客户端D，上述举例用于说明，本申请不作具体限定。

简单来说，每个分析结果都需要进行复核，如果复核结果为不同意，那么将分析状态修改为待分析，重新进行分析，如果复核结果为同意，且分析结论为存在风险，或者不存在风险但拥有处理计划，此时风险分析单元260可以生成风险任务。如果复核结果为同意，且分析结果为不存在风险且未拥有处理计划，此时风险分析单元260可以不对异常数据进行处理。

可选地，风险分析单元260可以根据分析状态和分析结果，从多个异常数据中获取至少一个风险任务数据，然后根据至少一个风险任务数据生成一个或者多个风险任务。其中，风险任务数据包括分析状态为已复核，分析结论为存在风险的异常数据，还包括分析状态为已复核，分析结论为不存在风险但包括分析计划的异常数据。具体实现中，如果分析结论为不存在风险且不包括分析计划的异常数据，其分析状态为已结束，那么这里的风险任务数据也可以理解为状态为已复核的异常数据。

具体实现中，N个风险任务数据可以生成M个风险任务，其中，N不等于M，应理解，在风险分析中，一些异常数据之间存在相关性，所以这些异常数据的解决方案也是相似的，为了提高任务处理效率，可以将这些存在相关性的异常数据合并到一个风险任务进行处理。举例来说，假设一家大型制造公司在财务报告中发现了3个异常数据，异常数据A：部分供应商账款未按时支付，资金流异常。异常数据B：财务部门的开支超过了预算。异常数据C：采购和库存管理之间协调失误，导致库存过多。这些异常数据与公司的财务管理不规范有关，因此对异常数据A、异常数据B和异常数据C进行风险分析之后，可以合并这些异常数据，创建一个名为“管理财务不规范”的风险任务。应理解，上述举例用于说明，本申请不作具体限定。

具体实现中，风险分析单元260可以在获取到至少一个风险任务数据以后，根据风险任务数据的分析结果，将至少一个风险任务数据进行聚类，同一个类别的风险任务数据可以合并生成同一个风险任务。风险分析单元260可结合分析结果中风险等级、风险类型、风险原因、风险影响、风险负责人等指标对风险任务数据进行聚类，比如将风险原因相似的风险任务数据进行合并生成一个风险任务，或者将处理计划相似的风险任务数据进行合并，或者将风险原因和处理计划均相似的风险任务数据进行合并生成一个风险任务，或者将风险负责人相同的风险任务数据进行合并生成一个风险任务，上述举例用于说明，本申请不作具体限定。

任务处理单元250用于将风险任务发送给客户端100进行处理，获得客户端100发送的任务反馈。

可选地，业务管理系统200可包括任务进展表，用于记录每个风险任务的处理进展，任务处理单元250接收到客户端100发送的任务反馈之后，可以根据任务反馈对任务进展表进行更新，具体可以是覆盖更新，也就是任务进展表只记录最新的任务反馈，也可以是增量更新，也就是在任务进展表中会记录每个阶段的任务反馈，具体可根据实际的应用场景决定，本申请不作具体限定。

可选地，业务管理系统200可包括处理用户名单，该处理用户名单可包括至少一个用于处理风险任务的用户或者用户组，举例来说，处理用户名单上的用户可以是企业的一线员工或者技术专家，用户组可以是业务部门。任务处理单元250可以将风险任务发送给处理用户名单上记录的用户或者用户组，获得其返回的任务反馈。其中，处理用户名单可以是用户通过配置单元210配置生成的。与上述分析用户名单类似的，该处理用户名单也可记录有每类风险任务对应的用户或者用户组，用户可通过配置单元210灵活配置处理用户名单，还可为处理用户名单上的各个用户设置优先级，还可以记录有工作流信息，该工作流信息可包括多个处理节点，每个处理节点对应一个处理用户或用户组。一些风险任务可能需要多个处理用户协同完成，业务管理系统200在接收到上一个处理用户的任务反馈之后，按照用户配置的工作流，向下一个处理用户发送风险任务以及其他用户的任务反馈，以此类推，直至按照工作流获得每个处理用户的任务反馈。

在本申请实施例中，任务处理单元250还用于对状态数据库2903中的处理状态进行更新。其中，处理状态用于指示风险任务所处的进度情况，处理状态包括待处理、处理中和已处理。

可选地，任务处理单元250可以在接收到风险分析单元260发送的风险任务之后，将接收到的风险任务的处理状态修改为待处理，在向客户端100发送风险任务之后，将该风险任务的处理状态修改为处理中，在接收到客户端100发送的任务关闭请求之后，将处理状态修改为已处理。

可选地，处理状态还包括复核中。具体实现中，任务处理单元250在接收到客户端100发送的任务延期请求时，可以将任务延期请求发送给第二复核用户进行审核，同时修改处理状态为复核中，接收第二复核用户反馈的复核结果，在复核结果为同意的情况下，修改任务期限，同时修改处理状态为处理中。

可选地，任务处理单元250在接收到客户端100发送的转处理请求时，可以将转处理请求发送给第二复核用户进行审核，同时修改处理状态为复核中，接收第二复核用户反馈的复核结果，在复核结果为同意的情况下，修改处理用户，同时修改处理状态为处理中。

简单来说，在复核结果为不同意的情况下，将处理状态修改为处理中，在复核结果为同意的情况下，按照用户发起的请求进行相应的处理后，将处理状态修改为处理中。应理解，上述处理用户名单包括处理用户和第二复核用户，这里的第二复核用户可以是处理用户的主管，负责复核处理用户发起的任务延期请求、任务关闭请求以及转处理请求。具体可根据实际的业务需求配置每个处理用户对应的第二复核用户，本申请不作具体限定。

同步单元280用于根据状态数据库2903对指标数据库2902进行更新。

在一可能的实现方式中，状态数据库2903与指标数据库2902进行对接，同步单元280可以根据状态数据库2903中的分析状态确定指标数据库2902中的分析指标。参考前述内容可知，分析指标包括用于描述分析结果的第一分析指标和用于描述分析进展的第二分析指标，第一分析指标可根据分析结果获得，也就是风险等级、风险类型、风险原因、风险影响、风险负责人等指标，第二分析指标包括可根据分析状态获得，比如第二分析指标可包括待分析的异常数据数量、分析中的异常数据数量以及已分析的异常数据数量等，本申请不作具体限定。

在一可能的实现方式中，同步单元280可以根据状态数据库2903中的处理状态确定指标数据库2902中的处理指标。处理指标用于描述风险任务的处理进展，因此处理指标可包括待处理的风险任务数量、处理中的风险任务数量以及已处理的风险任务数量等，本申请不作具体限定。

在一可能的实现方式中，同步单元280可以根据状态数据库2903中的处理状态、分析状态、分析结果以及一些其他财经风险指标确定指标数据库2902中的总览指标，具体可根据用户的业务需求计算出一些总览指标，比如异常数据总数、异常原因趋势、异常区域分布等，本申请不作具体限定。

在一可能的实现方式中，指标数据库2902可以与看板数据库2901对接，看板数据库2901中的看板页面可包括风险分析区域、任务处理区域以及异常总览区域，其中，风险分析区域是根据用户的配置信息以及指标数据库2902中的分析指标获得的，任务处理区域是根据用户的配置信息以及指标数据库2902中的处理指标获得的，异常总览区域是根据用户的配置信息、分析指标、处理指标以及其他财经分析指标获得的，具体可参考前述关于看板页面的配置和生成描述，这里不再重复赘述。

在一可能的实现方式中，看板获取单元220还用于接收第一用户发起的第一任务的处理请求，该处理请求是第一用户点击看板页面出发的，第一任务是分析任务或者风险任务，看板获取单元220还一用于向第一用户发送第一任务，接收第一用户反馈的处理结果，同步单元280还用于更新看板页面中的分析指标或者处理指标。使得业务管理系统可以实时更新分析状态或者处理状态，实时更新分析指标和处理指标，实时更新每个用户对应的看板页面，使得每个用户都可以及时获知风险分析进度和风险处理进度，避免风险延迟带来的财务危机。

需要说明的，本申请提供的业务管理系统可以应用于多种业务场景中，尤其是有看板展示需求，需要将各种任务处理进度实时展示在看板上的业务场景中，风险分析业务是其中的一种示例，本申请不作具体限定。

综上可知，本申请提供了一种业务管理系统，该系统可以接收用户发起的看板请求，根据看板请求携带的用户角色，获取该用户角色对应的看板页面，该看板页面包括风险分析区域和任务处理区域，风险分析区域用于向用户展示用于描述异常数据的风险分析情况的分析指标，该分析指标是根据异常数据的分析状态生成的，任务处理区域用于向用户展示用于描述风险任务的处理进展的处理指标，该处理指标是根据风险任务的处理状态生成的，风险任务是业务管理系统根据异常数据的分析结果生成的，使用该方法向用户展示的页面不仅显示有对异常数据的风险分析的情况，还显示任务处理的情况，并且该风险分析情况和风险处理情况是根据分析状态和处理状态确定的，也就是实时的处理情况，这样风险管理不再依赖于人工汇报，使得风险管理能够更加全面和及时；同时通过分区显示分析指标和处理指标，使得看板页面重点突出，复杂的指标也易于理解和解读，提高用户的数据洞察力和决策效果，还可以根据用户角色来设置每个区域内显示的分析指标和处理指标，不同角色显示的指标类型不同，满足财经管理中不同用户角色(比如管理者和一线人员)的使用需求，因此，使用本申请提供的业务管理系统，企业财经部门可以更加及时、高效的进行风险管理。

上文中结合图1，详细描述了根据本申请所提供的业务管理系统，下面将结合图2至图8，描述根据本申请所提供的业务管理方法。

图2是本申请提供的一种业务管理方法，该方法可应用于图1所示的业务管理系统中，如图2所示，该方法可包括以下步骤：

S210：客户端100向业务管理系统200发送用户输入的配置信息。该步骤可由图1实施例中的配置单元210实现。

可选地，配置信息包括指标配置信息、外观配置信息、数据源信息、用户角色信息中的一种或者多种，其中，指标配置信息包括用户需求在风险分析区域、任务处理区域以及异常总览区域显示的指标，上述区域内指标的描述可参考前述相关内容，这里不重复赘述。外观配置信息用于描述看板页面的视觉设计效果，具体可包括看板页面的布局信息和交互逻辑信息。数据源信息可包括数据的来源或者数据存储的位置信息，使得业务管理系统200可根据数据源信息获取指标显示在看板页面上，或者根据数据源信息获取数据经过一系列的计算之后生成指标显示在看板页面上，比如本申请中的分析指标和处理指标的数据源信息可以是指标数据库2902的地址信息或者接口信息。用户角色信息描述了各个角色或用户组的身份和权限级别，不同用户组或角色只能看到、访问和操作其对应权限级别的看板页面。

需要说明的，配置信息的详细描述可参考图1实施例的相关描述，这里不重复赘述，并且，配置信息还可包括更多的内容，具体可根据实际的应用场景决定，这里不一一举例说明。

S220：业务管理系统200根据配置信息生成元数据信息。该步骤可由图1实施例中的配置单元210实现。

可选地，上述元数据信息是描述看板页面的数据，具体可以是用于描述和定义看板页面的属性、结构和行为的数据，属性描述了页面或元素的外观和特征，结构描述了页面的组织方式和布局，行为描述了页面的交互逻辑。元数据的具体内容可以参考图1实施例的相关描述，这里不重复赘述。

具体实现中，可以通过AI技术获得上述元数据信息。使用第一样本集对第一神经网络进行训练，获得训练好的第一生成模型，该第一样本集包括已知配置信息和对应的已知元数据信息，训练好的第一生成模型可以根据输入的配置信息推理出其对应的元数据信息。其中，上述第一神经网络可包括但不限于CNN、RNN、GNN、LSTM等，本申请不作具体限定。

应理解，元数据信息为看板页面提供了统一的描述和定义，使得业务管理系统200可以通过修改元数据来增加、删除、修改组件信息或调整交互逻辑，而不需要修改看板页面的代码，从而实现页面的可配置性。同时，通过元数据信息可以看板页面的重用和扩展，相同或类似的元数据可以被多次使用生成不同的页面，减少重复性工作，还可以对所有看板页面的配置进行统一的更新和调整，这种集中管理和维护的方式简化了开发和维护的过程。

S230：业务管理系统200根据元数据信息获得页面的低代码配置。该步骤可由图1实施例中的配置单元210实现。

可选地，根据元数据生成的低代码配置包括布局信息包括页面中每个组件的组件位置、视觉信息、交互逻辑等，其中，视觉信息可包括布局结构、组件样式、组件的尺寸信息、图像和图标等，交互逻辑信息包括交互动作、交互组件、响应行为和响应组件等，具体可参考图1实施例中的相关描述，这里不重复赘述。需要说明的，上述低代码配置还可包括更多内容，比如还可包括数据源配置、权限和访问控制配置等，具体可根据实际的应用场决定，这里不一一举例说明。

可选地，上述低代码配置还可以是无码化配置，低代码配置还需要开发人员使用少量的代码完成开发，无码化配置可以供非技术人员通过无需编写任何代码的方式完成开发。

具体实现中，业务管理系统200也可以通过AI技术获得上述低代码配置，具体地，可使用第二样本集对第二神经网络进行训练，获得训练好的第二生成模型，该第二样本集包括已知元数据和对应的已知低代码配置，训练好的第二生成模型可以根据输入的元数据信息推理出其对应的低代码配置。其中，上述第二神经网络可包括但不限于CNN、RNN、GNN、LSTM等，本申请不作具体限定。

S240：业务管理系统200基于低代码开发平台生成低代码配置对应的看板页面。该步骤可由图1实施例中的配置单元210实现。

可选地，根据低代码配置生成的页面可以是一个schema文件，应理解，低代码平台通常提供了可视化的界面，允许用户通过拖拽、设置参数等方式来配置页面的各个部分，根据这些配置即可生成页面的schema。所以schema文件实际上是一个用于描述页面结构和内容的文件，定义了页面的组成、布局、数据以及交互逻辑等信息，通常情况下，schema文件通过特定的标记语言或数据格式进行定义，例如JSON或XML。根据schema文件，系统可以理解页面的结构和行为，从而更高效的构建出页面，所以业务管理系统200可以将每个看板页面以schema文件的形式进行存储，每个看板页面拥有对应的用户角色信息。

应理解，业务管理系统200根据用户的配置信息生成统一格式的元数据信息，然后根据元数据信息获得页面的低代码配置，最后基于低代码平台和低代码配置生成看板页面。这样对用户输入的配置信息进行多次抽象和归纳，使得看板页面可以被用户灵活配置，将用户需求与底层设计实现解耦，用户的需求的变更和扩展可以更加简化，系统拥有更好的可扩展性和维护性，可以适应更广泛的应用场景。

在本申请实施例中，生成的看板页面包括风险分析区域、任务处理区域以及异常总览区域中的一种或者多种。其中，风险分析区域用于显示异常数据的风险分析情况，风险分析区域包括用于描述异常数据的风险分析情况的分析指标，分析指标是根据所述异常数据的分析状态生成的，任务处理区域包括用于描述风险任务处理情况的处理指标，处理指标是根据所述风险任务的处理状态生成的，风险任务是业务管理系统根据异常数据的分析结果生成的。异常总览区域用于展示异常数据的总览指标，总览指标包括异常数据的总数量、总金额、风险原因趋势等，本申请不作具体限定。

可选地，风险分析区域显示的分析指标可包括第一分析指标和第二分析指标，其中，第一分析指标用于描述分析结果，具体可包括风险等级、风险类型、风险原因、风险影响、风险负责人等指标中的一种或者多种。第二分析指标用于描述风险分析进展，具体可以包括每个分析状态的异常数据的数量或者占比，该分析状态至少包括待分析、分析中和已分析。应理解，看板页面中的风险分析区域还可以包括更多用于展示风险分析情况的分析指标，本申请不作具体限定。

可选地，任务处理区域显示的处理指标可包括每个处理状态对应的风险任务的数量或者占比，该处理状态至少包括待处理、处理中和已处理。应理解，看板页面中的任务处理区域还可以包括更多用于展示任务处理情况的处理指标，本申请不作具体限定。

可选地，总览指标包括异常数据总数、异常数据总金额等，总览指标也可以按照不同的时间粒度或者区域粒度进行细分展示，比如每个子公司的异常数据总数，异常数据的总金额，每个区域的异常数据总数，异常数据总金额等。总览指标还可包括用户需求展示的一些指标，应理解，企业财经可包括为多个风险领域，不同的风险领域下用户需求的重要指标存在不同。举例来说，在全球关联交易领域，该指标信息可包括但不限于关联核销数量、关联开票数量、定价率异常数量等，在税务领域，该指标信息可包括但不限于欠税情况、欠税时长、税务罚款等，上述举例用于说明，异常总览区域具体可根据用户的业务需求进行灵活配置，本申请不作具体限定。

在一可能的实现方式中，根据用户的配置信息生成的看板页面可存储于看板数据库2901中，并且记录有每个看板页面对应的用户角色，其中，一个看板页面可以对应一个或者多个用户角色，一个用户角色也可以对应一个或者多个看板页面，本申请不作具体限定。示例性地，看板数据库2901可包括第一看板页面和第二看板页面。其中，第一看板页面供第一角色的用户访问，第二看板页面供第二角色的用户访问，第一角色的权限级别高于第二角色的权限级别，比如第一角色是管理层，第二角色是一线工作人员，上述举例用于说明，本申请不作具体限定。

可选地，不同用户角色对应的看板页面可以显示不同的区域，比如第一看板页面显示风险分析区域，第二看板页面显示任务处理区域，或者，第一看板页面显示风险分析区域和异常总览区域，第二看板页面显示任务处理区域和异常总览区域，本申请不作具体限定。

可选地，不同用户角色对应的看板页面可以显示相同的区域，但是区域内的指标类型不同。比如第一看板页面和第二看板页面均显示风险分析区域、任务处理区域以及异常总览区域，但是第一看板页面中的风险分析区域包括第一分析指标，第二看板页面中的风险分析区域包括第一分析指标以及第二分析指标，或者，第一看板页面中的风险分析区域中的第一分析指标为风险原因，第二看板页面中的风险分析区域中的第一分析指标为风险等级，上述举例用于说明，本申请不作具体限定。

可选地，不同用户角色对应看板页面可以显示相同的区域，区域内的指标类型相同但是指标对应的时间粒度或者区域粒度不同，其中，时间粒度不同指的是指标所属的时间范围不同，区域粒度不同指的是指标所属的区域范围不同，举例来说，时间粒度不同可以指的是：第一看板页面中显示的指标是根据一年的异常数据获得的，第二看板页面中显示指标是根据一个月的异常数据获得的；区域粒度不同可以指的是：第一看板页面中显示的指标是整个集团公司M个子公司的异常数据获得的，第二看板页面中显示指标是根据某一个子公司的异常数据获得的，上述举例用于说明，本申请不作具体限定。

应理解，用户可根据业务需求对每个用户角色对应的看板页面进行配置，本申请不作具体限定。仍以上述例子为例，假设第一角色为管理者，第二角色为一线工作人员，第一看板页面对应的用户角色需求全局性的指标，第二看板页面对应的用户角色需求细节性的指标，一般来说，管理者只需要获知分析的结果即可，一线工作人员需要额外获知异常数据分析的进展情况，所以第一看板页面可以只包括第一分析指标，比如显示风险原因的趋势，在各个区域中各种风险原因的分布等，第二看板页面需要包括第一分析指标以及第二分析指标，不仅显示风险原因的趋势，还需要额外显示待分析的异常数据占比、分析中的以此数据占比以及已分析的异常数据占比。并且，第一看板页面显示的是较长时间范围的指标，如年度指标或季度指标，用于总结和评估较长时间段内的绩效、趋势或目标达成情况。第二看板页面显示的是较短时间范围的指标，如季度指标、月度指标或每周指标，用于具体的周期性监测和控制，帮助团队或管理者了解绩效和进展情况。

S250：客户端100向业务管理系统200发送看板获取请求。该步骤可由图1实施例中的看板获取单元220实现。

其中，看板获取请求可包括用户的用户角色，该用户角色用于标识用户的角色和权限。参考前述内容可知，看板数据库2901中记录了看板页面和用户角色之间的对应关系，因此根据看板获取请求中的用户角色可以从看板数据库2901中确定该用户请求查看的看板页面。

S260：业务管理系统200获取用户角色对应的看板页面。该步骤可由图1实施例中的角色识别单元230实现。

具体实现中，根据用户的配置信息生成的看板页面可存储于看板数据库2901中，每个看板页面与一个用户角色建立对应关系，换句话说，看板数据库2901存储有看板页面，还存储有看板页面与用户角色之间的对应关系。所以步骤S260处业务管理系统200可以根据看板获取请求中携带的用户角色，从看板数据库2901中获取该用户角色对应的看板页面。简单来说，如果用户角色为第一角色，那么角色识别单元230可以从看板数据库2901中获取第一看板页面。如果用户角色为第二角色，那么业务管理系统200可以从看板数据库2901中获取第二看板页面。

可选地，看板获取请求还可包括其他内容，比如时间粒度、区域粒度、业务类型等等。业务管理系统200可以根据看板获取请求获取用户角色对应的多个看板页面之后，然后根据看板获取请求中的时间粒度、区域粒度、业务类型等信息，从该用户角色对应的多个看板页面中获取对应的看板页面。

具体实现中，看板数据库2901中存储的看板页面是schema文件，该schema文件中记录有各个指标的数据源信息，获取看板页面时，可以根据该数据源信息获取实时指标，生成包含实时指标的看板页面，这里的实时指标包括上述分析指标和处理指标，这里的数据源信息可包括上述指标数据库2902的地址信息或者接口信息。应理解，本申请通过将看板数据库2901和指标数据库2902对接，指标数据库2902和状态数据库2903对接，该状态数据库2903实时管理异常数据分析状态、实时管理处理任务处理状态，使得用户获取的看板页面上的分析指标和处理指标均为实时指标，使得用户可以及时获知企业风险状态，及时作出风险决策，避免风险延迟的出现，降低企业出现法律合规问题的可能性。

S270：业务管理系统200向客户端发送用户角色对应的看板页面。该步骤可由图1实施例中的看板发送单元240实现。

应理解，通过不同的角色配置不同的看板页面，不同的看板页面显示相同或者不同的分析指标、处理指标和总览指标，使得企业内不同级别的员工都可以通过业务管理系统200获取到自己所需的风险指标，有助于全面了解和评估企业风险情况，使得企业财经可以实现及时、高效的风险管理。

为了使本申请能够被更好地理解，下面结合图3和图4对本申请提供的看板页面进行举例说明，图3是本申请提供的第一看板页面的示例图，图4是本申请提供的第二看板页面的示例图，其中，图3所示的第一看板页面对应的用户角色为第一角色，第二看板页面对应的用户角色为第二角色，第一角色的管理权限高于第二角色。需要说明的，图3和图4是一种示例性界面，本申请不作具体限定。

如图3所示，第一看板页面可包括用户登录控件310、概览区域320、筛选控件330、异常总览区域340、风险分析区域350以及任务处理区域360。应理解，图3是一种示例性的看板页面，第一看板页面还可以包括更多的区域，本申请不作具体限定。

用户登录控件310用于供用户点击获取用户信息，该用户信息可绑定有用户角色，根据该用户角色可以向用户显示该用户角色对应的看板页面，图3所示的例子中，登录的用户对应的用户角色为第一角色，比如管理者。

概览区域320用于向用户展示其对应角色的看板页面的业务类型，应理解，一个角色可以对应多个看板页面，这些看板页面可以是不同业务类型下的异常数据对应的看板页面，示例性的，如图3所示，概览区域320显示了异常路径、交易质量、关联开票和关联核销这些业务类型，用户可以根据自己的需求从概览区域320选择不同的业务类型，右侧的异常总览区域340、风险分析区域350、任务处理区域360可以显示出对应类别的指标。

进一步地，每个业务类型下的异常数据还可以进一步划分为多个风险类别，图3示例性给出了交易质量类别下的多个风险类别：赎期异常、币种异常、定价率异常-网络、定价率异常-终端、定价率异常-原材料等，用户可以根据自己的需求选择所需的风险类别，图3所示的第一看板页面是用户点击了概览区域320中的交易质量类别下的赎期异常之后显示的看板页面。

筛选控件330用于选择指标的时间粒度和区域粒度，图3所示的第一看板页面对应的用户角色是管理者，所以图3所示的第一看板页面对应的时间粒度为年度，也就是显示的指标均为年度指标，区域粒度为全部区域。

筛选控件330还用于选择当前的页面类型，示例性的，图3所示的界面显示出看板管理、风险分析、任务管理、系统配置等页面类型，其中，看板管理即为显示图3和图4所示的看板，风险分析用于供分析用户进行异常数据的风险分析，任务管理用于供处理用户进行风险任务的处理，系统配置用于供用户输入配置信息。

异常总览区域340用于向用户显示总览指标，总览指标的描述可参考前述内容，这里不重复赘述。图3所示的例子中，交易质量类别下的赎期异常的总览指标可包括总数量、总金额、异常趋势、区域分布以及子公司分布，其中，总数量指的是赎期异常的异常数据总数量有320条，涉及的总金额为680.23万，异常趋势指的是赎期异常的数据在不同月份下的数量变化，区域分布指的是赎期异常的数据在不同区域(比如省份、市区)下的数据分布情况，子公司分布指的是赎期异常的数据在不同子公司下的数据分布情况。

风险分析区域350用于向用户显示分析指标，由于图3所示的第一看板页面对应的用户角色为管理层，所以风险分析区域350只显示了第一分析指标(风险原因分析)，没有显示风险分析进展。示例性的，图3所示风险分析区域350，通过饼状图、折线图以及柱状图对风险原因分析的内容进行了详细描述。

任务处理区域360用于向用户显示处理指标，在图3所示的例子中，处理指标包括待处理的异常数据数量、处理中的异常数据数量以及已处理的异常数据数量。并通过饼状图、折线图以及柱状图对不同区域、不同子公司、不同时间段下各种状态的异常数据数量进行描述。

应理解，图3所示的饼状图、折线图以及柱状图用于举例说明，本申请不对每个指标具体的表现方式进行限定。

在图3所示的第一看板页面中，用户可以通过用户登录控件310登录自己的账号，然后根据自己的需求从概览区域320选择需要的业务类型以及风险类别，然后通过筛选控件330选择指标对应的时间粒度和区域粒度，此时用户操作的客户端100可以执行S250，向业务管理系统200发送携带有角色信息、业务类型、时间粒度以及区域粒度的看板获取请求，业务管理系统200可以执行S260～S270向客户端100发送图3所示的第一看板页面。

应理解，图3所示的第一看板页面对应的用户角色为第一角色(比如管理者)，下面结合图4对第二角色(比如一线员工)对应的第二看板页面进行举例说明。

如图4所示，第二看板页面可包括用户登录控件310、概览区域320、筛选控件330、异常总览区域340、第一风险分析区域350A、第二风险分析区域350B以及任务处理区域360。应理解，图4是一种示例性的看板页面，第二看板页面还可以包括更多的区域，本申请不作具体限定。

其中，用户登录控件310、概览区域320、筛选控件330、异常总览区域340以及任务处理区域360的描述可参考图3实施例中的相关描述，这里不重复赘述。图4所示的第二看板页面与图3所示的第一看板页面的主要区别在于风险分析区域350分成了第一风险分析区域350A、第二风险分析区域350B，还有页面排版发生了变化，因此下面对第一风险分析区域350A、第二风险分析区域350B进行解释说明。

第一风险分析区域350A用于展示第一分析指标(图4以风险原因分析为例)，第二风险分析区域350B用于展示第二分析指标(图4以分析进展为例)。其中，第一风险分析区域350A显示的内容与图3实施例中的风险分析区域350显示的内容相同，均为风险原因分析，因此这里不重复赘述。第二风险分析区域350B显示的分析进展即为第二分析指标，包括多种分析状态的异常数据数量和金额，例如图3所示的已分析220条，待分析230条。分析进展还通过分析进展趋势以及分析进展分布进行了进一步的解释说明，分析进展区域描述了不同时间下已分析或者待分析的异常数据数量变化趋势，分析进展分布描述了不同区域下已分析或待分析的异常数据的分布。

应理解，在图3和图4所示的例子中，第一看板页面供管理者使用，所以图3所示的第一看板页面不包括第二分析指标(分析进展)，因为管理者只需要看结果即可，但是一线员工需要管控风险分析的进度，所以第二看板页面额外包括第二分析指标(分析进展)。应理解，图3和图4用于举例说明，用户可根据不同用户角色的需求，灵活设置看板页面中风险分析区域350、任务处理区域360以及异常总览区域340中显示的指标，本申请不作具体限定。

上述图2～图4实施例详细描述了本申请提供的业务管理方法中的看板页面生成方式(S210～S240)以及查询方式(S250～S270)，该看板页面中的分析指标包括各种分析状态下的异常数据数量分布情况，处理指标包括各种处理状态下的风险任务的数据分布情况，所以分析指标和处理指标是实时更新的指标，需要业务管理系统200根据维护的状态数据库2903实时更新指标数据库2902，指标数据库2902再与看板数据库2901对接，这样每次用户获取看板页面时，每个看板页面显示的分析指标和处理指标都是实时指标，用户使用这样的看板页面可以及时获知企业财经状况，及时制定风险策略，避免出现风险延迟的问题。

下面结合图5和图6对业务管理系统200如何维护状态数据库2903的指标管理方法进行详细解释。

图5是本申请提供的一种业务管理方法中的指标管理方法的步骤流程示意图，该方法可应用于图1所示的业务管理系统中，如图5所示，该方法可包括以下步骤：

S510：业务管理系统200获取异常数据，更新异常数据的分析状态为待分析。该步骤可由图1实施例中的数据获取单元270实现。其中，分析状态存储于状态数据库2903中。

其中，异常数据包括但不限于财务异常数据、经营异常数据、股价异常数据等，异常数据的获取来源可包括但不限于财务报表、股市数据、经济指标、行业研究报告、新闻报道等，本申请不作具体限定，异常数据的详细描述可参考图1实施例的相关描述，这里不重复赘述。

S520：业务管理系统200向第一客户端100A发送异常数据，业务管理系统200更新异常数据的分析状态为分析中。该步骤可由图1实施例中的风险分析单元260实现。这里发送的异常数据可以是待分析的异常数据。

具体实现中，业务管理系统200可记录有分析用户名单，该分析用户名单包括至少一个用于进行风险分析的用户或者用户组，业务管理系统200可以将异常数据发送分析用户名单上记录的用户或者用户组，其中，分析用户名单可以是用户配置生成的，用户可为不同类型的异常数据设置其对应的分析用户，还可以为各个用户设置优先级，比如A用户优先处理，本申请不作具体限定。

可选地，该分析用户名单可记录有工作流信息，该工作流信息可包括多个处理节点，每个处理节点对应一个用户或用户组。一些异常数据可能需要多个分析用户给出分析意见之后才能完成风险分析，业务管理系统200在接收到上一个分析用户反馈的分析意见之后，按照用户配置的工作流，向下一个分析用户发送异常数据和上一个分析用户反馈的分析意见，以此类推，直至获得所有分析用户的分析意见之后，获得分析结果。

S530：第一客户端100A向业务管理系统200发送异常数据的分析结果，更新异常数据的分析状态为已分析。该步骤可由图1实施例中的风险分析单元260实现。业务管理系统200可对分析结果进行存储。

可选地，该分析结果可包括分析结论，分析结论包括存在风险和不存在风险，对于分析结论为存在风险的分析结果，还可包括前述内容中的第一风险指标，也就是风险等级、风险类型、风险原因、风险影响、风险负责人等指标中的一种或者多种。

可选地，该分析结果还可包括对异常数据的处理计划，通常情况下，分析结论为存在风险的异常数据包括处理计划，但是分析结论为不存在风险的异常数据可能不包括处理计划，这是因为该异常数据不存在风险，所以也不需要进行处理。但是一些不存在风险的异常数据可能也会拥有处理计划，这是因为异常数据虽然没有风险，但是异常数据可以为企业带来一些优化业务表现的提示，发现潜在的改进方针，所以分析结论为不存在风险的异常数据也可能包含处理计划。

应理解，分析结果还可包括更多内容，比如分析结果还可包括风险等级、风险类型、风险原因、风险影响、风险负责人等，业务管理系统200可根据分析结果可生成第一分析指标。

可选地，分析状态还可包括待复核和已复核，业务管理系统200还可以在S530获得异常数据的分析结果之后，将该分析结果发送给第一复核用户，获得复核结果。其中，复核结果包括同意和不同意。这里的第一复核用户可以是分析用户的主管，通过额外设置复核用户的方式可以进一步确保分析结果的准确度。具体实现中，分析用户名单可以记录分析用户和第一复核用户的对应关系，比如分析用户A的第一复核用户为主管B，分析用户C的第一复核用户为主管D，具体可根据实际的业务需求进行配置，本申请不作具体限定。

可选地，若分析结果中的分析结论为存在风险，或者，分析结果中的分析结果为不存在风险但分析结果包括处理计划，业务管理系统200可以将该异常数据的分析状态从已分析修改为待复核，然后将该异常数据和分析结果发送给第一复核用户，获得复核结果之后，若复核结果为同意，将分析状态修改为已复核；若复核结果为不同意，业务管理系统200将异常数据的分析状态修改为待分析，再按照分析用户名单将待分析的异常数据发送给客户端100进行风险分析。

可选地，若分析结果中的分析结论为不存在风险，且分析结果不包括处理计划，业务管理系统200可以将该异常数据的分析状态从已分析修改为待复核，然后将该异常数据和分析结果发送给第一复核用户，获得复核结果为同意后，不对该异常数据进行处理，具体可以将分析状态修改为已结束，或者将异常数据删除；若复核结果为不同意，风险分析单元260将异常数据的分析状态修改为待分析，再按照分析用户名单将待分析的异常数据发送给客户端100进行风险分析。

S540：业务管理系统200根据分析结果生成风险任务，更新风险任务的处理状态为待处理。该步骤可由图1实施例中的任务处理单元250实现。其中，处理状态存储于状态数据库2903中。

可选地，业务管理系统200可以将分析结论为存在风险的异常数据生成对应的风险任务。

可选地，业务管理系统200可以根据分析结果中的分析结论以及处理计划生成风险任务，具体的，可以将分析结论为不存在风险，但分析结果包括分析计划的异常数据生成对应的风险任务。

可选地，业务管理系统200可以不处理分析结论为不存在风险且不包括分析计划的异常数据，具体可以将该类异常数据的分析状态修改为已结束，或者直接将该异常数据删除，或者其他方式标识出该类异常数据不需要进行进一步的处理，本申请不做具体限定。

可选地，如果用户设置了复核用户，那么每个分析结果都需要进行复核，如果复核结果为不同意，那么将分析状态修改为待分析，重新进行分析，如果复核结果为同意，且分析结论为存在风险，或者不存在风险但拥有处理计划，此时可以生成风险任务。如果复核结果为同意，且分析结果为不存在风险且未拥有处理计划，此时可以不再异常数据进行处理，可以将异常数据删除，或者修改其分析状态为已结束。

具体实现中，业务管理系统200可以根据分析状态和分析结果，从多个异常数据中获取至少一个风险任务数据，然后根据至少一个风险任务数据生成一个或者多个风险任务。其中，风险任务数据包括分析状态为已复核，分析结论为存在风险的异常数据，还包括分析状态为已复核，分析结论为不存在风险但包括分析计划的异常数据。具体实现中，如果分析结论为不存在风险且不包括分析计划的异常数据，其分析状态为已结束，那么这里的风险任务数据也可以理解为状态为已复核的异常数据。

进一步地，N个风险任务数据可以生成M个风险任务，其中，N不等于M，应理解，在风险分析中，一些异常数据之间存在相关性，所以这些异常数据的解决方案也是相似的，为了提高任务处理效率，可以将这些存在相关性的异常数据合并到一个风险任务进行处理。业务管理系统200可以在获取到至少一个风险任务数据以后，根据风险任务数据的分析结果，将至少一个风险任务数据进行聚类，同一个类别的风险任务数据可以合并生成同一个风险任务。在聚类时，可结合分析结果中风险等级、风险类型、风险原因、风险影响、风险负责人等指标对风险任务数据进行聚类，比如将风险原因相似的风险任务数据进行合并生成一个风险任务，或者将处理计划相似的风险任务数据进行合并，或者将风险原因和处理计划均相似的风险任务数据进行合并生成一个风险任务，或者将风险负责人相同的风险任务数据进行合并生成一个风险任务，上述举例用于说明，本申请不作具体限定。

应理解，如果存在复核用户，分析状态包括待分析、分析中、已分析、待复核和已复核，该应用场景下业务管理系统200对于分析状态的维护过程较为复杂，为了使本申请能够被更好地理解，下面结合图6对于存在复核用户这一应用场景，对上述S510～S540进行进一步的解释说明。图6是本申请提供的一种应用场景下的风险任务生成方法的步骤流程示意图，如图6所示，存在复核用户时，业务管理系统200可以先执行S510～S530，然后执行图6所示的S531～S5314，最后执行S540即可生成风险任务。其中，S510～S530以及S540的描述可参考图5实施例的相关描述，这里不重复赘述，下面对S531～S5314进行解释说明。

S531：业务管理系统200确定异常数据的分析结论是否为存在风险。存在风险的情况下执行S532，不存在风险的情况下执行S536。该步骤可由图1实施例中的风险分析单元260实现。

参考前述内容可知，异常数据的分析结果包括分析结论，分析结论包括存在风险和不存在风险，对于存在风险的异常数据需要生成风险任务进行处理，对于不存在风险的异常数据需要进一步判定是否需要对其进行处理，因此存在风险的情况下执行S532，不存在风险的情况下执行S536。

S532：将异常数据的分析状态更新为待复核，将异常数据的分析结果发送给第三客户端。该步骤可由图1实施例中的风险分析单元260实现。

具体实现中，第三客户端是复核用户使用的客户端，复核用户的描述可参考前述实施例中的相关内容，这里不重复赘述。

S533：接收第三客户端返回的复核结果。该步骤可由图1实施例中的风险分析单元260实现。

S534：确定复核结果是否为同意。在同意的情况下执行S535，在不同意的情况下执行S5311。该步骤可由图1实施例中的风险分析单元260实现。

应理解，复核结果为同意则表示S531判定分析结论存在风险是正确的结论，所以需要执行S535进一步生成风险任务，复核结果为不同意则表示S531判定分析结论存在风险是错误的结论，所以需要执行S5311重新对该异常数据进行风险分析。

S535：更新异常数据的分析状态为已复核。该步骤可由图1实施例中的风险分析单元260实现。

应理解，分析状态为已复核的异常数据表示该异常数据存在风险，并且已被复核人确认过确实存在风险，所以分析状态为已复核的异常数据需要生成风险任务进行处理。

S536：确定异常数据的分析结果是否存在处理计划，在是的情况下执行S532，在否的情况下执行S537。该步骤可由图1实施例中的风险分析单元260实现。

参考前述内容可知，异常数据如果不存在风险，但是可以基于该异常数据来优化业务表现，此时异常数据的分析结果可能包括处理计划，因此对于不存在风险但是包含处理计划的异常数据可以与存在风险的异常数据一同执行S532，而对于不存在风险且不存在处理计划的异常数据需要执行S537。

S537：分析状态更新为待复核，将分析结果发送给第三客户端。S537与S532相同，这里不重复赘述。该步骤可由图1实施例中的风险分析单元260实现。

S538：接收第三客户端返回的复核结果。S538与S533相同，这里不重复赘述。该步骤可由图1实施例中的风险分析单元260实现。

S539：确定复核结果是否为同意。在同意的情况下执行S5310，在不同意的情况下执行S5311。该步骤可由图1实施例中的风险分析单元260实现。

S5310：更新异常数据的分析状态为已结束。该步骤可由图1实施例中的风险分析单元260实现。

应理解，在复核用户确认该异常数据不存在风险且不存在处理计划的情况下，可以不对该异常数据进行进一步地处理，所以可以将分析状态修改为已结束，或者将该异常数据删除，本申请不作具体限定。

S5311：更新异常数据的分析状态为待分析。该步骤可由图1实施例中的风险分析单元260实现。

应理解，无论异常数据是否存在风险，是否存在处理计划，都需要对分析结果进行复核，在复核用户的结论为不同意时，需要重新对该异常数据进行分析，所以执行S5311。

S5312：获取分析状态为已复核的多个异常数据。

参考前述内容可知，分析状态为已复核的异常数据是存在风险的异常数据，或者，不存在风险但是存在处理计划的异常数据。

S5313：根据多个异常数据的分析结果，对多个异常数据进行聚类。

具体实现中，可以根据分析结果中的风险等级、风险类型、风险原因、风险影响、风险负责人等指标对风险任务数据进行聚类，比如将风险原因相似的风险任务数据进行合并生成一个风险任务，或者将处理计划相似的风险任务数据进行合并，或者将风险原因和处理计划均相似的风险任务数据进行合并生成一个风险任务，或者将风险负责人相同的风险任务数据进行合并生成一个风险任务，上述举例用于说明，本申请不作具体限定。

S5314：获取每个类别对应的异常数据的分析结果。

进一步地，在获取到每个类别对应的异常数据的分析结果之后，可以执行S540生成每个类别对应的风险任务，其中，一个类别可以生成一个风险任务。应理解，一些异常数据之间存在相关性，所以这些异常数据的解决方案也是相似的，为了提高任务处理效率，可以将这些存在相关性的异常数据合并到一个风险任务进行处理。

应理解，通过S5310～S5311可以从异常数据中获取一部分存在风险的异常数据，以及不存在风险但存在处理计划的异常数据，然后通过S5312～S5314以及S540生成这部分异常数据对应的风险任务，并且一个风险任务可以对应一个或者多个异常数据，然后再执行S550～S580对风险任务进行处理。下面对风险任务的处理过程进行解释说明。

S550：业务管理系统200向第二客户端100B发送风险任务，更新风险任务的处理状态为处理中。该步骤可由图1实施例中的任务处理单元250实现。

可选地，业务管理系统200可包括处理用户名单，该处理用户名单可包括至少一个用于处理风险任务的用户或者用户组，业务管理系统200可以将风险任务发送给处理用户名单上记录的用户或者用户组，获得其返回的任务反馈。与上述分析用户名单类似的，该处理用户名单也可记录有每类风险任务对应的用户或者用户组，用户可根据自己的业务需求灵活配置处理用户名单，还可为处理用户名单上的各个用户设置优先级，还可以记录有工作流信息，该工作流信息可包括多个处理节点，每个处理节点对应一个处理用户或用户组。一些风险任务可能需要多个处理用户协同完成，业务管理系统200在接收到上一个处理用户的任务反馈之后，按照用户配置的工作流，向下一个处理用户发送风险任务以及其他用户的任务反馈，以此类推，直至按照工作流获得每个处理用户的任务反馈。

需要说明的，如果分析用户和处理用户是同一个用户，那么第一客户端100A和第二客户端100B可以是同一个客户端。如果分析用户和处理用户是不同的用户，那么第一客户端100A和第二客户端100B是不同的客户端。

S560：第二客户端100B向业务管理系统200发送任务反馈，业务管理系统200更新任务进展表。该步骤可由图1实施例中的任务处理单元250实现。

可选地，业务管理系统200可包括任务进展表，用于记录每个风险任务的处理进展，接收到任务反馈可以根据任务反馈对任务进展表进行更新，更新方式可以是覆盖更新，也可以是增量更新，具体可参考图1实施例的相关描述，这里不重复赘述。

S570：第二客户端100B向业务管理系统200发送任务关闭请求，业务管理系统200更新风险任务的处理状态为已处理。

可选地，处理状态还包括复核中，业务管理系统200在接收到第二客户端100B发送的任务关闭请求之后，可以将任务关闭请求发送给第二复核用户进行审核，修改处理状态为复核中，接收第二复核用户反馈的复核结果，在复核结果为同意的情况下，将风险任务的处理状态修改为已处理。在复核结果为不同意的情况下，不修改处理状态，向第二客户端100B发送审核不通过的提醒消息。

可选地，业务管理系统200可以接收第二客户端100B发送的任务延期请求，然后将任务延期请求发送给第二复核用户进行审核，同时修改处理状态为复核中，接收第二复核用户反馈的复核结果，在复核结果为同意的情况下，修改任务期限，同时修改处理状态为处理中。

可选地，业务管理系统200可以接收到第二客户端100B发送的转处理请求，然后将转处理请求发送给第二复核用户进行审核，同时修改处理状态为复核中，接收第二复核用户反馈的复核结果，在复核结果为同意的情况下，修改处理用户，同时修改处理状态为处理中。其中，处理任务延期请求、任务关闭请求、转处理请求的第二复核用户相同或者不同，具体可根据用户配置的处理用户名单确定，本申请不作具体限定。

简单来说，在复核结果为不同意的情况下，将处理状态修改为处理中，在复核结果为同意的情况下，按照用户发起的请求进行相应的处理后，将处理状态修改为处理中。应理解，上述处理用户名单包括处理用户和第二复核用户，这里的第二复核用户可以是处理用户的主管，负责复核处理用户发起的任务延期请求、任务关闭请求以及转处理请求。具体可根据实际的业务需求配置每个处理用户对应的第二复核用户，本申请不作具体限定。

S580：根据状态数据库2903中的分析状态和处理状态，更新指标数据库2902中的分析指标和处理指标。

可选地，状态数据库2903与指标数据库2902进行对接，业务管理系统200以根据状态数据库2903中的分析状态确定指标数据库2902中的分析指标。参考前述内容可知，分析指标包括用于描述分析结果的第一分析指标和用于描述分析进展的第二分析指标，第一分析指标可根据分析结果获得，也就是风险等级、风险类型、风险原因、风险影响、风险负责人等指标，第二分析指标包括可根据分析状态获得，比如第二分析指标可包括待分析的异常数据数量、分析中的异常数据数量以及已分析的异常数据数量等，本申请不作具体限定。

可选地，业务管理系统200可以根据状态数据库2903中的处理状态确定指标数据库2902中的处理指标。处理指标用于描述风险任务的处理进展，因此处理指标可包括待处理的风险任务数量、处理中的风险任务数量以及已处理的风险任务数量等，本申请不作具体限定。

可选地，业务管理系统200可以根据状态数据库2903中的处理状态、分析状态、分析结果以及一些其他财经风险指标确定指标数据库2902中的总览指标，具体可根据用户的业务需求计算出一些总览指标，比如异常数据总数、异常原因趋势、异常区域分布等，本申请不作具体限定。

可选地，指标数据库2902可以与看板数据库2901对接，看板数据库2901中的看板页面可包括风险分析区域、任务处理区域以及异常总览区域，其中，风险分析区域是根据用户的配置信息以及指标数据库2902中的分析指标获得的，任务处理区域是根据用户的配置信息以及指标数据库2902中的处理指标获得的，异常总览区域是根据用户的配置信息、分析指标、处理指标以及其他财经分析指标获得的，具体可参考前述关于看板页面的配置和生成描述，这里不再重复赘述。

应理解，通过上述S510～S580对分析状态和处理状态进行维护，可以使得看板页面上的分析指标和处理指标均为实时指标。用户接收到看板页面之后，可以根据看板页面中显示的指标，选择自己需要处理的分析任务或者风险任务，提交分析任务或者风险任务的处理结果之后，业务管理系统200可以实时更新分析状态或者处理状态，实时更新分析指标和处理指标，实时更新每个用户对应的看板页面，使得每个用户都可以及时获知风险分析进度和风险处理进度，避免风险延迟带来的财务危机。

为了使本申请能够被更好地理解，下面结合图7和图8对本申请提供的业务管理方法进行进一步地解释说明。图7和图8是本申请提供的一种示例性界面，该界面仅用于举例说明，本申请不作具体限定。

图7是本申请提供的业务管理方法中分析用户使用的一种界面示意图，该界面可以是分析用户登录后显示的界面之一，如图7所示，该界面可包括分析概览区域720、异常数据显示区域730以及分析操作控件740。

分析概览区域720可显示一些概览指标，比如不同类型下不同分析状态的异常数据的数量，风险分析的完成率等，图7示例性给出了赎期异常和币种异常两种风险类别下，不同来源、不同分析状态的异常数据的数量，应理解，图7用于举例说明，分析概览区域720还可以显示更多或者更少的内容，具体可根据实际的应用场景以及用户的配置来确定本申请不作具体限定。

进一步地，分析概览区域720可以向用户提示新增的待分析的异常数据，图7所示的界面中，待分析旁边的深色圆形提示框内的数字用于向用户提示新增的待分析的异常数据数量，比如赎期异常-应付账款类别下的待分析异常数据为6，旁边的深色圆形提示框内的数字为3，表示待分析的异常数据数量为6个，其中有3个是新增的待分析的异常数据，用户可以点待该类别，右侧的异常数据显示区域730即可显示如图7所示的内容。

异常数据显示区域730可显示用户选择的多个异常数据的各项信息，示例性的，图7所示的例子中，异常数据显示区域730显示了每个异常数据的日期、异常类型、异常规则号、来源系统、地区、赎期、币种、金额等信息，用户可点击每一条异常数据的操作栏中的分析处理选项，对异常数据进行异常分析。应理解，图7是一种举例，异常数据显示区域730还可以包括更多内容，比如还可以包括分析进展，用于展示异常数据的分析状态，包括已复核、待分析、待复核等等，还可显示是否逾期，比如在分析进展中的待分析下方中接显示1天后预期，已预期2天等等，上述举例用于说明，本申请不对异常数据显示区域730中具体的内容进行限定。

具体实现中，当用户点击分析处理选项后，风险分析系统可以执行S520，更新异常数据的状态信息为分析中。

进一步地，用户点击一条异常数据的分析处理选项之后，客户端100可以向用户显示如图8所示的界面，图8是本申请提供的业务管理方法中分析用户使用的另一种界面示意图，该界面可以是分析用户登录后显示的界面之一，其中，图7所示的界面是分析用户查看异常数据时的界面，图8所示的界面是分析用户提交分析结果时的界面，换句话说图7所示的界面对应前述内容中的S520，图8所示的界面对应前述内容中的S530。

如图8所示，该界面可包括工具栏810以及分析处理区域820，其中，分析处理区域820可进一步包括历史分析记录区域821以及风险分析区域822。

工具栏810可包括多个控件，不同的控件用于实现不同的功能，举例来说，图8中工具栏810中从上往下的第一个控件用于控制展开和收回分析概览区域720，应理解，图8当前显示的界面中分析概览区域720是收回状态，如果用户点击图8所示的第一个控件，可以重新展开图7所示的分析概览区域720。工具栏810中的第二个控件用于控制展开和收回右侧的分析处理区域820。应理解，工具栏810中的控件可根据用户的业务需求进行设置，本申请不作具体限定。

分析处理区域820可包括多个区域，各个区域可以根据用户的需求展开或者折叠，在图8所示的例子中，异常信息区域和历史分析结论区域被折叠，历史分析记录区域821以及风险分析区域822被展开。其中，历史分析记录区域821可包括分析用户的分析记录以及复核用户的复核记录，风险分析区域822可包括分析结果的多个选项，分析用户可以对这些选项进行选择和填充，点击确定控件823之后即可提交分析结果，业务管理系统200可以执行S530，更新历史分析记录区域821中的内容，并更新异常数据的状态信息为已分析。

参考前述内容可知，一个异常数据的风险分析可能需要多个分析用户参与。图8所示的例子中，分析用户A已经获得分析结论为存在风险，复核用户B也提交了复核结论为已同意，图8显示的界面可以是分析用户A在修改分析结论，也可以是分析用户C进一步丰富分析结果，比如提交风险类别、风险原因等，同时，分析用户C提交的分析结果也需要复核用户进行复核，分析用户C的复核用户也可以是复核用户B，还可以是复核用户D，本申请不作具体限定。

应理解，业务管理系统200根据分析用户提交的分析结果以及复核用户提交的复核结果更新异常数据的状态信息之后，可以执行S530、S531～S5314、S540，生成多个风险任务。同理，处理用户处理上述多个风险任务时，客户端100可以向处理用户显示类似图7的界面，向处理用户展示不同处理状态下的处理任务数量，处理用户选择待处理的处理任务后，通过点击操作控件，弹出类似图8所示的任务处理结果提交界面，提交处理结果之后，业务管理系统200可以执行S560～S580。

进一步地，处理用户还可以提交一些任务延期请求、转处理请求、任务关闭请求等，这些请求都需要复核用户进行复核，处理用户发起请求以及复核用户的复核结果都可以记录在历史处理记录中，具体可参考图8中历史分析记录区域821，这里不再举例说明。

综上可知，本申请提供了一种业务管理方法，该方法通过接收用户发起的看板请求，根据看板请求携带的用户角色，获取该用户角色对应的看板页面，该看板页面包括风险分析区域和任务处理区域，风险分析区域用于向用户展示用于描述异常数据的风险分析情况的分析指标，该分析指标是根据异常数据的分析状态生成的，任务处理区域用于向用户展示用于描述风险任务的处理进展的处理指标，该处理指标是根据风险任务的处理状态生成的，风险任务是业务管理系统根据异常数据的分析结果生成的，使用该方法向用户展示的页面不仅显示有对异常数据的风险分析的情况，还显示任务处理的情况，并且该风险分析情况和风险处理情况是根据分析状态和处理状态确定的，也就是实时的处理情况，这样风险管理不再依赖于人工汇报，使得风险管理能够更加全面和及时；同时通过分区显示分析指标和处理指标，使得看板页面重点突出，复杂的指标也易于理解和解读，提高用户的数据洞察力和决策效果，还可以根据用户角色来设置每个区域内显示的分析指标和处理指标，不同角色显示的指标类型不同，满足财经管理中不同用户角色(比如管理者和一线人员)的使用需求，因此，通过本申请提供的业务管理方法，企业财经可以更加及时、高效的进行风险管理。

上文中结合图2至图8，详细描述了根据本申请所提供的业务管理方法，下面将结合图9，描述根据本申请所提供的计算设备。

图9是本申请提供的一种计算设备的结构示意图，该计算设备900可以是前述内容中的业务管理系统。进一步地，计算设备900包括处理器901、存储单元902、存储介质903和通信接口904，其中，处理器901、存储单元902、存储介质903和通信接口904通过总线905进行通信，也通过无线传输等其他手段实现通信。

处理器901由多个通用处理器构成，例如CPU。上述硬件芯片是专用集成电路(application-specific integrated circuit,ASIC)、编程逻辑器件(programmablelogic device,PLD)或其组合。上述PLD是复杂编程逻辑器件(complex programmablelogic device,CPLD)、现场编程逻辑门阵列(field-programmable gate array,FPGA)、通用阵列逻辑(generic array logic,GAL)、数据处理单元(data processing unit,DPU)、片上系统(system on chip,SoC)或其任意组合。处理器901执行各种类型的数字存储指令，例如存储在存储单元902中的软件或者固件程序，它能使计算设备900提供较宽的多种服务。

具体实现中，作为一种实施例，处理器901包括一个或多个CPU，例如图9中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，计算设备900也包括多个处理器，例如图9中所示的处理器901和处理器906。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

存储单元902用于存储程序代码，并由处理器901来控制执行，以执行上述图1-图8任一实施例中业务管理方法的处理步骤。程序代码中包括一个或多个软件单元。上述一个或者多个软件单元是图1实施例中的配置单元、看板获取单元、角色识别单元、看板发送单元、任务处理单元、风险分析单元、数据获取单元以及同步单元，其中，配置单元用于获取客户端发送的用户输入的配置信息，根据配置信息生成元数据信息、根据元数据信息获得页面的低代码配置，基于低代码开发平台生成低代码配置对应的看板页面，具体可用于实现图2实施例中的S210～S240及其可选步骤。看板获取单元用于接收客户端发送的看板获取请求，具体用于实现图2实施例中的S250及其可选步骤，角色识别单元用于获取用户角色对应的看板页面，具体用于实现图2实施例中的S260及其可选步骤，看板发送单元用于向客户端发送用户角色对应的看板页面，具体用于实现图2实施例中的S270及其可选步骤。数据获取单元用于获取异常数据，更新异常数据的分析状态为待分析，具体用于实现图5实施例中的S510及其可选步骤。风险分析单元用于向第一客户端发送待分析的异常数据，更新异常数据的状态信息为分析中，接收客户端返回的异常数据的分析结果，更新异常数据的状态信息为已分析，具体用于实现图5实施例中的S520、S530、图6实施例中的S531～S5314及其可选步骤。任务处理单元用于根据分析结果生成风险任务，更新风险任务的处理状态为待处理，向客户端发送风险任务，更新风险任务的处理状态为处理中，接收客户端发送的任务反馈，更新任务进展表，接收客户端发送的任务关闭请求，更新风险任务的处理状态为已处理，具体用于实现图5实施例中的S540～S570。同步单元用于根据状态数据库中的分析状态和处理状态，更新指标数据库中的分析指标和处理指标，具体用于实现图5实施例中的S580。

存储单元902包括只读存储器和随机存取存储器，并向处理器901提供指令和数据。存储单元902还包括非易失性随机存取存储器。存储单元902是易失性存储器或非易失性存储器，或包括易失性和非易失性存储器两者。其中，非易失性存储器是只读存储器(read-only memory,ROM)、编程只读存储器(programmable ROM,PROM)、擦除编程只读存储器(erasable PROM,EPROM)、电擦除编程只读存储器(electrically EPROM,EEPROM)或闪存。易失性存储器是随机存取存储器(random access memory,RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM用，例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic random access memory,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(doubledatadate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM,ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。还是硬盘(hard disk)、U盘(universal serial bus，USB)、闪存(flash)、SD卡(secure digital memory Card,SD card)、记忆棒等等，硬盘是硬盘驱动器(hard disk drive,HDD)、固态硬盘(solid state disk,SSD)、机械硬盘(mechanicalhard disk,HDD)等，本申请不作具体限定。

存储介质903是存储数据的载体，比如硬盘(hard disk)、U盘(universal serialbus，USB)、闪存(flash)、SD卡(secure digital memory Card,SD card)、记忆棒等等，硬盘可以是硬盘驱动器(hard disk drive,HDD)、固态硬盘(solid state disk,SSD)、机械硬盘(mechanical hard disk,HDD)等，本申请不作具体限定。

通信接口904为有线接口(例如以太网接口)，为内部接口(例如高速串行计算机扩展总线(Peripheral Component Interconnect express,PCIe)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他服务器或单元进行通信。

总线905是快捷外围部件互联标准(Peripheral Component InterconnectExpress，PCIe)总线，或扩展工业标准结构(extended industry standard architecture，EISA)总线、统一总线(unified bus，Ubus或UB)、计算机快速链接(compute express link，CXL)、缓存一致互联协议(cache coherent interconnect for accelerators，CCIX)等。总线905分为地址总线、数据总线、控制总线等。

总线905除包括数据总线之外，还包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线905。

需要说明的，图9仅仅是本申请实施例的一种可能的实现方式，实际应用中，计算设备900还可以包括更多或更少的部件，这里不作限制。关于本申请实施例中未示出或未描述的内容，可参见前述图1-图8实施例中的相关阐述，这里不再赘述。

本申请实施例还提供了一种计算设备集群，该计算设备集群可以是前述内容中的业务管理系统，该计算设备集群包括至少一个计算设备900。计算设备集群中的一个或多个计算设备900中的存储单元902中可以存有相同或者不同的用于执行业务管理方法的指令。

本申请实施例还提供了一种包含指令的计算机程序产品。计算机程序产品可以是包含指令的，能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品。当计算机程序产品在至少一个计算设备上运行时，使得至少一个计算设备执行业务管理方法。

本申请实施例还提供了一种计算机可读存储介质。计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc,DVD))、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令，指令指示计算设备执行业务管理方法。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括多个计算机指令。在计算机上加载或执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修复或替换，这些修复或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (24)

1.一种业务管理方法，其特征在于，所述方法包括：

业务管理系统接收第一用户发起的看板获取请求；

获取所述第一用户对应的看板页面，其中，所述看板页面包括风险分析区域以及任务处理区域，所述风险分析区域包括分析指标，所述分析指标用于描述分析任务的处理情况，所述分析指标是根据所述分析任务的分析状态生成的，所述分析任务包括对异常数据进行风险分析，所述任务处理区域包括处理指标，所述处理指标用于描述风险任务的处理情况，所述处理指标是根据所述风险任务的处理状态生成的，所述风险任务是所述业务管理系统根据所述分析任务的分析结果生成的；

向所述第一用户发送所述第一用户对应的看板页面。

2.根据权利要求1所述的方法，其特征在于，所述向所述第一用户发送所述第一用户对应的看板页面之后，所述方法还包括：

所述业务管理系统接收所述第一用户发起的第一任务的处理请求，所述处理请求是所述第一用户点击所述看板页面触发的，所述第一任务是所述分析任务或者所述风险任务；

所述业务管理系统向所述第一用户发送所述第一任务，接收所述第一用户反馈的处理结果；

所述业务管理系统更新所述看板页面中的所述分析指标或者所述处理指标。

3.根据权利要求2所述的方法，其特征在于，所述业务管理系统包括状态数据库，所述状态数据库包括多个分析任务的分析状态和多个风险任务的处理状态；所述获取所述第一用户对应的看板页面包括：

所述业务管理系统从所述状态数据库中获取每个分析状态下的分析任务数量，确定所述分析指标，其中，所述分析指标包括不同分析状态的分析任务数量，所述分析状态包括待分析、分析中和已分析；

从所述状态数据库中获取每个处理状态下的风险任务数量，确定所述处理指标，其中，所述处理指标包括不同处理状态的风险任务数量，所述处理状态包括待处理、处理中和已处理；

基于所述分析指标和所述处理指标生成所述看板页面。

4.根据权利要求1至3任一权利要求所述的方法，其特征在于，所述方法还包括：

所述业务管理系统接收第二用户发起的看板获取请求，所述第二用户的用户角色与所述第一用户的用户角色不同；

获取所述第二用户对应的看板页面，其中，所述第一用户对应的看板页面中显示的分析指标和处理指标所属的范围与所述第二用户对应的看板页面中显示的分析指标和处理指标所属的范围不同，所述范围包括时间范围和区域范围，所述第一用户对应的看板页面中的分析指标种类与所述第二用户对应的看板页面中的分析指标种类不同；

向所述第二用户发送所述第二用户对应的看板页面。

5.根据权利要求1至4任一权利要求所述的方法，其特征在于，所述业务管理系统接收第一用户发起的看板获取请求之前，所述方法还包括：

所述业务管理系统接收第三用户发送的配置信息，所述配置信息包括指标配置信息、外观配置信息以及用户角色信息，所述指标配置信息包括用户需求在所述风险分析区域以及所述任务处理区域显示的指标，所述外观配置信息用于描述所述看板页面的视觉设计效果，所述外观配置信息包括所述看板页面的布局信息和交互逻辑信息；

根据所述配置信息生成元数据信息，所述元数据信息用于描述所述用户请求配置的看板页面；

根据所述元数据信息获得页面的低代码配置，所述低代码配置是基于低代码开发平台提供的配置选项生成的；

基于所述低代码开发平台生成所述低代码配置对应的看板页面，记录所述看板页面对应的用户角色。

6.根据权利要求1至5任一权利要求所述的方法，其特征在于，所述分析指标还包括所述分析任务的分析结果，所述分析结果包括风险等级、风险类型、风险原因、风险影响、风险负责人中的一种或者多种。

7.根据权利要求3至6任一权利要求所述的方法，其特征在于，所述方法还包括：

所述业务管理系统获取第一异常数据，将所述第一异常数据对应的第一分析任务的分析状态修改为待分析；

向分析用户发送所述第一异常数据，将所述第一分析任务的分析状态修改为分析中；

接收所述分析用户反馈的分析结果，将所述第一分析任务的分析状态修改为已分析。

8.根据权利要求7所述的方法，其特征在于，所述分析状态还包括待复核，所述接收所述分析用户反馈的分析结果，将所述第一分析任务的分析状态修改为已分析之后，所述方法还包括：

所述业务管理系统将所述分析结果发送给复核用户，将所述第一分析任务的分析状态修改为待复核；

接收所述复核用户反馈的复核结果，在所述复核结果为同意的情况下将所述第一分析任务的分析状态修改为已复核，在所述复核结果为不同意的情况下将所述第一分析任务的分析状态修改为待分析。

9.根据权利要求8所述的方法，其特征在于，所述分析结果包括存在风险和不存在风险，所述风险任务是根据分析状态为已复核且分析结果为存在风险的分析任务生成的。

10.根据权利要求8或9所述的方法，其特征在于，所述方法还包括：

所述业务管理系统接收所述分析用户反馈的处理计划，所述风险任务是根据分析状态为已复核、分析结果为不存在风险且包括处理计划的分析任务生成的。

11.根据权利要求3至10任一权利要求所述的方法，其特征在于，所述方法还包括：

所述业务管理系统获取第一处理任务，将所述第一处理任务的处理状态修改为待处理；

向处理用户发送所述第一处理任务，将所述第一处理任务的处理状态修改为处理中；

接收并记录所述处理用户发送的任务反馈；

接收所述处理用户发送的任务关闭请求，将所述第一处理任务的处理状态修改为已处理。

12.一种业务管理系统，其特征在于，所述系统包括：

看板获取单元，用于接收第一用户发起的看板获取请求；

角色识别单元，用于获取所述第一用户对应的看板页面，其中，所述看板页面包括风险分析区域以及任务处理区域，所述风险分析区域包括分析指标，所述分析指标用于描述分析任务的处理情况，所述分析指标是根据所述分析任务的分析状态生成的，所述分析任务包括对异常数据进行风险分析，所述任务处理区域包括处理指标，所述处理指标用于描述风险任务的处理情况，所述处理指标是根据所述风险任务的处理状态生成的，所述风险任务是所述业务管理系统根据所述分析任务的分析结果生成的；

看板发送单元，用于向所述第一用户发送所述第一用户对应的看板页面。

13.根据权利要求12所述的系统，其特征在于，所述系统还包括同步单元，

所述看板获取单元还用于，接收所述第一用户发起的第一任务的处理请求，所述处理请求是所述第一用户点击所述看板页面触发的，所述第一任务是所述分析任务或者所述风险任务；

所述看板发送单元还用于，向所述第一用户发送所述第一任务，接收所述第一用户反馈的处理结果；

所述同步单元用于更新所述看板页面中的所述分析指标或者所述处理指标。

14.根据权利要求13所述的系统，其特征在于，所述业务管理系统包括状态数据库，所述状态数据库包括多个分析任务的分析状态和多个风险任务的处理状态，

所述角色识别单元，用于从所述状态数据库中获取每个分析状态下的分析任务数量，确定所述分析指标，其中，所述分析指标包括不同分析状态的分析任务数量，所述分析状态包括待分析、分析中和已分析；

所述角色识别单元，用于从所述状态数据库中获取每个处理状态下的风险任务数量，确定所述处理指标，其中，所述处理指标包括不同处理状态的风险任务数量，所述处理状态包括待处理、处理中和已处理；

所述角色识别单元，用于基于所述分析指标和所述处理指标生成所述看板页面。

15.根据权利要求12至14任一权利要求所述的系统，其特征在于，

所述看板获取单元，还用于接收第二用户发起的看板获取请求，所述第二用户的用户角色与所述第一用户的用户角色不同；

所述角色识别单元，还用于获取所述第二用户对应的看板页面，其中，所述第一用户对应的看板页面中显示的分析指标和处理指标所属的范围与所述第二用户对应的看板页面中显示的分析指标和处理指标所属的范围不同，所述范围包括时间范围和区域范围，所述第一用户对应的看板页面中的分析指标种类与所述第二用户对应的看板页面中的分析指标种类不同；

所述看板发送单元，用于向所述第二用户发送所述第二用户对应的看板页面。

16.根据权利要求12至15任一权利要求所述的系统，其特征在于，所述系统包括配置单元，

所述配置单元，用于接收第三用户发送的配置信息，所述配置信息包括指标配置信息、外观配置信息以及用户角色信息，所述指标配置信息包括用户需求在所述风险分析区域以及所述任务处理区域显示的指标，所述外观配置信息用于描述所述看板页面的视觉设计效果，所述外观配置信息包括所述看板页面的布局信息和交互逻辑信息；

所述配置单元，用于根据所述配置信息生成元数据信息，所述元数据信息用于描述所述用户请求配置的看板页面；

所述配置单元，用于根据所述元数据信息获得页面的低代码配置，所述低代码配置是基于低代码开发平台提供的配置选项生成的；

所述配置单元，用于基于所述低代码开发平台生成所述低代码配置对应的看板页面，记录所述看板页面对应的用户角色。

17.根据权利要求12至16任一权利要求所述的系统，其特征在于，所述分析指标还包括所述分析任务的分析结果，所述分析结果包括风险等级、风险类型、风险原因、风险影响、风险负责人中的一种或者多种。

18.根据权利要求14至17任一权利要求所述的系统，其特征在于，所述系统包括数据获取单元和风险分析单元，所述数据获取单元用于获取第一异常数据，所述风险分析单元用于将所述第一异常数据的分析状态修改为待分析；

所述风险分析单元用于向分析用户发送所述第一异常数据，将所述第一异常数据的分析状态修改为分析中；

所述风险分析单元用于接收所述分析用户反馈的分析结果，将所述第一异常数据的分析状态修改为已分析。

19.根据权利要求18所述的系统，其特征在于，所述分析状态还包括待复核，

所述风险分析单元还用于将所述分析结果发送给复核用户，将所述第一分析任务的分析状态修改为待复核；

所述风险分析单元还用于接收所述复核用户反馈的复核结果，在所述复核结果为同意的情况下将所述第一分析任务的分析状态修改为已复核，在所述复核结果为不同意的情况下将所述第一分析任务的分析状态修改为待分析。

20.根据权利要求19所述的系统，其特征在于，所述分析结果包括存在风险和不存在风险，所述风险任务是根据分析状态为已复核且分析结果为存在风险的分析任务生成的。

21.根据权利要求19或20所述的系统，其特征在于，所述风险分析单元还用于接收所述分析用户反馈的处理计划，所述风险任务是根据分析状态为已复核、分析结果为不存在风险且包括处理计划的分析任务生成的。

22.根据权利要求14至21任一权利要求所述的系统，所述系统还包括任务处理单元，

所述任务处理单元用于获取第一处理任务，将所述第一处理任务的处理状态修改为待处理；

所述任务处理单元用于向处理用户发送所述第一处理任务，将所述第一处理任务的处理状态修改为处理中；

所述任务处理单元用于接收并记录所述处理用户发送的任务反馈；

所述任务处理单元用于接收所述处理用户发送的任务关闭请求，将所述第一处理任务的处理状态修改为已处理。

23.一种计算设备，其特征在于，所述计算设备包括处理器和存储器，所述存储器用于存储指令，所述处理器用于执行所述指令，以使得所述计算设备实现如权利要求1至11任一权利要求所述的方法。

24.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，所述指令被计算设备或者计算设备集群运行时实现如权利要求1至11任一权利要求所述的方法。