企业计划环境中的实时数据汇总

摘要

一种企业经营计划系统，包括具有相关数据区域和交易数据区域的数据库，以及用于在所述交易数据区域内存储从一组企业投稿人接收的投稿数据的服务器。所述服务器把所述投稿数据从交易数据区域登载到相关数据区域。所述交易数据区域可以包括一组投稿槽和一组汇总槽，这些槽根据企业模型分级相关。所述相关数据区域包括一组依照企业投稿人定义的相关表，而所述相关数据区域允许详细地统计分析以及生成报告。

说明书

发明领域

本发明涉及企业计算环境，具体而言，涉及用于企业经营计划的计算环境。

背景技术

企业日渐增多地承担为企业运作确立正确预测的工作。如果未能满足所确立的期望，就会给企业带来资金流动、股票价格、变现速度、以及投稿人信心领域以及其它领域的严重负面影响。以准确性为关键要素的企业计划活动的例子包括收益预测、库存管理、资源计划等等。然而，企业经营计划是十分困难并且昂贵的任务，通常产生不精确的结果。

通常，企业采取“自上而下”或者“自下而上”的方式来进行企业计划。在“自上而下”的计划中，企业识别重要的企业目标，诸如平均产品价格、每个雇员的成本等等，并且贯穿公司的分级结构把目标向下推行。相反，“自下而上”的计划涉及汇总来自于组织的最低成本中心的低级预测。例如对于预算计划来说，需要管理人员周期性地预测支出，并且把所述支出分配为多个类别，诸如广告、输送以及薪水。然而，如果同时存在的话，所述自下而上预测很少与自上而下的企业目标一致。

这种信息通常是使用纸件的形式来收集，近年来，通常使用诸如采用电子数据表软件程序创建的电子模板之类的电子形式来收集。这样经常给企业的财务部门遗留了统一不协调计划的艰难任务，其中所述不协调的计划已经通过使用不一致的假定并且改变企业逻辑来汇集了。

近年来，已经使用大型计算机系统来经由企业网收集所述数据。所述计算机系统通常使用耗时的、在“空闲”的几小时期间脱机批处理过程来统一从各种企业用户处收集的数据。这种脱机合并会在收集来自于用户的数据和把收集的数据与从企业收集的其它数据合并之间产生明显的时间延迟。因而，这种系统经常给用户呈现用于预测企业活动的实际的、汇总的数据的不精确视图。这会导致用户提供不正确的数据，或者错误地修改它们的输入。此外，用户可能不确定对于企业来说哪些数字是“正确的”数字，并且通常会怀疑结果的完整性。对于像企业计划这样的繁重的面对最后期限的活动来说，数据收集和脱机合并的这种低速处理会产生明显的问题。

发明内容

本发明致力于企业计划技术，通过允许组织使公司的财务模型和组织任务与详细预测实时地保持一致，来改善大型组织内部预算计划的准确性和可预测性。具体来讲，所述技术使用了企业计划数据库系统，所述企业计划数据库系统具有用于与企业用户实时交互的交易数据区域，以及用于详细统计分析并且生成报告的相关数据区域。

依照所述技术，企业计划系统允许并且自动进行自上而下的目标与对企业详细的自下而上的预测相一致。通常，所述企业计划系统提供三个阶段的企业计划：(1)建模阶段，(2)投稿阶段(contributionphase)，和(3)一致性阶段。在所述建模阶段期间，称为分析员的高级企业管理者或者行政部门定义组织目标，并且为企业构造计划模型。接下来，在投稿阶段期间，一组定义的投稿人与企业计划系统交互并且以投稿数据(contribution data)的形式提供详细的预测。在一致性阶段期间，所述企业计划系统自动地使预测数据与组织目标相一致。

在此过程期间，所述企业计划系统依照所定义的模型操作以便提供具有多个一致级别的分级计划过程。在每一级，所述企业计划系统向企业评审者呈现投稿数据，正如分级模型所定义的那样，并且要求评审者使目标数据与预测数据相一致。每个评审者例如可以鉴于分析员提供的公司目标来拒绝或者接受投稿数据。

当投稿人提供投稿数据时，所述企业计划系统跨越企业实时地自动汇总投稿数据，并且向评审者呈现所汇总的数据合格或不合格。此过程一直继续，直到与最高级别的组织层级相关联的评审者最终批准所述投稿数据为止，由此确保来自于所述投稿人的投稿数据与公司的目标相一致。

在一个实施例中，一种系统包括具有相关数据区域和交易数据区域的数据库，以及用于在所述交易数据区域内存储从一组企业投稿人接收的投稿数据的服务器，并且把所述投稿数据从交易数据区域登载到相关数据区域。所述交易数据区域可以包括一组投稿槽和汇总槽，这些槽依照企业模型分级相关。所述相关数据区域可以包括一组依照所述模型定义的相关表。

在另一个实施例中，一种方法包括依照多级企业模型接收来自于企业投稿人的投稿数据，并且把投稿人的投稿数据存储在数据库的交易数据区域内。所述方法还包括把所述投稿数据从数据库的交易数据区域登载到相关数据区域，并且根据数据库相关数据区域的投稿数据生成报告。

本发明可以提供一个或多个优势。例如，此处所述的技术通过允许组织使公司模型和组织目标与详细预测实时地保持一致，由此可以改善企业计划的准确性和可预测性。所述技术可以提供用于递送合作的、实时计划的能力、而不要求脱机合并以及汇总预测的平台。因为所述企业计划系统能实时汇总投稿数据，故而能向所有用户呈现正确的、最新的数字视图。无论所述计划涉及的企业用户的数目有多少，所述系统都可以提供快速响应，由此可以提供精确的计划信息。

此外，此处所述的体系结构能易于扩展到数千个用户，并且可以围绕最佳的计划实施来设计。以这样的方式，所述系统可以用于跨越企业内部的业务单位和系统来集中管理所有的计划信息，由此创建“计划中枢”。所以，用户能根据计划数据的单个库来工作，并且能确信数据的完整性。

