这篇文章是关于什么？

这是一篇笼统的文章，涉及什么是“预算自动化”，该领域包含哪些问题以及使用了哪些IT工具。



如果您想了解BI，数据仓库（DWH），预算自动化系统（Cognos，Anaplan，1C：控股管理，Bit.Finance）如何相互连接以及它们与其他公司信息系统的区别-您在这里。



如果您是从未从事过业务规划主题领域的技术架构师，那么本文也很适合您。





我立即警告您，我试图用最简单的语言撰写本文，以​​便每个人都可以理解。

我为什么决定写它？

如今，几乎没有对该领域的简短系统描述，它可以为以下问题提供清晰的答案：

1. ? ?
2. (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, ., 1: ) ?
3. BI – ?

会计和计划之间的体系结构差异是会计数据从下至上流动。为了获得质量报告，您需要组织尽可能详细的事实记录。然后，任何汇总信息（对于管理人员而言很重要）都可以通过简单的汇总获得。



因此，在会计中，“文档”->“表（寄存器）->“报告”方案可以达到最佳效果（早在自动化之前就已使用，早在中世纪的会计中就已使用）。





数字：1.会计方案“凭证->注册->报告”





该计划最初得到了扩大。因此，方便的是精确地“从上方”输入它们（即，以与生成报告相同的形式）。



因此，当试图通过与传统会计类似的方式构建预算自动化时（图3），公司将立即面临三个关键问题。





数字： 3



问题1：管理规则。管理以报告代码编写的数据转换规则（从最低级别的会计到预算格式）非常不便，而且很费力。



问题2：``聚集事实''的速度。计划非常快速地显示在报告中（因为它们已经以放大的形式存储），而实际数据的计算速度非常慢。



问题3：计划报名表... 输入计划最方便的形式是计划情况报告。但是信息系统中的报告通常不允许数据输入。



前两个问题不仅与预算有关，而且总体上代表了数据仓库，数据集成和ETL整个主题领域的基础。



第三个问题是特定的计划问题。实际上，这是作为实时工具的ERP系统的重要问题之一（实时工具不仅设计用于已发生事件的“适当”核算，还用于业务的计划和运营控制）。

问题1：管理转换规则

在图。在图1-3中，所有转换实际数据的规则（从最低会计级别到较高报告级别）都正确​​地写在了报告代码中。



这是不好的：

• 不更改代码就无法管理规则；
• 它们只能在此报告中使用。
  意思是：

  – , , ,
  
  – - ,
  
  

转换规则的复杂性

在此必须考虑转换规则确实可能非常复杂，这一点非常重要。转换并不总是简单的数据聚合（每天到每个月；从部门到组织；从仓库到区域；从产品线到物品等）。这在独联体国家尤其明显，在独联体国家，管理会计通常基于会计。然后，从不同会计明细的各种组合中，可以确定管理会计的不同值。





您可以想象维护这样的代码对程序员来说有多大的问题，如果有几百篇这样的文章，它们会用在十几个不同的报告中，并且在管理会计中确定它们的规则可以每3-4个月进行调整。

问题1的解决方案：映射

为了解决此问题，可以从报表中删除映射（不同级别和/或记帐和报告类型的字段之间的对应关系），将其创建为单独的对象，分别进行配置和存储，然后在必要时进行引用。





数字：4



这一次具有两个优点：

• 规则更易于管理。可以使它们具有交互性并且无需代码即可进行配置，这意味着即使是普通用户也可以经常这样做。
• 一个规则可以在不同的报告和/或其他算法中使用

这种方法没有明显的缺点。



但是，开发用于方便地映射大量目录的工具并不容易。

问题2：实际数据转换的速度

问题2的解决方案：存储转换后的数据

为了不“即时”计算报告数据，可以将它们以放大和转换的形式存储。



为此，除了源表（公司中仍将需要）之外，您还需要创建表来存储汇总的实际数据。这些可以是单独的表，也可以是“计划”和汇总的“事实”的通用表。



