CN103870914A - 具有预定义警告的业务管理*** - Google Patents

Abstract

本发明涉及一种具有预定义警告的业务管理***，其中揭露一种包括有预定义警告(alert)及报告(report)的用于管理消费者金融服务业务的***及方法。本***包括数据库模块，具有维度表(dimension table)及事实表(fact table)，经结构化用以包含消费者金融服务业务相关的资料。预定义警报模块针对消费者金融服务业务重要性状况警告使用者、以及报告模块，连结至数据库模块。本方法预定义业务警告条件以识别消费者金融服务业务信息中特定使用者所需信息有关的警告状况。

Description

具有预定义警告的业务管理***

技术领域

本申请案基本上涉及业务管理***(business management system)的领域，并且更明确地涉及以自动化报告与早期预警警告功能提供业务智能、分析的业务管理***。

背景技术

业务管理***已变得普遍无所不在。虽然此些***可专门用于给定产业，如特别针对制造工厂的解决方案、或针对诸如炼油厂等营运的制造导向***之类，一般的管理***实际上仍存在于各式各样的公司，包括消费者银行(banking)、金融服务(financial service)、保险、以及电信企业。

许多管理***尝试处理整体企业范围出现的问题。此些诸如德国沃尔道夫(Waldorf)的思爱普(SAP)AG所生产并且贩售的***提供具有可客制化模块的核心功能。此些***需要具扩充性、并且昂贵的客制化作业以使其适用于特殊产业，更何况是特定公司。在客制化程序结束时，公司可具有功能相当大的***，但在那程序中可损失弹性。此外，为「标准」公司设计***基本功能的事实，必定对特定产业限制此些***的适用性。

本技术为了达到总体解决方案，已试图通过将专用较小型***接合(piece)在一起以解决这些问题。然而，此些***之间的接口(interface)经常显示比理论所提实际更多的问题。现代商务企业(business enterprise)的非常复杂性经常造成提供结合普遍性(broadly-based)管理***能力(power)与特定产业解决方案弹性的解决方案尝试失败。

因此，特定产业领域专用业务管理***仍有广泛的需求。

发明内容

本发明的一个态样是用于管理消费者金融服务业务的业务管理***。本管理***包括数据库模块、警告模块、以及报告模块。数据库模块包括两种表格，维度表(dimension table)、以及事实表(facttable)。维度表经结构化(structured)以包含包括有特定产品维度表、维度表、雪花维度表(snowflake dimension table)、以及静态维度表在内与消费者金融服务业务有关的资料。事实表也经结构化以包含包括有申请状态表(application status table)、申请表、每日帐户交易快照表(snapshot table)、以及帐户交易快照汇总表(aggregatetable)在内与消费者金融服务业务有关的资料。本揭示还包括经预定义用以针对消费者金融服务业务重要性状况警告使用者的警告模块、以及经预定义用以报告消费者金融服务业务重要性状状况的报告模块。

本揭示的进一步态样是为了管理消费者金融服务业务用于在操作业务管理***中产生警告的方法。本方法包括预定义业务警告条件，包括识别使用者角色，连同使用者在此些角色中所需的关键信息；识别与该关键信息相关连的产品类别；识别与关键信息相关连的技术主题；以及识别与关键信息有关的警告状况。在操作***期间，警告产生方法监控***以判断是否符合任何警告条件。一旦发现有警告状况符合，***激活相应预定义以通知使用者。依据来自使用者的要求，***产生与警告连结的报告。

附图说明

下文所述的图式提出并且描述本揭示的许多示例性具体实施例。在图式中，相称的组件符号意指等同或功能类似的组件。图式在本质上用于描述并且未依照比例绘制。

图1为描述本揭示***总体结构的方块图；

图2为描述本揭示***具体实施例的资料流的流程图式；

图3为描述本揭示某些具体实施例中所使用维度表数据结构的图式；

图4为描述本揭示某些具体实施例中所使用事实表数据结构的图式；

图5为本揭示某些具体实施例中所使用警告定义及激活所用程序的流程图；

图6至图9为描述本揭示警告子***特征的屏幕截图(screenshot)；以及

图10至图15为描述本揭示报告子***特征的屏幕截图。

主要组件符号说明

具体实施方式