另外，所述技术促进高级用户跨越所述企业进行合作，以便允许减少计划周期，例如从月减少到星期，并且迅速允许最佳地进行实施，像滚动预测。

在附图和以下描述中阐明了本发明的一个或多个实施例的细节。通过以下描述和附图并且根据权利要求书，本发明的其它特征、目的以及优势将更加明显。

附图说明

图1是举例说明企业计划系统允许并且自动进行使自上而下的目标与详细的自下而上预测相一致的环境的框图；

图2是举例说明企业计划系统的一个示例性实施例的框图；

图3是举例说明用于与所述系统交互的远程计算设备的一个实施例的框图；

图4是举例说明数据库服务器的示例性实施例的框图，其中企业数据被组织以便包括交易数据区域和相关数据区域；

图5和6是举例说明依照企业计划模型分级定义的交易数据区域的示例性组织的框图；

图7是举例说明企业计划系统更加详细操作的流程图；

图8是更加详细地举例说明企业计划系统执行的实时汇总过程的流程图；

图9是更加详细地举例说明在把数据从交易数据区域登载到相关数据区域的过程中、一组应用服务器的示例性操作的流程图；

图10是举例说明在跨越一组应用服务器控制多个企业计划模型的使用过程中、管理控制台的示例性操作模型的流程图；

图11-21举例说明了在示例性的企业计划会议期间由网络浏览器呈现的多个视图。

具体实施方式

图1是举例说明企业计划系统3允许并且自动进行使自上而下的目标与企业4的详细自下而上预测相一致的环境2的框图。通常，所述企业计划系统3提供三个阶段的企业计划：(1)建模阶段，(2)投稿阶段，和(3)一致阶段。在所述建模阶段中，诸如主管财务的官员、资深的财务分析师或者生产和销售分析员的分析员8为企业4定义需求并且为企业构造计划模型。更具体地说，分析员8开发具有多个分级设置的节点的模型，所述节点代表企业4内部的各种成本中心，诸如商业单位或者部门。

在所述建模阶段期间，分析员8还为组织层级的每个节点确立公司的目标。然后，分析员8向每个节点分配一个或多个企业用户，诸如管理者、监督者、销售代表、工人管理者等等，用于负责相应成本中心的企业计划。每个企业用户可以被指定为用于向企业系统3提供计划数据的投稿人8，用于取舍来自于投稿人8的分配的评审者，或者他们两者。投稿人8和评审者9可以是企业4内部或者耦合至网络9的其它实体内部的被授权用户，诸如供应商14和顾客16。

最后，分析员8定义多个模板来收集来自于所述投稿人的经费预测数据。分析员8把公司的目标数据包括在所述模板中以便与所述预测数据相一致。

接下来，在投稿人6与企业计划系统3交互的期间，企业计划系统3进入投稿阶段，并且以投稿数据的形式输入详细的预测。例如，根据正由企业4执行的特殊的企业计划活动，投稿人6可以提供详细的财务预测、收益预测、定购预测、库存预测、所估计的资源需求等等。

在一致性阶段期间，企业计划系统3自动使所述预测数据与分析员8提供的公司目标相一致。具体来讲，企业计划系统3依照所定义的模型操作以便提供具有多个一致级别的分级计划过程。当每个投稿人6提供他或者她的投稿数据时，企业计划系统3实时地自动汇总跨越企业4的投稿数据，并且向与企业4的较高层级相关联的评审者9提供对所汇总数据的访问。具体来讲，当接收来自于投稿人6的投稿数据时，企业计划系统3识别所有较高级别的组织模型，并且实时计算每级的新的汇总总数，其中所述所有较高级别的组织模型受到最新接收的投稿数据的影响。

所以，在企业计划会议期间，评审者9实时地察看跨越企业4所汇总的数据。在每一级，所述企业计划系统3确保评审者9、正如企业模型的节点所定义的那样，使目标数据与预测数据相一致。每个评审者9例如可以鉴于分析员8提供的公司目标来拒绝或者接受投稿数据。此过程一直继续，直到最高级别的组织层级最终批准所述投稿数据为止，由此确保来自于投稿人6的投稿数据与分析员8提供的公司目标相一致。

以这样的方式，企业计划系统3可以提供比传统方法更加正确的企业计划。例如，企业计划系统3可以通过允许组织使公司模型和组织目标与详细预测保持一致，来改善企业计划的准确性和可预测性。所述技术可以提供用于递送合作的、实时计划的能力、而不要求脱机合并以及汇总预测的平台。因为所述企业计划系统能实时汇总投稿数据，故而能向所有用户呈现正确的、最新的数字视图。此外，企业计划系统3的体系结构能易于扩展到数千个用户，并且可以围绕最佳的计划实施来设计。另外，所述技术允许企业用户高度合作，所述企业用户即投稿人6和评审者9，并允许减少正确的计划周期。

企业用户可以使用各种计算设备来经由网络9与企业计划系统3进行交互。例如，企业用户可以使用膝上型计算机、台式计算机等等并且运行诸如来自于Redmond，Washington的微软公司的InternetExplorer^TM的网络浏览器来与企业计划系统3进行交互。作为选择，企业用户可以使用个人数字助理(PDA)——诸如来自于Santa Clara，California的Palm的Palm^TM管理器、允许上网的便携式电话或者类似设备。网络9代表任何通信网络，诸如基于包的数字网路，像因特网。以这样的方式，系统2能易于扩展到适合的大型企业。所述企业用户可以经由局域网直接访问企业计划系统3，或者可以经由虚拟专用网络、远程拨号、或者类似远程访问通信机构来远程访问企业计划系统3。

图2是举例说明企业计划系统3的一个示例性实施例的框图。在所举例说明的实施例中，企业计划系统3包括网络服务器20、应用服务器26和数据库服务器40。