当然，必须首先以某种方式填充这些表：为此，我们将执行与生成报告时较早的转换过程相同的转换过程，但是现在我们将其移至单独的后台进程。





数字：五

W

与该问题相关的是数据仓库（DWH）域。



粗略地说，DWH是用于存储中间计算（汇总或以其他方式转换的）数据的位置（一个表，或者实际上是一组相关的表）。



优点是什么：

• 数据读取速度。如果报表“读取”了表中已转换的数据，则它们会非常快地完成操作。
• 可验证性。将数据预先存储在仓库中后，可以更轻松地进行验证。

缺点：

• 准确性。实际上，这个负值是理论上的（当我们从最主要的信息源获取数据时，就可以确保最大的准确性）。
  实践中

  , ; , . , , , .
• 加载内存。因此，为了存储聚合数据，我们浪费了硬盘驱动器上的额外空间。而且，实际上，这在理论上是不利的。
• 解密。如果我们将报告连接到汇总表（根据源文档未详细说明数据），则解密（下钻）的可能性就会出现问题。

ETL流程

ETL可以称为任何过程，其中数据是从某个地方获取，修改然后加载到某个地方的。这是“提取”，“变换”，“加载”的常见缩写。



但是通常在将转换后的数据写入某个位置进行存储的情况下，通常精确地使用该术语。



这种方法具有以下优点：

• 系统上的负载分配。转换过程会随着时间而延长。我们可以逐步（在原始会计系统中更改/添加数据时）或按计划填充汇总表。例如，当服务器“免费”时，复杂的计算可能会推迟一整夜或其他非工作时间。这使您可以管理系统上的负载。
• 一次性转换。一旦将摘要信息写入汇总表中，就可以从许多不同的报表中访问它。因此，不必多次执行相同的转换。

只有一个减号：

• 控制已加载数据完整性的复杂性。建立一个不会丢失数据的ETL流程，该流程应足够透明且可控制-可能，但是这需要一支高素质的团队，用户的参与以及可观的人工成本。

问题3：预算输入表

事实是，以经典形式，软件产品中的报告是数据输出的一种手段。但是您不能在其中输入数据。





但是对于预算而言，经典方案“输入表单”（文档）->内部表->输出表单（报告）“不适合。



例如，一次我们制定了每月采购报告（如图2所示），但现在我们开始计划，而CFO希望以相同的形式输入采购预算。



还剩下什么呢？您可以创建一个看起来与该报告非常相似的计划输入表单（如图3所示）。

问题3的解决方案：交互式I / O表单

该解决方案也很明显：而不是通常的“文件”和报告”，你应该创建一个对象，将同时和阅读和输入数据。



如果在该对象中还可以在输入的数据和/或读取的数据之间执行计算，那就更好，那就是像Excel允许您那样工作。



在这种情况下，输入后的计划可以“添加”到实际数据所在的同一数据仓库中（见图）。





数字： 6



但是，这种形式比会计系统中的普通报告或文件要难得多。



交互的程度可以不同：更容易实现预配置的表单，更困难的是动态的（列/行的数量事先未知，但它们的类型是预定义的）。让用户“旋转”数据，建立新表格并设置任意计算公式，更改报告的结构甚至更加困难。

问题4的解决方案：多维数据集

还有另一个工具可以解决上面未指出的问题。

事实是，在大量数据，高交互性和复杂公式的情况下，习惯上存储来自ERP系统的数据的普通关系SQL表不能提供最大的实时数据处理速度。



为了解决此问题，您可以不以表的形式而是以多维数据集的形式来使用数据存储。





的确，如果对于预算任务而言，立即以多维数据集的形式组织存储是一个不错的选择，那么对于其他业务任务，多维存储模型可能就不合适了，并且可以使用其他技术来组织存储。在这种情况下，多维数据集可以作为体系结构中的另一个链接添加到“主”存储中。