搭配图式说明下文的实施方式。示例性具体实施例经说明用以描述所附权利要求书所定义本揭示的技术主题，而非限制其范畴。

概述

本揭示提出得以对特定环境轻易客制化的业务管理***，其包括识别并且预定义警告的能力，还有连结警告的报告。于第一层，对业务内的特定角色配置警告及报告。在给定角色的范畴内，可接着更具体地将警告/报告连系于(tie to)总体业务的特定产品或子集。接着，可提出给定警告的特定主题，还有触发警告产生的特定条件。警告仅提供特定状况已出现的通知；将警告连结到报告，让使用者轻易地深度探讨至以恰好期望粒度(granularity)理解警告所需细节的程度。

支持本揭示***的数据结构以资料仓库(data warehouse)的方式予以列置，包括维度表及事实表。维度表包含藉以衡量业务活动的属性，而事实表则包含有关于那些维度的特定信息。

本揭示按照银行企业呈现本揭示的示例性具体实施例。因此，利用本文所述***的组织的总体公司结构可包括数个分支银行。此一组织的其它态样可延伸至区域总部或综合设施(aggregating facility)、以及中央总部，其中，总体公司资料遭到编制(compile)。将理解的是，此银行***的用途本质上完全属示例性。本文所提出的原理适用于许多产业，并且所属领域的技术人员将了解对其它产业领域应用本文所述一般原理的便利性。

示例性具体实施例

***运作

图1根据本揭示的某些具体实施例描述包括有业务平台200的业务管理***100。基本上，业务管理***100围绕来源数据库102而置。数据库可以是大型企业规模数据库或资料仓库***，其示例包括诸如SQL Server DB、DB2、Oracle DB、Datastage、ODI、Informatica、Cognos、Oracle BI之类。此些***一般经结构化用以接受资料要素(data element)所组成的接口文件，资料要素依次将由消费者银行及金融服务用户经由其直接来自原始来源的资料所提供。因此，销售资料可流自如分支银行之类的来源，其可依次从诸如个人银行、商业银行、贷款等银行内的特定商业区接收资料。此外，区域性或更高层总部可从全然不同的营运单位接收资料。因此，向区域中心报告的实体(entity)可包括分支银行、抵押贷款经纪人(mortgage broker)、抵押贷款发行人(mortgage initiator)、以及***发行人。

接口层104可位于来源数据库102与业务平台200之间。此模块为使用者加载来源资料成功能更直接的格式，其有助于产生某些报告类型。应注意的是，接口层104可采取许多形式并且予以置于许多地方，下文有更详细的说明。

业务平台200体现本揭示的教示。主要组件包括产品数据库110及报告/警告模块122。本技术中普遍理解的是，透过撷取、转换、并且装载(load)资料的程序将资料加载资料仓库***内。程序在一般称为ETL模块的模块中运作。在此，输入资料的通用格式及待装载资料的所需形式为已知的，并且ETL模块进行任何所需转换。此些模块在本技术中为众所周知的并且将不在本文多作说明。

产品数据库110将资料储存在暂存区(staging area)112及资料市集(data mart)114。一旦如资料映像文件所指定而准备来源资料，即通过来源***将资料推向接口层104。资料若予以提供如来源档，则其通过业务平台200予以读取并且装载到接口层104内的接口表，之后，在暂存区112中完成数据处理及数据的计算。然后将资料装载到资料市集(DataMart)114，应用程序(application)从资料市集114抓取资料以供报告及产生警告。产品数据库110处理暂存区112内的资料并且将资料储存在资料市集114内。实现这些模块的设备在本技术中为已知的，如数据库（例如DB2、SQL Server DB或Oracle Database）、ETL工具（例如Datastage、ODI、或Informatica）、以及BI工具（OBIEE或Congnos）的组合。下文详述产品数据库110内所承载资料的结构。

报告/警告模块122包括报告工具120及报告/警告模块122。尽管在此可使用许多可行的结构，图式中所示的较佳结构仍使用产生报告格式及内容用的模块，耦接至用于储存预产生报告以供快速传播的装置。将轻易理解的是，报告及警告的规划需要仔细分析商务企业。此处的重要工作是判断经理人及其团队在管理业务的过程中需要什么样的信息。由于每一种业务情境都不同，因此此处没有可行的先验规则(priori rule)。即使在同一家公司内，不同的部门或营运单位所需的信息仍很可能不一样。然而，可注意到的是，有经验且技巧熟练的经理人理解其信息需求，并且那些需求可为报告工具120的输入。就那点而言，报告工具120可由产品数据库110查找(locate)所需资料。经配置使用团队知识和技巧以特定形式显示资料的报告，在报告/警告模块122内可维持网要形式(skeleton form)。由于这些报告绕过报告定义及建立步骤，因此其可非常快速地予以提出。