网络服务器20提供了一种接口，用于经由网络9与企业用户18通信。网络服务器20执行网络服务器软件，诸如来自于Redmond，Washington的微软公司的Internet Information Server^TM。照此，网络服务器20提供了用于依照软件模块21与投稿人6、分析员8和评审者9进行交互的环境，其包括分析模块30、投稿模块32、管理(ADMIN)控制台36和扩展管理器38。

软件模块21可以包括Lotus脚本、Java脚本、Java小程序、有效服务器页面(Active Server Pages)、依照超文本标记语言(HTML)或者动态HTML编写的网页、有效X对象以及其它适当的模块。网络服务器20服务于由软件模块21所定义的网页，并且向企业用户18的计算设备发送所述网页。所述网页可以包括静态的媒体，诸如文本和图形成像，以及常规的输入媒体，诸如文本条目框、单选按钮、下拉式菜单等等，用于接收来自于企业用户18的信息。

软件模块21与数据库服务器40交互以便访问企业数据42，所述企业数据42包括用户数据42A、模型数据42B、作业数据42C和结构数据42D。企业数据能够以多种不同的形式来存储，所述形式包括一个或多个数据存储文件，或者在一个或多个数据库服务器上执行的一个或多个数据库管理系统(DBMS)。所述数据库管理系统可以是关系型的(RDBMS)、分级的(HDBMS)、多维的(MDBMS)、面向对象的(ODBMS或者OODBMS)或者面向关系的(ORDBMS)的数据库管理系统。此外，虽然分别地举例说明了，但是可以把企业数据42合并成单个数据库或者其它数据存储结构。企业数据42例如可以作为单个关系数据库来实现，诸如来自于微软公司的SQL服务器。

用户数据42A存储每个用户18的信息，包括用户的姓名、电子邮件地址以及其它联系信息。模型数据42B存储由分析员8定义的企业计划模型。例如，模型数据库42B存储用于定义分析员8开发的一致性过程的信息，包括一致性级别的数目、所述层级中的各种“节点”以及与每个节点相关联的投稿人6。另外，模型数据42B存储所述模型的各个数据输入模板，用于获取来自于用户18的分配和评审数据。作业数据42C定义用于执行应用服务器26的管理作业，而配置(CONFIG)数据42D存储企业计划系统3的基本配置数据。

应用服务器36为执行企业逻辑模块46、企业计划扩展47和应用编程接口(API)48提供操作环境。另外，应用服务器36执行如作业数据42C所定义的管理任务。换言之，作业数据42提供了用于对未决管理作业的作业描述进行排队的机制，这些未决管理作业是将由应用服务器26执行的。

参照软件应用21，分析模块30包括一个或多个软件模块，用于创建企业计划模型，诸如企业4的财务模型，以便控制整体计划过程。例如，分析模块30允许分析员8定义各种成本中心、相应的拥有者以及在企业计划过程中一致性阶段的数目。在一种配置中，分析模块30从企业资源计划(ERP)数据库(未示出)中读取成本中心结构和所有权。另外，分析模块30允许分析员8定义“模板”来收集投稿数据。模板可以包括一个或多个多维的结构，其提供了用于输入和计算投稿数据的接口。例如，所述模板可以按照数据体内的维数来定义成本中心，以便依照沿行的会计科目表和列中的时期来选择数据。分析模块30在模型数据42B内存储企业计划模型以及相应的模板。

分析模块30还允许组织定义多个机制来自动执行预算过程，并且确保投稿人6及时提交它们各自的投稿数据，并且确保模板迅速地贯穿所定义的一致性阶段来移动。例如，使用分析模块30，所述分析员8可以定义触发电子邮件消息(电子邮件)，以便提醒投稿人6访问企业计划系统3并且完成特殊模板的定时器。

投稿模块32包括软件模块，用于向指定为投稿人6的企业用户18呈现所述模板，并且用于从投稿人5获取投稿数据。投稿模块32实时地获取并且汇总跨越企业4的投稿数据，并且向与企业4的较高层级相关联的评审者9提供对所汇总数据的访问。

报告生成器34包括分析软件模块，用于根据从投稿人6接收的投稿数据生成企业计划报告并且将其存储在模型数据42B中。具体来讲，所述分析软件模块允许用户18，诸如分析员8和评审者9，使复杂的查询公式化以便生成报告，并且对企业模型的当前数据执行其它数据分析功能。这些软件模块可以是具有浏览器接口的基于网页的模块，或者可以是独立的可执行程序。

企业逻辑模块46在应用服务器26提供的操作环境内执行，并且提供响应于软件模块21访问和处理数据库42内存储的数据的功能。具体来讲，企业逻辑模块46包括用于实现企业计划功能的软件例行程序，并且由软件模块21引用。

管理控制台36呈现用于控制网络服务器20、应用服务器26和数据库服务器40的集群的接口。管理控制台36允许系统管理员控制每个集群内使用的服务器的数目。所述系统管理员例如可以选择网络9内可利用的一个或多个服务器，并且指导管理控制台36来将服务器用作应用服务器36。以这样的方式，企业计划系统3可以容易地扩展到支持具有数千用户18的大型企业。

当管理与企业计划活动相关联的任务时，管理控制台36可以把所述任务中断为多个作业，每个作业依照多个级别、由特定模型定义的组织层级与模型的不同分层相关联。例如，管理控制台36可以把特殊的任务分隔为N个作业集，其中N等于在所述层级内定义的节点数目。然后，管理控制台36可以跨越使用所述模型的该组应用服务器26来分配所述作业。