预算中的软件产品类型

现在，让我们考虑解决预算自动化中重要问题的信息技术类型：

• 初始数据系统（会计系统，ERP系统）
• ETL工具
• 数据仓库（常规和OLAP多维数据集）
• BI系统
• EPM系统
• 当然是Excel

每种类型的系统都具有理论上的基本功能（请参见表）：







但是实际上，界限是稍微模糊的，并且通常产品会“知道”如何做相关的事情。重叠的函数非常大致如下所示：







重要说明：应该注意的是，重叠的函数通常不是100％。



也就是说，通常提供附加功能的工具不能像单独的专用工具那样执行它们！

预算中的软件类型图

一般而言，用于通过不同类型的信息系统预算自动化不同的任务以视觉覆盖率可以显示大约是这样的：





图 7



现在，让我们看一些流行的软件产品提供什么样的预算架构。

ERP系统中的预算

随着时间的流逝，ERP的概念发生了变化，新功能正在纳入ERP系统。



我认为，“经典” ERP功能包括一个会计系统；报告设计者；计划的运行控制功能，当然还有其输入的基本功能。



不包括：从多个来源收集数据的能力；构建多维数据集和交互式分析



我们有理由相信，EPM（如BI）的概念被认为是ERP之外的东西。但是现在边界变得越来越模糊，EPM功能甚至整个产品都可以作​​为模块包含在ERP系统中。

1C：SCP

UPP实施以下方案，但要在一个基础之内。





数字：8. 1C中预算的体系结构：UPP UPP



中预算的优势：

• SCP非常透明，易于修改。验证其中的数据很容易，并且开发新功能非常便宜。

映射-在SCP中处于平均级别。这不是加号或减号。设定平均劳动强度。



SCP中预算的缺点：

• 缺乏投入产出的互动形式。任何数据的创建都是通过文档（输入计划；获取汇总的实际数据；执行计算）进行的，这些文档之间没有交互作用，也没有交互作用，并且具有查看大图的能力。
• 缺少ETL接口。有映射，但是实际数据是直接从文档表单加载的，这很不方便。
• 旧平台。您无法使用1C托管表单技术，该技术为用户提供了现代的列表和报表过滤/排序功能。这降低了用户的分析能力。

总的来说，在SCP中，预算的自动化是根据普通会计原理最清楚地实现的：用户不是根据一般情况工作，而是根据主要文档（输入计划;加载事实;估计）进行工作，而一般情况只能在无法输入任何内容的报告中看到。

1C：ERP

据我所知，ERP最初仅提供“在线”报告模型。如今，在许多公司中，主要情况就是这样。尽管如此，现在程序允许中间存储计算值。





数字：9. 1C中预算的体系结构：ERP 1C



中预算的优势：ERP：

• 投入产出的充分功能形式

1C中预算编制的缺点：ERP：

• 模型的刚性。原则上，就像在大多数ERP系统中一样，预算模型不能容忍频繁的更改，而对预先设定很挑剔
• 弱映射。由于某些原因，映射功能比UPP差
• 产品硬度。与SCP不同，在这里重新设计方法框架非常困难且昂贵。您需要研究现有的一口井，并在1C：ERP（如果确实适合公司）的基础上建立预算
• 性能。交互式表单功能非常强大，但是技术设备使它们在处理大量数据时极其缓慢

同样在1C：ERP中，在设置组织预算流程（工作流）和多用户工作方面没有重要的功能。例如，批准过程包含在单独的产品1C：文档管理中，通常在ERP上实现。

1C：CA

集成自动化是1C：ERP的简化版本，因此其开发遵循相同的路径，并且这里没有自己的预算方法。

MS Axapta / MS Dynamics AX

只有一个“在线”模型可以查看实际预算数据-它们直接从其自己的会计模块中读取，而没有提供进行严重转换的可能性。





数字：10. MS Dynamics中的预算体系结构