报告及警告有非常密切的关连性。报告是经由选择及格式化用以协助经理人了解业务情境的资料采集。警告也与经理人所需业务信息有关，但警告仅基于预定义准则传达问题存在的通知。其作用为早期预警触发予经理人。相反地，***所指定区域中警告的缺乏，意味着那区域有正业务成长或改善而对于那态样没有早期预警。因此，事件的自然发展将要求***分派警告给经理人，经理人接着如报告中所含请求更多细节。为了易于产生及存取，本揭示在报告/警告模块122这单一模块内结合报告及警告功能。

图2详述以上说明，聚焦在进入业务平台200内的资料流。如上所述，资料从来源数据库102开始流经资料撷取、转换、以及装载处的ETL模块104。如此处所示，ETL程序包括供校对(collation)101、预确认(pre-validation)103、以及确认105用的模块。数据必需基于所提供的变量列表(variable list)予以推向临时暂存区(interimstaging area)，其接着通过校对引擎予以拉取(pull)。开始时，资料基于经理人的需求予以分类而校对，如业务平台200的结构所反映，而非来源数据库102中找到的来源导向结构。重点在于来源资料将最有可能源自许多位置，如来源S1、S2、S3、以及S4所示。例如，来源可为不同分支银行位置、或各个营运位置内的不同事业单位。来源数据库102内所包含的资料可改变格式、组织、以及技术主题，并且资料校对引擎101将资料组成逻辑相关单元以供加载业务平台200。

还有，校对引擎101可执行特定计算。源自不同来源的资料透过APIs（应用程序接口）予以采集。API’s执行的功能连系于业务平台200的需求、以及尤其是那***的资料辞典(data dictionary)（图未示）。如初始计量(initial measure)，这需要将资料从资料来源映像至资料辞典。直接可得的资料可予以直接装载至暂存区（图1），但来自多重***的资料可需要通过合适的计算算法处理以符合资料辞典。将理解的是，一旦已知来源资料与业务平台200两者的细节，此些计算为所属领域的技术人员所知的技巧。

例如，在许多情境中，可用许多不同格式表达来源数据库102内所包含的资料。校对引擎101可存取需予以转换成帐户级月资料(account level monthly data)的各种日交易资料。例如，就简单的范例而言，工具可查阅(look up)帐户在这个月内的付款并且予以加总为帐户的月付款。资料可以Excel文件、或文字文件的形式、或任何其它格式送达校对引擎101。校对引擎可进行的一项任务是将那些档案转换成供进一步处理而选用的格式。

来自来源数据库102的资料在来源数据库102收到资料时即尽快地予以推向校对引擎101，或可予以拉取–也就是，用于周期性处理，或在资料已累积特定量时处理。资料结合于复合预确认档以供进一步处理。所属领域具有普通技术的人员可了解并且实现这些及其它变化。

预确认模块103经由资料辞典执行经校对资料。如所知，那程序确保资料匹配给定的限制条件集合。可酌情识别错误讯息。

确认引擎105检验资料以确保供加载业务平台200的内容及格式正确。在此，若遇到问题，则引擎拒绝整个档案，将有问题的个别记录加载特殊档案供使用者存取，突显造成拒绝的要素。使用者在所有记录校正时可接着再次推进(push)整个档案。可产生拒绝报告以识别需要校正的数据项。

接口层104从校对引擎101、预确认模块103、以及确认引擎105接收资料，并且其持有那资料供加载业务平台200。那装载运作可按诸如每日、每周、或每月等计划出现，或其可在接口层104中累积到所选资料量时出现。