管理控制台36提供作业接口来察看因应用服务器26将处理而排队的作业，并且察看跨越集群应用服务器26的负载均衡。管理控制台36生成作业数据42C来为应用服务器26定义任务。当作业在作业数据42C中排队时，应用服务器26从所述数据库服务器40读取作业数据42C，并且处理所述作业直到完成。例如，一个类型的作业涉及“剪切(cut-down)”处理，通过该处理，在企业数据42B内定义的企业模型被“划分”给每个用产。在此处理期间，应用服务器26识别分配给用户18的所定义模型的区域，并将其作为投稿人或者作为评审者。企业计划系统3把各个部分呈现给每个用户18，用于获取投稿数据，并且用于使投稿数据与组织目标相一致。用这种方式，企业计划系统3不必把整体模型发送给每个用户18，由此减少了通信时间以及资源需求。相反，每个用户18只接收相关信息。

另外，管理控制台36允许系统管理员跨越应用服务器26控制企业计划模型的使用。具体来讲，分析员8可以为企业4定义多个计划模型。例如，分析员8可以为收益预测、库存管理、资源计划、管理应付帐款等等定义独立的模型。管理控制台36允许系统管理员创建使用映射，用于把每个模型分配到一组应用服务器26。换言之，不同的企业模型可以在独立的应用服务器26上使用，或者可以共享一个或多个应用服务器。

因此，所述系统管理员可以细致地控制为企业计划分配计算资源，并且可以调节所述资源以符合企业的当前需求。所述系统管理员可以调节使用映射，以便根据企业计划活动的最后期限的接近来变更跨越应用服务器26的模型的使用。具体来讲，当最后期限接近时，所述系统管理员可以鉴于用户18可能增加的活动，把更多的计算资源分配给最早到期的企业模型。作为另一个例子，所述系统管理员可以根据参与企业计划模型的用户18的当前使用级别来调节所述使用映射。

管理控制台36允许分析员8修改企业计划模型。例如，在启动企业计划活动之后，分析员8可以希望获取附加的投稿数据。为了便于采用模型的改变，管理控制台36支持节点级修改并且维护企业计划模型。具体来讲，管理控制台允许分析员8登入并且登出所述模型的节点，即标记所述节点，或相反把所述节点的状态从“在线”改变为“脱机”。因此，分析员8可以更新与特殊的脱机相关联的模型“部分”，而不是中断企业范围的计划活动。其它用户不能够编辑脱机节点，即不能把投稿数据或者评审输入保存到交易数据区域62内节点的相应槽中。

然而，与非脱机节点相关联的所述企业投稿人可以继续提供并且评审企业计划会议的投稿数据。此特征允许基于每个节点来修改并且维护，并且允许模型保持运行。据此，分析员8可以修改与特定节点相关联的企业逻辑，而不使整体模型脱机。

应用服务器26通常处理由分析员8做出的模型改变。具体来讲，如果分析员8在计划活动期间修改了企业模型，那么可以使用应用服务器26使从用户18接收到的分配和评审数据与最新模型一致。作为选择，管理控制台36可以引导应用服务器26以便使用户18的计算设备远程一致。当所述模型改变之后由用户18进行身份验证访问时，验证服务器44可以把一致性作业“推”给本地计算设备。所述远程计算设备使用户18的投稿数据和评审数据与最新模型相一致，并且把统一后的数据保存到企业计划系统4。由于企业计划系统3不必脱机来更新企业模型，并且用于处理更新的计算资源可以跨越用户18的远程计算设备来分配，所以这样做是十分有益的。

扩展管理器38提供了一种接口，通过该接口，系统管理员可以安装并且有选择地使用扩展47来容易地把附加企业计划功能提供给系统10。一般说来，可以添加三类扩展：(1)管理扩展，(2)服务器侧扩展，以及(3)客户端侧扩展。管理扩展包括软件模块，用于在管理控制台36内执行，或者由管理控制台36启用。因此，管理扩展通常用于提供附加的行政功能，并且可以生成将由应用服务器26执行的管理作业。

服务器侧扩展通常在应用服务器提供的操作环境内执行。可以使用这些扩展来简化工作流程集成、自定义初始化或者在计划活动期间自定义登载汇总的投稿数据。

相反，客户端侧扩展包括软件模块，用于在用户18的远程计算设备的操作环境内执行，通常在网络浏览器环境内执行。投稿模块32自动地搜索最新安装的扩展47，并且当它们下次访问时把所述扩展下载给用户18。具体来讲，一旦用户访问或者当需要时，投稿模块32可以立即把扩展载入并且引用到远程计算设备上。虽然客户端侧扩展通常在远程计算设备的操作环境内操作，但是所述扩展可以与服务器侧部件交互。

为了简化扩展的并入，企业计划系统3提供了应用编程接口(API)48，由此，扩展47可以直接访问并且操纵模型数据42B内的模型，以及企业计划系统3的其它部件。经由扩展管理器38，所述系统管理员可以把新扩展48注册到系统10，并且定义用于启动扩展的输入，例如按钮或者其它图形图标。

扩展管理器38允许系统管理员根据分配给特定用户18的职责有选择地使用扩展。具体来讲，扩展管理器38允许系统管理员把扩展分配给所有投稿人6，并且分配给所有评审者9。另外，扩展管理器38允许系统管理员把扩展分配给模型数据42B内存储的企业计划模型的不同部分。以这样的方式，扩展可以被分配给不同的成本中心、不同的营业部门等等。此外，扩展可以根据评审者9在由特定模型定义的层级中的级别来进行分配。例如，可以要求所述层级的某个级别的评审者9、例如成本中心的控制者，完成最佳实施的扩展，用于提供关于所有汇总的投稿数据的详细的最佳实施验证。扩展管理器38可以把用户专用扩展信息存储到用户数据42A中，以表明把扩展分配给每个用户18，并且可能为所述扩展设定用户专用的属性。这种灵活性的优点是允许企业计划模型在企业计划会议更深地扩展到企业10时、可以被修改并且被自定义。