系统的正负都是其自身的Dynamics会计模块及其现成结构的“锐化”。



优点：

• 与会计模块集成。从ERP系统的各个模块获取实际数据的设置非常简单。
• 积分。从外部系统加载现成的计划有很多可能性。因此，Microsoft显然遵循EPM与ERP分离的逻辑，因此EPM系统非常适合“动态”
• 工作流程。预算流程功能齐全且透明的可自定义组织模型

缺点：

• ETL。通常，该产品不提供有意义的数据转换功能
• 产品硬度。这里设置了一种现成的，但方法很有限的方法。而且（例如在1C：ERP的情况下）不仅很难对其进行回收，而且实际上毫无意义。

SAP S4 HANA

替代ERP系统SAP R / 3的主要SAP产品。



为了进行预算，现在使用了单独的EPM产品，在台式机版本（SAP BPC）中，仍可以将其视为ERP上“独立”的单独的EPM系统，但是在云版本（SAP Analytics Cloud）中，它最终已经集成到ERP系统中（在SAP S4中） HANA云）。有关SAP BPC的更多详细信息将在下面。



重要的是要对S / 4 HANA本身进行一些说明：SAP将ERP系统的所有工作从关系数据库转移到组合数据库（关系，列式和多维的混合）。这样的组合数据库是专有的SAP HANA技术（请勿与S / 4 HANA混淆），根据用户操作，该技术既可以用作事务处理（会计系统），也可以用作分析系统（多维数据集）。



因此，SAP正在转向与“正常”实践中众所周知的体系结构相反的体系结构。在其中，分析数据库不是建立在存储“ SAP BW”之上，而是在ERP系统“之下”实现。在这种情况下，当用户使用来自EPM系统的数据时，数据仓库（SAP BW）会将用于计算的数据传送回此原始组合数据库。



实际上，SAP通过与RAM相反的方式实现了与IN-Memory OLAP相同的效果：通过最大化RAM中的计算。

甲骨文云ERP

Oracle还采取了将EPM系统嵌入ERP的方法。



该公司正在积极地将其产品迁移到云版本（也许比SAP更加积极）。因此，对于其主要的EPM解决方案Oracle Hyperion（我们还将在下面讨论），该公司正在推广基于云的Oracle EPM Cloud形式的替代方案，该替代方案已包含在基于云的Oracle Cloud ERP中。

双系统

“纯”形式的BI系统（商业智能）是数据输出的一种方式。也就是说，BI是报表和仪表板设计器，它们通常还包含用于重组和分析数据的基本功能（例如，它们允许您联接表，查找平均趋势等）。



流行的BI系统：

• Power BI
• 画面
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

通常，BI连接到数据存储（关系和多维）或原始SQL表。因此，您可以参考足够详细的源数据（以在BI中已经聚合它们）。但是，复杂的条件转换（带有“ if”条件）与“经典” BI功能无关。如果您面临构建仪表板可视化系统的任务，最好在实施BI之前先构建一个转换。

EPM系统

EPM代表企业绩效管理。此外，还会遇到企业绩效管理（CPM）和业务绩效管理（BPM）等术语。



相当宽泛的术语可以暗示相关的功能，但是大多数情况下，此类系统可以视为交互式“计划事实”形式的构造函数。 EPM的概念尚未广为人知，但更正确地称为EPM系统，例如IBM Planning Analytics，Oracle Hyperion，Anaplan等解决方案，这些解决方案有时在业务智能的背景下被考虑。



有时EPM系统是为更广泛的目的而创建的（例如，SAP EPM或1C：控股管理），但是我们将在预算自动化系统方面准确地考虑它们。因此，尽管SAP本身将其称为包含SAP BPC的较大的SAP EPM产品，但我们将其称为EPM系统SAP业务计划与合并（SAP BPC）。



如前所述，BI不允许数据输入。EPM通常包括标准的BI功能，此外还提供输入和写入数据的功能。