资料备妥时，将其加载业务平台200内，并且特别是加载产品数据库110内。在那儿，首先对暂存区(stage area)112并且接着对资料市集114（图1）处理资料。每次进行交谈(session)以填充暂存区表格时，首先移除或删减表格内的先前资料，并且接着***新的记录集合。首先从各自的资料源读取资料，然后全部计算并且转换，其接着予以装载至各自的事实及维度表。在加载市集维度表时，对每一个唯一记录产生键值(key)，接着在适用并且装载于各自事实表的维度上查找事实表。装载总是以***完成。接着由事实表建立汇总表。资料仓库的那些要素两者的运作为本技术广为人知而无需在此进一步说明。

数据结构

产品数据库110将资料存成两种表格–维度表300及事实表400。维度藉以衡量(measure)业务的属性（衡量为其价值由使用者予以分析的所计算资料变量），且维度应隔离资料集合至非重叠区域。维度是那些可用以分割(segment)衡量的参数）。例如，在分支银行所收取收益(revenue)组成的资料集合中，有用的维度可为分点位置、日期、收益、金额、以及业务系列(line)。那些维度每一个都操作用以将资料集合切成（“slice and dice＂into）分离、非重叠性要素。然而，事实表400包含业务程序的衡量(measurements)、或度量(metrics)。例如，「$12,000」是事实，并且那事实可落在标示「收益」的维度的类别下。一般而言，多重事实及维度经汇总，以致事实表可包含如「2012年11月20日第16街分行的收益$12,000。」的入口(entry)。

图3所细述的维度300普遍分成四类：特定产品维度302、共通维度(common dimensions)304、雪花维度(snowflake dimensions)306、以及静态维度308。特定产品维度302尤指产品线，如汽车贷款产品维度302a、***产品维度302b、房贷维度302c、个人金融维度302d等等。这些维度各尤指特定类型的产品。例如，***维度302b类别下搭载(carry)的维度举例可为「卡类」、「信贷限额」等等。任何数量的产品式维度可取决于业务结构而予以新增。然而，以管理IP为基础的报告和警告的基本集合使本技术立即有用且有生产性。

共通维度304横跨许多产品类别。例如，「分行」304a将为给定分行所贩售所有产品的维度，其本身不附属于任何个别产品。

雪花维度306是仅持有(hold)来自其它维度表的键值信息(keyinformation)的维度。一此种维度可持有例如来自特定产品表「汽车经销商(Auto_Dealer)」、「汽车型号(Auto_Model)」、以及「汽车贷款种类(Auto_LoanType)」的键值信息。共通雪花维度306a，应用于所有产品，以及产品雪花维度306b，仅用于特定产品。

静态维度308经由.CVS档案类型的静态文件予以装载，其特征为通过逗号、栏标(tab)、段落符号、或诸如此类字符定界(delimit)。例如，维度「年龄范围(Age Band)」属静态维度。

图4描述事实表400的详细结构。所属领域的人员将理解的是，事实表可在各种应用中采取许多形式，从而可使用有别于此处所示的结构。如上所示，本揭示的范例聚焦于银行应用，并且那取向反映在事实表400的细节结构中。

如此处所结构化，事实表400通过产品予以组织，以致于每一项产品都有四个事实表：申请表、申请状态表、每日帐户交易快照表、以及每月帐户交易快照表。每日帐户交易快照表包含各关注主题区中日结交易资料的快照，包括各主题区中的所有帐户。每月帐户交易快照表包含各关注主题区中月结交易资料的快照，包括各主题区中的所有帐户。最后一个表格实际上是汇总表，为一种较高度粒度总结的事实表。因此，对于标示为产品402的第一产品，有申请表402a、申请状态表402b、每日平衡表402c、以及帐户快照表402d这四种事实表。由产品2到产品n的各产品都有与其相关的四种相同事实表。

警告及报告

如上所述，经理人面对的重大挑战在于，正确判断问题发生且早期预警警告送达相关人员（基于角色的目标式解决方案）的时机与范围、以及指定其为了识别其所需处理特定议题而需深度探讨的报告。此外，由于特定问题对经理人最重要的问题是与经理人在公司职位极相关的议题，因此那挑战加剧。部门主管面对的问题显著有别于对CEO重要的问题。

图5描述用于预定义及激活角色式警告程序的程序500。如以上所提的情境，本揭示尤指银行业用的管理解决方案而述，从而此处所提的特定范例适用于那业务。所属领域的人员将理解的是，程序500下的原理也可应用于其它产业，本技术中技巧的程度足以完成那任务。