扩展的例子之一是这样一种扩展，用于在基于非定制产品协作网络的计划工具周围提供包装，诸如来自于微软公司的网络会议系统(NetMeeting)。评审者9可以把所述扩展引用于下级的会议，并且直接访问模型数据42B来一起评审投稿数据，而不是拒绝投稿数据。另一例子是用于允许相对于其它资源实时验证分配的扩展。扩展的其它例子包括：(1)所述层级内某些用户18需要的自定义报告功能的扩展，(2)把计划数据输出给其它应用、例如电子表格应用的扩展，(3)驱动最新开发的打印引擎的扩展，(4)输入企业数据的扩展，以及(5)与文档管理系统连接的扩展。

扩展管理器38允许所述系统管理员把扩展47映射到系统3内的事件或者消息。例如，所述系统管理员可以安装新的扩展，并且要求当经由投稿模块32从投稿人6之一接收投稿数据时引用所述扩展。此特征对于使用投稿数据的最佳实施验证或者其它企业要求的执行尤为有用。作为另一例子，可以使用扩展将自上而下的公司目标与自下而上的预测的统一控制在预先确定的百分比内，例如百分之十内。作为另一例子，可以使用扩展来减少对某级的预测，或者降低到特定的百分比。据此，可以容易地跨越企业4来要求和控制在预测方面的一致性的减少。

在一个实施例中，扩展47可以包括用于遵照部件对象模型(COM)的软件模块。因此，可以容易地把ActiveX客户端用于引用扩展47。每个扩展47可以提供一个或多个公用接口，以便例如由投稿人模块32或者管理控制台36启用并且控制。

图3是举例说明计算设备50的一个实施例的框图，包括当用户18操作时在其上执行的各种软件模块，所述用户诸如是投稿人6或者评审者9。在示例性的实施例中，计算设备50包括网络浏览器52、计算引擎54、模板56和数据体58。当用户18引导计算设备50访问企业计划系统3时，计算引擎54和模板56被下载并且安装在网络浏览器52内。

在一个实施例中，计算引擎54包括嵌入ActiveX对象的正向计算引擎54，其中所述ActiveX对象是依照基于阵列的语言构建的。模板56包括ActiveX控制，用于包括任何必需的驱动程序来输入和操纵预算预测数据。模板56包括独立的数据体58，其包含自上而下的目标数据以及自下而上的投稿数据，并且允许所有计算在本地执行。因此，在完成下载之后，每个投稿人6可以在模板56内修改他或她相应的投稿数据，并且执行计算，而不访问企业计划系统3。作为ActiveX部件，计算引擎54、模板56和数据体58经由计算设备50得以本地维护。照此，所述投稿人6只会在模板56和计算引擎54被最初下载时，以及当在会议结束时保存模板56的时候，才会感受到网络延迟。

为了与企业计划系统3交互，每个投稿人6使用浏览器52来与模板56交互，以便提供各自的投稿数据，此过程例如是通过完成所显示的表格单元，并且察看所述表格内计算的项目发生的动态改变。因为计算引擎54驻留在网络浏览器52内，所以单元条目不必重新提交给企业计划系统3，不必重新计算然后经由网络9重新发送到网络浏览器52。如果所述投稿人6希望结束计划会议，但是没有完成该过程，那么所述投稿人6可以把模板56以及数据体58保存到企业计划系统3。当投稿人6希望继续计划会议时，他或她可以访问企业计划系统3，在那时，将把合适的模板56以及数据体58装载到网络浏览器52中以便进一步编辑。当所述投稿人6对模板56内输入的预算数据表示满意时，投稿人6可以把数据提交给企业计划系统3。当每个投稿人6提供他或者她的投稿数据时，或者接受所述投稿数据时，企业计划系统3实时地自动汇总跨越企业4的投稿数据，并且向与企业4的较高层级相关联的评审者9提供对所汇总数据的访问。

依照类似的方式，每个评审者9经由网络浏览器52与企业系统3交互，所述网络浏览器52在他或者她的远程计算设备50上运行。每个评审者9可以鉴于分析员8提供的公司目标来拒绝或者接受所述投稿数据。此过程一直继续，直到与最高级别的组织层级相关联的评审者最终批准所述投稿数据为止，由此确保来自于所述投稿人的投稿数据与公司的目标相一致。

在一个实施例中，网络浏览器52包括内嵌压缩模块53，用于自动地压缩与企业计划系统4的通信信息，并且解压从系统接收的通信信息。具体来讲，内嵌压缩模块53自动地侦听从网络浏览器52经由超文本传输协议(HTTP)传送到系统10的输出缓冲信息，并且在传送之前自动地压缩所述缓冲信息。同样，内嵌压缩模块53侦听输入的HTTP缓冲信息，并且确定所述缓冲信息是否被压缩。如果所述缓冲信息被压缩，那么内嵌压缩模块53自动地解压所述缓冲信息，并且把解压的缓冲信息运送给网络浏览器53。以这样的方式，内嵌压缩模块53无缝地压缩和解压计算设备50和企业计划系统3之间的通信信息，由此能够在系统2内提高效率。

在一个实施例中，企业计划系统3利用单个有效的服务器页面(ASP)来接收压缩的HTTP缓冲信息，并且把压缩的缓冲信息定向到合适的企业逻辑模块46以便解压和处理。带有每个HTTP缓冲信息的首部可以包括字节计数或者表明所述缓冲信息是否被压缩的其它信息，并且包括合适的企业逻辑模块46的标识符。

图4是举例说明数据库服务器40的示例性实施例的框图，其中企业数据42被组织以便包括交易数据区域62和相关数据区域63。一般说来，交易数据区域62支持来自于用户18的实时数据采集和汇总，而相关数据区域63用于生成报告和进行复杂的数据分析。