著名的EPM系统：

• 甲骨文Hyperion
• IBM规划分析
• Anaplan
• SAP BPC
• 比特金融
• 1C：控股管理

让我们从小孩子开始。

比特金融

Bit。Finance是基于UPP预算方法的，但是，与之不同的是，首先，它是受支持和开发的，其次，它是作为ERP之上的EPM系统实现的（因此，它允许您整合来自各种外部来源的事实数据）。





数字：11. Bit.Finance



中预算的体系结构Bit.Finance中预算自动化的优势：

• 用于输入或读取数据的表单的构造方法。与UPP不同的是，此处没有固定会计凭证的形式，可以对其进行自定义，从而使它们成为相当方便的形式。
• 管理成本估算的界面。您可以在此处集中重新计算预算模型，而不必手动创建成本核算文档。

映射比SCP更加发达。



获取实际数据的方式有以下三种：

• 通过证据获取文件（如SCP），
• 并行会计。在此选项中，会计凭证在保存时会同时在会计记录簿和预算记录簿中创建条目。
• 广播方法。在此选项中，会计分类帐条目将转换为预算分类帐。

Bit.Finance中预算自动化的缺点：

• 浏览文件形式。尽管文档的形式已经变得灵活（请参见第一个要点），并且总体而言，在这方面，与SCP相比已经取得了很多进展，但就我们所希望的而言，该产品仍未偏离基于文档的工作模型。正如我们所说的那样，这对于预算是不方便的。
• 缺乏投入产出的互动形式。与1C：ERP不同，这里没有。

Anaplan

最近在全球市场上广受欢迎的旗舰产品。仅在云版本中提供。



与其他流行的解决方案（包括Hyperion和Planning Analytics）不同，它具有一些特定的专长：它最适合作为成本核算服务，使您能够快速自动地重新计算具有大量依赖关系的体积预算模型。





数字：12. Anaplan预算架构（流行的自动化方案）



优点：

• 成本核算。该产品专注于计算，并将所有数据存储在内存中的OLAP中，从而可以在线重新计算所有模型
• 团队合作（在准备计划数据之内）
• UX和自由格式建模。
• ETL。自己且非常方便的ETL工具
• 需要最少的IT支持。特别是在建模方面
• 成本。对于俄罗斯市场来说有点贵，但是与国际领先厂商（相同的Oracle Hyperion）相比，总拥有成本更低
• 实施速度。与Hyperion和Planning Analytics相比，该产品更易于使用和实施

缺点：

• 格式化
• 团队合作（就事件处理而言：通知，邮件等）
• 自定义公式语法。通常，从最终用户的角度来看，使用自己的代码始终是不利的。
• 层次结构。过去对于不同的预算模型使用不同的目录层次结构存在问题。这个问题对许多公司而言并不重要，但对某些公司而言却至关重要。也许（我希望如此）现在Anaplan已经解决了这个问题。
• Ad-hoc . , : Anaplan , .

Anaplan的优势和劣势都是其相对明确的专业领域，并且它并不侵犯公司的IT生态系统。优点是该产品已经明确定义了其功能目的，并且其发展方向是可以预见的。这是一项用于进行假设分析，计算和批准计划（预算）的服务，您需要基于此计划客户的体系结构。缺点是该产品无法替代功能完善的公司数据仓库，不能替代BI的所有功能，不能在其上构建复杂的公司ETL基础结构，甚至不能构建整个公司计算系统。如果不只在云版本中提供产品，那么所有这些都不会成为问题。



与Oracle和SAP（两者都声称是生态系统）不同，Anaplan并不强调在云与公司服务器之间轻松“移动”数据和工具的能力。因此，在他的案例中，云产品的缺点（考虑到关税，取决于服务器上使用的数据量）显得尤为明显。



由于它不能代替通用公司存储，因此在某些情况下，它可以用作将计划数据“添加”到公司自己的DWH中的计算服务，然后将数据从该数据传输到单独的BI系统以构建快速报告和仪表板。