程序500可予以设想为发生于两不同部分。第一部分是预定义阶段，包括步骤502至508。那些步骤按照使用者、产品或产品类别、警告主题、以及警告条件彻底定义程序。警告参数已建立的程序可进入主动阶段，即步骤510至518，其中，***监控运作以辨识符合警告准则的状况，并且在符合那些条件时，发布警告。

定义阶段的第一步骤，即步骤502，识别使用者角色。如上所述，使用者的角色主要支配(largely dictate)使用者要求履行其义务的特定信息。例如，CEO需要整体组织的绩效成果，要求整合来自许多来源的资料。在跨国组织中，可由各种组织总结成果，在分布广泛的时区中以不同币别运作。另一方面，部门主管需要等量的关键信息，但那信息将更加聚焦。例如，部门主管将搜寻最后变动及最近日的信息，而非查看一周或一个月的报告。部门主管将寻找往下达个别或单元层级所产生的收益或生产总量(production totals)，而非检讨整体事业单位的收益。

为了定义特定角色及其信息需求，必须完成相当多的研究，并且给予想法。此问题在当代大众传播及仪器(instrumentation)已变得尤其敏感。现代经理人的问题不在于如何取得更多信息，而是如何从随手可得的资料洪流中识别重要信息。为了支持如程序500之类任何***的实现，必须完成那层级的业务分析。为了聚焦于实现程序500的细节，据推测，业务分析师已完成组织内信息流及信息需求的探讨。

图6至图9描述***中所示表示程序500的示例性具体实施例。那些图式表示业务管理平台200（图1）警告定义部分的屏幕截图。其为图6的第一此类屏幕截图描述将由公司执行长/财务长/研发长（CEO/CFO/CRO）等等在签署警告***时所观看的屏幕。如那儿所示，警告屏幕600包括三个下拉式选单：角色选择下拉式选单602、产品选择下拉式选单604、以及警告类别下拉式选单606。另外，使用者观看警告显示608，显示所有目前的警告状况。下文说明那些屏幕部分的每一个。

如上所述，程序500中其为步骤502的第一步骤识别使用者角色。如图7所示，在警告屏幕600上，角色选择通过点选角色选择下拉式选单602予以达成。那动作呼叫开启适当的下拉式选单，其表示角色的选择。在此，使用者可选自CEO、产品主管、CRO、CFO、以及分析师。明显的是，这些角色未提供详尽的选单，同样明显的是，详尽的选单用起来麻烦。因此，某些提供适当角色群组的***在此将有作用。在某些具体实施例中，***可将其它信息用于判断目前使用者的大概角色。这些及其它方法界定使用者的职称，从而业务平台200上使用者的角色。

请回头参阅图5，下一个步骤504移向识别产品类别。应注意的是，预定义警告中所含括的特定准则在各种应用将有差别。在银行业中，产品类别是到业务资料内的良好进入点，理由是那些类别在例如零售银行、商业银行、及诸如此类之间有所差异。在其它业务中，不同的准则可具有重要性。例如，在某些运作中，地理位置可比产品类别还要重要。应注意的是，重要的不是特定类别识别，而是人们必须识别尤其适用于手边业务的类别名称(category designation)。

执行产品类别选择在图8中予以描述。在那儿，使用者点选产品选择选下拉式选单604以呼叫产品类别清单。所述清单中的选择有***、汽车贷款、个人贷款、房贷、以及财富管理。如使用这业务平台200的特定***所识别，那些类别区别银行业中的业务领域。即使在银行业内，特定公司仍很可能想要改变产品类别以符合其特定环境。例如，集中房贷业务的银行很可能停止(cut out)***、汽车贷款、个人贷款、以及财富管理的类别，而有利于例如住宅贷款、商业贷款、证券化贷款、以及诸如此类。

请再回去参阅图5，***在步骤506识别警告主题，接着在步骤508识别警告条件。这些步骤的第一个必须预先完成，理由是警告的基本主题必须通过初步业务分析予以识别。此分析是精确识别企业每一个层级进行适当决策所需信息的必要部分。人在组织的层级愈高，决策就变得愈困难，理由正是可用资料非常多。基于管理知识与技能其为在步骤508识别警告条件的第二点也需要某些预先规划，理由在于其必须先精确判断构成良好、有问题、以及不良绩效等级(performancelevel)的是什么。此外，此分析点必须不间断，理由在于必须持续详细检查绩效等级以赶上不断变化的状况。例如，随着设备更新，期望的绩效等级将最有可能变更。类似地，若为了精简成本拖延维修，则绩效等级必须适应那种状况。