更具体地说，数据库服务器40把从投稿人6接收的投稿数据存储在交易数据区域62中，并且例如定期地把投稿数据从交易数据区域62登载到相关数据区域63。交易数据区域62包括多个槽66，这些槽是依照企业模型来分级相关的。交易数据区域62包括一组投稿槽66用于存储从投稿人6接收的投稿数据，并且包括一组汇总槽67，用于存储根据所述投稿数据并且依照模型定义的层级实时计算的汇总数据。因此，交易数据区域62包括每个企业投稿人6的交易槽67，用于存储从相应的企业投稿人接收的投稿数据。另外，交易数据区域62A把每个评审者9与每个评审者9的至少一个汇总槽67相关联。例如，企业模型可以具有N个分级设置的节点，每个节点在网络用户处定义并且指定所述用户作为投稿人和评审者的其中一个。依照此结构，交易数据区域包括N个槽，这些槽包括每个评审者的汇总槽以及由所述模型定义的每个投稿人的交易槽。

图5和6是进一步举例说明依照企业计划模型分级定义的交易数据区域66的组织的框图。图5描述了由企业计划模型定义的示例性层级，用于示例性的假想的比萨饼连锁商店：比萨饼大厦股份有限公司。层级70在通过特许而占有的各种地理区域周围被水平的组织，具有区域1至5，并且纵向组织成三个一致性级别。企业目的以及目标由分析员8设定，并且被向下分配至所述层级的各种节点。称为代销店的特许的个体商店占据底部级别，即III级，并且提供投稿数据。

1级的每个节点具有相应的投稿人6，负责输入投稿数据。同样，1级、II级的每个节点与评审者9相关联，以便鉴于由分析员8定义的公司目标来统一所述投稿数据。为简单起见，图5举例说明了投稿人之一，与代销店A相关联的Andy，并且示出两个评审：与区域1相关联的Peter以及与所述节点相关联的Guy。在此例子中，Guy是比萨饼大厦股份有限公司的财务总管，并且负责监督所有区域。因此，Guy被列为根节点29的“拥有者”，并且作为所有区域1-5的“评审者”。Peter是负责监督区域1的中级管理者。照此，Peter被列为区域1的拥有者并且列为代销店A的评审者。作为本地比萨饼商店的管理者的Andy被列为代销店A的拥有者。

根据层级内节点的级别，把层级70的每个节点与模型数据42B内一个或多个相应的模板相关联。例如，把III级中的每个代销店与用于获取预测信息的单个模板相关联。在II级，把每个区域与其对应的子节点的所述模板相关联，所述子节点即所述区域中的代销店。因此，把层级70的根节点72与公司的所有模板相关联。

图6举例说明了交易数据区域62的示例性组织，用于依照比萨饼大厦的企业计划模型定义的层级70来支持投稿数据的实时汇总。在此例子中，交易数据区域62包括III级的每个节点的投稿槽66，即每个代销店A-H。每个投稿槽66存储所述投稿人6的投稿数据，所述投稿人6与层级70的III级相应节点相关联。

同样，交易数据区域62包括1级、II级每个节点的汇总槽67，即根节点72以及对应于区域1-5的节点。每个汇总槽67存储其子节点的汇总的投稿数据，正如层级70所定义的那样，并且在图6中由箭头表示。例如，汇总槽74对应于根节点72，并且存储通过对从区域1-5接收到的所有数据求和来计算的汇总数据。作为另一例子，对应于区域2的汇总槽76存储由代销店B-D的投稿数据计算的汇总数据。以这样的方式，交易数据区域62为所述模型的所有级别提供正确的、最新的数据视图，由此简化企业范围的计划。

图7是举例说明企业计划系统3更加详细的操作的流程图。最初，分析员8与企业计划系统3交互，以便开发包括一个或多个数据体的计划模型，其中所述数据体具有多个维数(80)。例如，对于比萨饼大厦股份有限公司来说，所述模型可以定义维数为3的单个数据体：(1)第一维列举具体比萨饼，例如肉类爱好者、素食者、烤肉、海味、火腿和蘑菇，(2)第二维用于每周的销售预测，以及(3)第三维用于公司目标。

分析员8还定义组织层级来控制企业范围的计划过程(82)。例如对于比萨饼大厦来说，分析员8可以定义具有十四个节点的组织层级，如图5中所示那样。分析员8把一个或多个企业用户分配给每个节点，并且把每个用户指定为投稿人、评审者或者他们两者。另外，分析员8可以把与每个节点相关联的用户之一指定为该相应节点的拥有者。

当接收组织层级时，企业计划系统3的应用服务器26鉴于所述层级来处理所述模型，以便为每个所定义的用户“划分”所述模型。换言之，应用服务器26把所述层级应用于所述模型，就好像所述层级是附加的维数，并且识别每个用户可以访问的各自的模型部分。应用服务器26把层级中的每个节点与跨越模型其它维的划分相关联。通过以这样的方式划分模型，企业计划系统3不必把整体模型发送给用户的远程计算设备，而是只需要发送所述模型的一个或多个数据体的相关部分即可。

另外，应用服务器初始化企业数据42，包括创建交易数据区域62的适当数目的汇总槽66和投稿槽67，以及创建相关数据区域63的表与关系。

接下来，分析员8与企业计划系统3交互以便为企业提供目标数据(86)，并且投稿人6与系统交互以便以投稿数据形式的提供详细预测(88)。当接收所述投稿数据时，应用服务器26更新交易数据区域66的投稿槽67来存储所述投稿数据，并且实时更新汇总槽66，以便存储企业层级的每个高级节点的汇总总数。

以这样的方式，评审者9易于跨越企业4来利用汇总总数。因此，评审者9可以访问企业计划系统3，并且鉴于分析员8提供的目标数据来立即提供要么拒绝要么接受投稿数据以及汇总总数的评审输入(92)。在此处理期间，应用服务器26周期性地把投稿数据以及汇总数据从交易数据区域62登载到相关数据区域63(94)，以便通过报告生成器34创建分析报告以及其它统计分析(96)。企业计划系统3重复所述一致性处理，直到组织层级的高级评审者接受所述投稿数据以及汇总总数(98)。