数字：13. Anaplan预算架构（替代自动化方案）



通常，同时使用EPM和BI系统是一种常规做法。

甲骨文Hyperion

它至少有两个版本：Oracle Hyperion Planning和Oracle Hyperion Financial Management。

现在正在积极地被新的Oracle EPM Cloud产品取代。



由于生态系统主义，建筑可以采用多种类型，但是典型的建筑看起来像这样。





数字：14. Hyperion中的预算体系结构（可能的选项）



在图中，我以BI系统为例，因为Oracle Essbase分析数据库是BI工具中大数据分析的出色基础。



Oracle Data Integrator是作为ETL解决方案提供的，它充当Oracle生态系统中的通用数据集成机制。



Oracle Hyperion中预算自动化的优点：

• 生态系统。在Oracle方面，我会指出它的优点，因为Oracle是最大的数据库供应商之一，对于使用Oracle DBMS的公司（还有很多这样的公司）进行集成确实可以带来很多好处。特别是，在云和服务器之间分配功能更加方便。另外，同事们谈论了Oracle体系结构在安全性方面的相当大的优势（我不是专家，如果这里有任何内容，请指正）。
• 临时（“按需报告”）。

Oracle Hyperion中预算自动化的缺点：

• 生态系统。我还要注意一点，因为根据现有信息，Hyperion主要是由从事Oracle技术堆栈工作的公司选择的，并且从长期在非Oracle环境中使用Hyperion来看，效果可能会较小。
• . , Anaplan.
• . , UX ( ).

IBM Planning Analytics

主要用于大型企业，不是很容易部署和管理，而是功能非常强大的EPM系统。当前，IBM Planning分析是基于TM1技术（这是Cognos的核心）构建的。



对于ETL流程，IBM建议使用单独的产品IBM DataStage（以前由Cognos DataManager使用），Turbo Integrator，Cognos Integration Server或外部ETL工具。



典型的体系结构与Hyperion非常相似。





数字：15. Planning Analytics中的预算架构（可选）



IBM Planning Analytics的优势：

• 预测。
• 处理事件。
• 灵活性。产品在预配置方面不能被称为非需求产品，但是它会尝试适应变化的模型。
• 不是生态系统。与IBM合作的惊奇之处在于，该公司生产的大量教学材料旨在描述IBM产品与其他解决方案（包括Oracle和SAP）以及各种问题进行交互的最佳实践。从我的主观观点来看，从长远来看，公司保持与第三方系统集成的发展趋势是个好习惯（这使我们能够支持公司开发的各种体系结构），而不是减少它。
• 产品支持。

缺点

• 复杂。与Hyperion一样：需要大量的用户培训，而不是最轻的基础结构。

SAP BPC

通常，SAP的显着特征是生态系统，解决方案的体系结构和基础架构的复杂性。



如前所述，SAP在不同时间支持并支持不同的体系结构选项。根据最新信息，该架构的旗舰版推荐的供应商今天这个样子的：





图。15. SAP业务规划和咨询中的预算架构（示例）



基于SAP BPC的预算优势：

• 数据整合。尽管很复杂，但它功能强大且速度很快，这对于大公司而言至关重要。
• 可视化。
• 工作流程。

基于SAP BPC的预算编制的缺点：

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• 价钱。就总体拥有成本而言，它实际上是世界上最昂贵的EPM系统之一，受体系结构变化的影响。

ETL工具

众所周知的ETL工具用于构建ETL流程，其中有许多来自同一供应商的产品会产生BI / EPM解决方案：

• IBM DataStage
• Informatica PowerCenter
• 塔伦德
• 阿帕塔尔
• SAP数据服务
• Oracle数据集成商
• Microsoft Azure数据工厂
• 还有很多 博士

计划逐步更新本文，可能还会添加有关新产品的信息以及为从头开始预算而开发软件产品的原理。