请参阅图9，使用者可选择绩效等级以供触发给定警告。在此，主机公司(host company)利用颜色编码架构，以琥珀色、绿色、红色、以及白色指示绩效等级。考虑到颜色与特定绩效等级关联性广，而广泛使用类似的颜色架构。选择是必要的，因为使用者可关注于知道给定因素是否进行不顺，而另一个因素则可针对警告绩效良好或绩效不良的时机而予以识别，但不包括绩效为中间的时机。较佳的是，使用者可选择超过一个警告等级，允许多重绩效等级选择。

步骤508完成程序500的识别阶段。之后，***进入主动阶段，由步骤510至518所组成。步骤510由监控***组成，然后是步骤512，判断是否满足任何警告条件。若无条件符合，***单纯地回到步骤510。其可轻易地看出大部分***运作由这两个步骤组成。然而，若符合警告条件，在步骤514激活警告。可在图6至图9的警告显示608中看到那结果。如那儿所看到的，简述的是警告技术主题，还有指示警告项目状态的色圈(colored circle)。

报告

如先前所述，可认知经理人很可能想要比单一、简短系列(line)所可提出多出很多有关警告条件的信息。为了符合那需求，警告***与报告模块122（图1）整合。结果是，若在步骤516使用者想得到报告,其可点选警告显示608上每一个项目右端的色圈，并且那动作将在步骤518产生报告。通过在产生的报告中包括适当的超级链接(hyperlink)，经理人遵循一连串连结以取得或多或少其想要的信息。

本揭示所产生的报告范例示于图10至图15中。请参阅图10，***可利用使用者设定文件(user profile)建立一组预设准则，其管理使用者第一次登录***时显示的信息。在此，报告屏幕900在角色为「CEO」的人登录报告模块122（图1）时由***自动产生。在那儿，显示的是目前选择的产品区、以及一或多个特定报告。在所述范例中，使用者已预先设定产品区为「***」，并且己选择六个预定义报告供显示。个人设定档的产生及用途在本技术为众所周知而将不在此作进一步说明。

使用者为了产生所选择报告而采取的详细步骤将在下文章节予以涵盖。报告产生的第一步骤是角色识别，在图11中描述，使用者从下拉式选单902选择角色，如同以上关于警告所述。在此，提供给使用者的选择有执行长(CEO)、产品主管(PRODUCT HEAD)、研发长(CRO)、财务长(CFO)、以及分析师(ANALYST)。类似地，请参阅图12，使用者从下拉式选单904选择产品类别。这里显示的选择有***(CREDITCARDS)、汽车贷款(AUTO LOAN)、个人贷款(PERONL LOAN)、房贷(MORTAGE)、以及财富管理(WEALTH MANAGEMENT)。将理解的是，角色及产品选择两者都可予以交互修改。例如，使用者的角色可限制下拉式选单904所提供的产品范围。例如，房贷专员(mortgage officer)可能无法观看房贷(MORTAGE)除外的任何产品。

在每一个产品区内，有许多预定义报告是使用者可用的。这些报告可组成许多等级，以及***允许使用者阶层式着手报告类别及主题。例如，并且如图13所示，***可提供许多等级的类别906。所示的范例假设***选择为产品区，并且***提供三种顶层(top-level)类别，领先指针(LEAING INDICATORS)、同时指针(COINCIDENTALINDICATORS)、以及落后指针(LAGGED INDICATORS)，将类别依时间区分成过去、现在、及未来。产品类别的选择取决于对特定业务的通盘了解。另外，报告类别可随角色而变。尽管CEO可初始关注宽广、企业广度的类别，国内销售经理人仍可希望看到地理区分，以致顶层类别可能为东区(EASTERN REGION)、南区(SOUTHERN REGION)、及诸如此类。