图8是更详细地举例说明企业计划系统3的实时汇总处理的流程图。当接收来自于投稿人6之一的存取请求时(99)，应用服务器26访问企业数据42并且识别投稿人的各自的投稿槽(100)。应用服务器26从识别出的槽中检索由投稿人先前存储的任何投稿数据，并且把输入模板56和投稿引擎54发送到投稿人6(102)。

当从所述投稿人6接收新的或者更新的投稿数据时(104)，应用服务器26更新相应的投稿槽以存储所述投稿数据(106)。接下来，应用服务器26有选择地更新与更新的投稿槽相关任何母汇总槽的汇总槽66的汇总总数。具体来讲，应用服务器26根据定义的分级模型来识别已更新的投稿槽的即时母汇总槽(108)，根据更新的投稿槽计算母槽的新的汇总总数(110)，并且把新的汇总总数存储到母槽(112)。应用服务器26重复此过程，直到所有相关的高级汇总槽都被更新(114)。

在一个实施例中，应用服务器26把交易数据区域62组织为具有一组行的单个表。每个行对应于所定义的组织层级中的各自节点。应用服务器26把相应的投稿数据或者汇总数据存储在每个行内，并且可以把数据存储为包含单个“滴(blob)”的数据的行。具体来讲，应用服务器26可以把数据作为单个串、文本或者二进制数据写入给定的行。在一个实施例中，每个行被存为遵照可扩展标记语言(XML)的打包文本。

打包的XML描述了对于所述模型的划分的每个单元，其属于与所述行相关联的用户，并且描述了所述单元的当前值。当初始化交易数据区域62时，应用服务器26从模型的一个或多个数据体提取元数据，并且在相应的槽内创建所述模型每个“划分”的XML表示。

当更新所述投稿数据时，所述XML可以由用户的远程计算设备生成。所述远程计算设备可以生成所述XML，并且把XML作为HTTP缓冲信息的一部分依照压缩或者未压缩的形式来发送。作为选择，应用服务器26可以生成XML。

为了实时更新汇总总数，应用服务器26解析相应的母汇总槽的XML，以便迅速地检索所述单元的当前值，并且采用具有更新的汇总总数的新条目来替代打包的XML。所述汇总数据可以依照XML形式来存储，并将其作为具有一组单元的线性阵列来存储汇总总数。因此，应用服务器26可以从一个汇总槽检索线性阵列，利用母汇总槽阵列来覆盖所述阵列，并且迅速地重算母槽的汇总总数。

图9是更加详细地举例说明在把数据从交易数据区域62登载到相关数据区域63的过程中、应用服务器26的示例性操作。应用服务器26可以周期性地登载数据，例如每15分钟、每30分钟等等。作为选择，或者另外，应用服务器26可以响应一种事件来登载数据，所述事件例如是提交来自于投稿人6的投稿数据，或者来自于评审者9的评审输入。

为了登载所述数据，应用服务器26传递每个投稿槽67的投稿数据，以便识别一组数据元和相应的值(116)。如上所述，每个槽67可以包含用于描述一部分企业计划模型的打包XML。应用服务器26解压打包的XML，并且识别所述模型的数据体所包含的单元以及所述单元的当前值。

接下来，根据所述模型，应用服务器26从对应于解析的投稿数据的相关数据区域63选择一个或多个表(118)。例如，应用服务器26可以识别销售表以存储预测的产品销售。

最后，应用服务器26把解析的数据写入相关数据区域63的识别表中。因此，报告模块34可以把复杂的查询发布到数据库服务器40，以便生成富有经验的报告，或者对跨越企业4获取的投稿数据执行类似分析。

图10是举例说明在跨越应用服务器26控制多个企业计划模型的使用过程中、管理控制台36的示例性操作模型的流程图。最初，管理控制台接收识别一个或多个应用服务器26的输入(122)。例如，系统管理员可以从局域网内的服务器列表中选择应用服务器26。作为选择，所述系统管理员可以规定特殊的名称、网际协议(IP)地址或者用于与所述应用服务器通信的类似通信处理。

作为响应，管理控制台36为描述在每个服务器上呈现的计算资源而查询识别出的应用服务器，诸如在每个应用服务器26内呈现的处理器数目(124)。管理控制台36可以把此信息呈现给系统管理员，以用于使用企业4的各种计划模型。

接下来，管理控制台36接收来自于系统管理员的输入，所述输入用于把每个模型分配给一组应用服务器26(126)。根据所述输入，管理控制台36生成使用映射，用于把每个模型与相应的应用服务器组相关联，并且把所述映射存储在企业数据21内(128)。

根据所述映射，企业逻辑模块46生成用于管理企业计划会议的作业，并且把作业描述存储在作业数据42C内。应用服务器26依照所述使用映射读取并且处理所述作业描述(130)，如上所述。以这样的方式，不同的企业模型可以在分开的应用服务器26上使用，或者可以共享一个或多个应用服务器。

可以响应来自于系统管理员的输入或者动态地根据应用服务器26的当前装载级别来调节使用映射(126)。具体来讲，管理控制台引导再生所述使用映射，由此使跨越应用服务器26集群的企业计划模型的使用重新平衡。

图11-19举例说明了在上述假想的比萨饼大厦股份有限公司的示例性企业计划会议期间、网络浏览器52的多个视图，如上所述。例如，图11举例说明了当Guy(CFO)访问企业计划系统3以便检查比萨饼特许的各种预算的处理时，由网络浏览器52显示的视窗160的一个实施例。在此例子中，Guy已经使用来自于微软公司的Internet Explorer并且运行来自于Macromedia公司的Shock Wave^TM来访问了企业计划系统3。

视窗160显示：1)对于给出预算模板的所有投稿人和评审者的可自定义的标题行162，2)用于显示指令的链路164，3)投稿人的姓名，以及4)当前日期。企业计划系统3可以使用构建在远程计算设备的操作系统中的认证来用于安全保证，因此不必分别地创建和管理新口令。

视窗160包括左框165，用于显示由分析员8为比萨饼连锁商店定义的分级模型138。如上所述，所述层级包括五个销售区域，区域2具有3个比萨饼商店(代销店B-代销店D)。所述层级代表公司的工作流程，并且因此对于投稿人很直观。此外，每个投稿人具有有限的视图，因此左框165只显示具体的投稿人已经访问的部分层级模型138。因为Guy是被定义为所有五个区域评审者的高级执行者，所以他可以察看整体层级。

当用户选择左框165中所述层级中的节点时，右框166和左框165由此结合，右框显示所选节点及其子节点的细节。更具体地说，右框166显示详细说明所选节点和其每一个子节点的表。每个表示出了：a)节点名，b)所述节点的操作状态，c)对模板的最后修改时间，d)所述预算模板是否已经由节点的拥有者打开，e)拥有者/评审者姓名，f)所述预算模板是否已经评审，以及g)用户可以对所述节点采取的动作。

在所述层级中的底部级别，每个节点具有三个工作流程状态：a)NS-所述预算没有开始，b)WIP-所述预算是那种拥有者已经输入一些数据但是没有结束的“未完工程”，以及c)LOCKED-拥有者已经把预算提交评审。一旦提交预算，拥有者就无法做出改变，除非下一级评审者拒绝所述提交，由此把较低线路节点的状态改变回WIP。

作为本地比萨饼商店的管理者的Andy的视图与Guy十分不同。图12举例说明了当Andy访问企业计划系统3时网络浏览器52显示的示例性视窗170。如图12所示，Andy只能查看代销店A，即他负责的代销店。因为Andy没有开始预算过程，所以右框的表172显示所述节点的NS状态。

图13举例说明了当Andy点击代销店A并且开始企业计划过程时显示的视窗180。在此刻，网络浏览器52下载模板56以及数据体58。当存在跨越网络9的通信时，这是少数几次之一。当计算引擎54驻留在所述客户端时，当用户输入预算信息时不进行网页通信。Andy与视窗180交互以便输入支出预测数据182，但是无法更新已经由分析员8设定的目标数据184，并且无法改写模板内嵌入的公式。以这样的方式，视窗180允许Andy察看由分析员8设定的财务目标，同时输入详细的预测信息。计算引擎54允许视窗180作为智能电子数据表来操作，所述电子数据表用于支持算术运算、有条件的逻辑、加权和时间平均以及多个其它运算。另外，分析员可以配置视窗180以便提供对行、列以及页面项目的上下文有关的帮助。当输入支出预测数据182时，Andy可以保存所述信息并且稍后继续所述过程，或者可以把所述预测信息提交给Peter来评审。

当Andy保存所述模板时，如图14中所示那样，网络浏览器52显示视窗190，其将所述节点的状态反映为“未完工程”(WIP)。依照这种状态，Andy可以返回并且继续编辑预测数据，并且提交所述预测数据以供Peter评审，如图15的视窗200所示。一旦提交了预测数据，所述节点的状态就被转换为LOCKED(锁定)，如图16的视窗210所示。依照这种状态，Andy无法修改所述预测信息，除非Peter评审所述模板并且拒绝所述信息。

图17举例说明了当Peter访问企业计划系统3以便评审他负责的预算信息时、由网络浏览器52显示的示例性视窗220。如图17所示，把Peter定义为区域1的拥有者，并且是代销店A的评审者。当注册时，Peter立即能够知道Andy已经提交了预算信息，这是通过右手视窗的表222显示的LOCKED状态反映出来的。另外，因为区域1的所有子节点、即代销店A，已经提交了预测信息，所以表224显示区域1的状态为READY(就绪)，以表明Peter可以评审所有的预算信息。

图18举例说明了当Peter选择用于评审时显示所述模板的示例性视窗230。值得注意的是，包括由拥有者(Andy)设定的预测数据232以及由财务分析师设定的目标数据234在内的所有信息都是只读的，并且无法进行修改。照此，Andy作为评审者具有两个选项：(1)拒绝所述预测信息并且把表格送回给Peter以便修改，或者(2)同意所述预测信息，如此使得所述模板可以由Guy来评审，Guy是区域1指定的评审者。在此级别，所述节点具有五个可能的状态。最先的三个与1级节点相似：NS(没有开始)、WIP(未完工程)以及LOCKED。另外，高级节点还可以是INCOMPLETE(残缺)以及READY(就绪)。所述INCOMPLETE状态出现在至少一个子节点处于NS状态时，即，当向评审者汇报的人员没有开始所述预算过程时发生。

由此，评审者9可以迅速地知道所述模板是否没有被察看，并且拥有者是否需要一些附加的提示。所述READY(就绪)状态出现在所有子节点都已经完成预算过程时。在此刻，所述评审者是预算过程的要径，并且必须拒绝或者提交来自于下级的数据。在其它数据收集方法中，这种方法的一个优势在于：中级管理者具有简单并且有效的方法来显示他们已经接受的上级管理，并且保证预算的预测。

图19举例说明了当Peter拒绝来自于代销店A的信息时、信息的示例性视图。代销店A已经转换回到WIP状态，其因此还把区域1移回WIP状态。拥有者Andy自动地接收来自于Peter(他的评审者)的电子邮件，通知他为什么所述意见被拒绝。继续这种一致性处理，直到把合格的预算信息最终向上传送到所述层级的所有级别。

图20举例说明了当分析员8创建并且维护企业模型时、由浏览器52呈现的示例性视图，包括把拥有者分配给所述层级的各种节点。图21举例说明了当分析员为每个节点定义存取级别(例如读取对写入)时、由浏览器52呈现的示例性视图。

已经说明了本发明的不同的实施例。这些以及其它实施例都在以下权利要求书的范围内。