顶层类别906之后是阶层式巢状子类别907，巢状层次仅视业务需求而定。在所述范例中，类别领先指针设有采购度量(AcquisitionMetrics)、活动分析(Activity Analysis)、属性(Attribution)等等子类别。将注意的是，子类别向其左方包含并且「扩增(expand)」按钮，告知使用者有另外的子类别可供选用。基于给定业务的结构，可提供多重子类别层次。

图14描述使用者己选择子类别采购度量的情境，其提供使用者四种报告908的选择，定名为采购指针(Acquisition Indicators)，采购趋势(Acquisition Trends)、核准分析(Approval Analysis)、以及例外分析(Exception Analysis)。如上所述，特定报告主题的选择、以及报告内容，源于特定使用者需求及业务的详细研究。

形成的所产生报告910可在图15中看到。此报告源于图14中所示屏幕中的选择采购指针。此报告呈长条图及资料显示两者的结构。业务分析将显露使用者对资料的需求、以及对于报告的适当维度化衡量。例如，所示图表的使用者需要以$100,000增量显示的帐面金额，每天的资料点作区隔。不同的业务情境可需要幅度等级大于或小于这里所示的量级(quantity scaling)（y轴）。类似地，时间单位（x轴）可较短（如盘中）或较长（跨周或月）。

尽管可了解使用者或许可结构化每一个这些报告，以及可能需要判断类别、子类别、以及个别报告是那个，那工作(task)所需时间将显著。然而，花在那工作上的时间是使用者主要任务外所花的时间，其需要分析资料并且进业务决策，而非结构报告。因此，提供使用者涵盖广泛业务活动的预定义报告集合容许使用者集中在资料上，而非供显示资料的程序。结果应该是跨业务的改良型决策制定。

另外，***提供使用者通过修改x及y轴数值以完善报告的能力、以及深度探讨更细粒度资料等级的能力。此些功能为众所周知并且将不予以详述。

***容许使用者快速识别警告条件并且将謷告直接连系至报告。警告产生充份直接并且直接了当，使用者仅需一些时间(in a matter ofmoments)即可改变警告识别，如改变环境所必要。

结论

将众所公认的是，以上所提***可适应于各种环境。本揭示所识别具体实施例的细节尤其连系于银行业，但所属领域的技术人员将认识到，可将相同原理应用到各种其它产业。基本业务分析可识别对经理人重要的信息类别。例如，某些企业将希望以地理区域区分信息，而其它则集中在产品系列(product lines)。这里提出的***有足够的弹性容纳种种业务需求，全部都落在本揭示的范畴内以及所附权利要求书的范围内。

Claims (5)

1.一种用于管理消费者金融服务业务的业务管理***，其包含：

数据库模块，其包括：

一或多个维度表，每一个维度表都经结构化用以包含该消费者金融服务业务有关的资料，其包括：

一或多个特定产品维度表；

一或多个共通维度表；

一或多个雪花维度表；及

一或多个静态维度表；以及

一或多个事实表，每一个事实表都经结构化用以包含与该消费者金融服务业务有关的资料，其包括：

一或多个申请状态表；

一或多个申请表；

一或多个每日帐户交易快照表；及

一或多个帐户交易快照汇总表；

警告模块，经预定义用以针对消费者金融服务业务重要性状况警告使用者；以及

报告模块，经预定义用以报告消费者金融服务业务重要性状况。

2.一种用于在操作业务管理***中产生警告以供管理消费者金融服务业务的方法，其包含

预定义业务警告状况，其包括：

识别使用者角色，连同使用者在所述角色中所需的关键信息；

识别与该关键信息相关连的产品类别；

识别与该关键信息相关连的技术主题；

识别与该关键信息有关的警告条件；

监控该业务管理***以判断是否符合任何警告条件；

一旦发现有警告条件符合，激活警告通知使用者；

一旦接收来自使用者的要求，产生连结至该警告的报告。

3.根据权利要求2所述的方法，其中，识别产品类别包括识别其为***、房贷、消费者贷款、汽车贷款、或财富管理之一的产品。

4.根据权利要求2所述的方法，进一步包含：

预定义报告以报告消费者金融服务业务重要性状况；以及

应使用者的要求为所述使用者准备并且散布报告。

5.一种用于管理消费者金融服务业务的业务管理***，其包含：

警告模块，经预定义用以针对消费者金融服务业务重要性状况警告使用者；以及

报告模块，经预定义用以报告消费者金融服务业务重要性状况。

Images