記事の内容はなんですか？

これは、「予算の自動化」とは何か、この領域がどのような問題で構成されているか、およびそこで使用されているITツールについての一般的な記事です。



BI、データウェアハウス（DWH）、予算編成自動化システム（Cognos、Anaplan、1C：Holding Management、Bit.Finance）がどのように相互接続され、他の企業情報システムとどのように異なるかを理解したい場合は、こちらをご覧ください。



あなたがビジネスプランニングの主題分野で働いたことがないテクニカルアーキテクトである場合、この記事もあなたのためです。





誰もが理解できるように、できるだけ簡単な言語で記事を書こうとしたことをすぐに警告します。

なぜ私はそれを書くことにしたのですか？

今日、この分野の短い体系的な説明は事実上ありません。それは質問に対する明確な答えを与えるでしょう：

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

アカウンティングとプランニングのアーキテクチャ上の違いは、アカウンティングデータがボトムアップで流れることです。質の高いレポートを取得するには、可能な限り詳細な事実の記録を整理する必要があります。次に、単純な集計によって、要約情報（マネージャーにとって重要）を取得できます。



したがって、アカウンティングでは、ドキュメント->テーブル（登録）->レポートスキームが最適に機能します（これは、自動化のずっと前に、中世のアカウンティングで使用されていました）。





図：1.会計スキーム「ドキュメント->登録->レポート」





計画は当初拡大されました。したがって、正確に「上から」（つまり、レポートが生成されるのと同じ形式で）入力すると便利です。



したがって、従来の会計と同様に予算の自動化を構築しようとすると（図3）、企業はすぐに3つの重要な問題に直面します。





図： 3



問題1：ルールの管理。レポートコードに記述されているデータ変換のルール（最低レベルの会計から予算編成形式へ）を管理することは、非常に不便で面倒です。



問題2：「事実の収集」の速度。計画はレポートに非常にすばやく表示され（すでに拡大された形式で保存されているため）、実際のデータの計算は非常に遅くなります。



問題3：エントリーフォームを計画する..。計画を入力するための最も便利なフォームは、計画事実レポートです。ただし、情報システムのレポートでは通常、データ入力は許可されていません。



最初の2つの問題は、予算編成に関連するだけでなく、一般に、データウェアハウジング、データ統合、およびETLの主題領域全体の基礎を表しています。



3番目の問題は特定の計画の問題です。これは、実際、リアルタイムツールとしてのERPシステムの重要な問題の1つです（発生したイベントの「死後の」アカウンティングだけでなく、ビジネスの計画と運用管理も目的としています）。

問題1：変換ルールの管理

図では 1〜3では、実際のデータを変換するためのすべてのルール（最低のアカウンティングレベルから最高のレポートレベルへ）は、レポートコードに正しく記述されています。



これは悪いです：

• コードを変更せずにルールを管理することはできません。
• これらは、このレポートでのみ使用できます。
  つまり：

  – , , ,
  
  – - ,
  
  

変換ルールの複雑さ

ここで、変換ルールが実際に非常に複雑になる可能性があることを考慮することが非常に重要です。変換は、必ずしもデータの単純な集約ではありません（日から月、部門から組織、倉庫から地域、製品ラインから記事など）。これは、管理会計が会計に基づいていることが多いCISで特に顕著です。次に、さまざまな会計の詳細のさまざまな組み合わせから、管理会計のさまざまな値を決定できます。





そのようなコードを維持することはプログラマーにとってどれほどの問題であるか想像できます。そのような記事が数百ある場合、それらは12の異なるレポートで使用され、管理会計でそれらを決定するためのルールは3〜4か月ごとに調整できます。

問題1の解決策：マッピング

この問題を解決するために、マッピング（異なるレベルのフィールドおよび/またはアカウンティングとレポートのタイプ間の対応）をレポートから取り出し、個別のオブジェクトとして作成し、個別に構成および保存して、必要に応じてそれらを参照できます。





図：4



これには一度に2つの利点があります。

• ルールの管理は簡単です。コードなしでインタラクティブに構成できます。つまり、通常のユーザーでも実行できることがよくあります。
• 1つのルールをさまざまなレポートやその他のアルゴリズムで使用できます

このアプローチには重大な欠点はありません。



しかし、大量のディレクトリを便利にマッピングするためのツールを開発するのは簡単ではありません。

問題2：実際のデータの変換速度

問題2の解決策：変換されたデータの保存

「オンザフライ」でレポートデータを計算しないようにするために、レポートデータはすでに拡大および変換された形式で保存できます。



これを行うには、ソーステーブル（社内で引き続き必要）に加えて、集約された実際のデータを格納するためのテーブルを作成する必要があります。これらは個別のテーブルであり、「計画」と集約された「事実」の両方の一般的なテーブルです。



もちろん、これらのテーブルは最初に何らかの方法で入力する必要があります。このために、レポートを生成するときに以前に実行したのと同じ変換手順を実行しますが、ここでは別のバックグラウンドプロセスに移動します。





図：五

DWH

この問題に関連するのは、データウェアハウス（DWH）ドメインです。



大まかに言えば、DWHは、中間の計算された（集約された、または何らかの方法で変換された）データを格納するための場所（テーブル、または実際には関連するテーブルのセット）です。



長所は何ですか：

• データの読み取り速度。レポートがすでに変換されたデータをテーブルから「読み取る」場合、レポートは非​​常に迅速にそれを行います。
• 検証可能性。データがウェアハウスに事前に保存されていると、検証が容易になります。

マイナス：

• 正確さ。実際、このマイナスはかなり理論的なものです（非常に主要な情報源からデータを取得するときに、最大の精度が正確に保証されます）。
  練習中

  , ; , . , , , .
• メモリを読み込んでいます。したがって、集約されたデータを保存するために、ハードドライブの余分なスペースを浪費します。また、実際には、むしろ理論上の欠点です。
• 復号化。レポートを集約テーブル（ソースドキュメントに従ってデータが詳細化されていない）に接続すると、それらの復号化（ドリルダウン）の可能性に問題が発生します。

ETLプロセス

ETLは、データがどこかから取得され、変更されてからどこかにロードされる任意のプロセスと呼ぶことができます。これは、Extract、Transform、Loadの一般的な略語です。



ただし、通常、この用語は、変換後のデータがストレージ用にどこかに書き込まれる場合に正確に使用されます。



このアプローチには利点があります。

• システムの負荷の分散。変換プロセスは時間の経過とともに拡大します。集計されたテーブルは、（元のアカウンティングシステムでデータを変更/追加するときに）段階的に、またはスケジュールに従って埋めることができます。たとえば、サーバーが「無料」の場合、複雑な計算を夜間やその他の営業時間外に延期することができます。これにより、システムの負荷を管理できます。
• 1回限りの変換。要約情報を集約テーブルに書き込むと、さまざまなレポートからアクセスできます。したがって、同じ変換を何度も実行する必要はありません。

マイナスは1つだけです。

• ロードされたデータの整合性を制御することの複雑さ。データを失わず、十分に透過的で制御可能な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は次のスキームを実装しますが、1つのベース内にあります。





図：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：Workflowに含まれています。これは通常、ERPの上に実装されます。

1C：CA

Integrated Automationは、1C：ERPの簡略版であるため、その開発は同じ道をたどり、独自の予算編成方法はありません。

MS Axapta / MS Dynamics AX

予算の実際のデータを表示するための「オンライン」モデルのみを提供します。これらは独自のアカウンティングモジュールから直接読み取られますが、深刻な変革の可能性は提供されません。





図：10. MS Dynamicsの予算編成のアーキテクチャ



システムのプラスとマイナスの両方が、Dynamicsの独自のアカウンティングモジュールとその既製の構造に対する「シャープ化」です。



長所：

• アカウンティングモジュールとの統合。ERPシステムのさまざまなモジュールから実際のデータを取得するための設定は非常に簡単です。
• 統合。外部システムから既製の計画をロードする機会はたくさんあります。したがって、MicrosoftはEPMをERPから分離するという論理に明確に従っており、その結果、EPMシステムはDynamicsに非常によく「ハング」しています。
• ワークフロー。予算プロセスの十分に機能的で透過的なカスタマイズ可能な組織モデル

マイナス：

• ETL。一般に、この製品は意味のあるデータ変換機能を提供しません
• 製品の硬度。既製ですが、かなり限定された方法論がここに設定されています。そして（1C：ERPの場合のように）それをリサイクルすることは難しいだけでなく、実質的に無意味です。

SAP S4 HANA

ERPシステムSAPR / 3に取って代わった主要なSAP製品。



予算編成のために、別のEPM製品が使用されるようになりました。これは、デスクトップバージョン（SAP BPC）ではERPの「上」にある別のEPMシステムと見なすことができますが、クラウドバージョン（SAP Analytics Cloud）では、最終的にERPシステム（SAP S4）に統合されています。 HANAクラウド）。 SAPBPCの詳細は以下のとおりです。



S / 4 HANA自体について別のことを言うことが重要です。SA​​Pは、ERPシステムのすべての作業をリレーショナルデータベースから結合されたデータベース（リレーショナル、列、および多次元の混合）に転送します。このような結合されたデータベースは、独自のSAP HANAテクノロジー（S / 4 HANAと混同しないでください）であり、ユーザーのアクションに応じて、トランザクション（アカウンティングシステム）または分析システム（キューブ）のいずれかとして機能します。



したがって、SAPは、現在「通常の」慣行でよく知られているものとは逆のアーキテクチャに移行しています。その中で、分析データベースはストレージ（SAP BW）の「上」に構築されていませんが、ERPシステムの「下」に実装されています。この場合には、データウェアハウス（SAP BW）、ユーザは、EPMシステムからの彼のデータで動作する場合、計算のためにデータを転送するバックこの元の組み合わせのデータベースへ。



実際、SAPは、RAMからの計算を最大化するという、逆の方法でインメモリOLAPが考案されたのと同じ効果を実現します。

Oracle Cloud ERP

オラクルはまた、ERP内にEPMシステムを組み込むという道を歩みました。



同社は製品をクラウドバージョンに積極的に移行しています（おそらくSAPよりもさらに積極的に）。そのため、主要なEPMソリューションであるOracle Hyperion（これについても以下で説明します）について、同社はクラウドベースのOracle CloudERPに含まれるクラウドベースのOracleEPMCloudの形式で代替案を推進しています。

バイシステム

「純粋な」形式のBIシステム（ビジネスインテリジェンス）は、データ出力の手段です。つまり、BIはレポートおよびダッシュボードの設計者であり、通常、データを再構築および分析するための基本的な機能も含まれています（たとえば、テーブルを結合したり、平均的な傾向を見つけたりすることができます）。



人気のあるBIシステム：

• Power BI
• Tableau
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

通常、BIはデータストア（リレーショナルと多次元の両方）または生のSQLテーブルに接続します。したがって、十分に詳細なソースデータを参照できます（すでにBIに集約されています）。ただし、複雑な条件付き変換（「if」条件を使用）は、「従来の」BI機能に関するものではありません。ダッシュボード視覚化システムを構築するタスクに直面している場合は、BIを実装する前に変換を構築することをお勧めします。

EPMシステム

EPMはEnterprisePerformanceManagementの略です。また、企業パフォーマンス管理（CPM）という用語や、あまり一般的ではありませんが、ビジネスパフォーマンス管理（BPM）という用語も使用されます。



関連する機能を暗示する可能性のある非常に広い用語ですが、ほとんどの場合、そのようなシステムは、インタラクティブな「Plan-fact」フォームのコンストラクターと見なすことができます。 EPMの概念はまだ一般的に知られていませんが、IBM Planning analytics、Oracle Hyperion、Anaplanなどのソリューションは、ビジネスインテリジェンスのコンテキストで考慮されることがあり、より正確にはEPMシステムと呼ばれます。



EPMシステムは、より広い目的で作成される場合があります（たとえば、SAP EPMまたは1C：Holding Management）が、予算の自動化のためのシステムの観点から正確に検討します。したがって、SAP Business Planning＆Consolidation（SAP BPC）をEPMシステムと呼びますが、SAP自体はこれをSAPBPCを含むより大きなSAPEPM製品と呼んでいます。



すでに述べたように、BIはデータ入力を許可していません。EPMには通常、標準のBI機能が含まれており、さらにデータを入力および書き込む機能を提供します。



注目すべきEPMシステム：

• Oracle Hyperion
• IBM Planning Analytics
• アナプラン
• SAP BPC
• Bit.Finance
• 1C：ホールディングマネジメント

小さなものから始めましょう。

Bit.Finance

Bit。FinanceはUPPの予算編成方法に基づいていますが、それとは異なり、最初にサポートおよび開発され、次にERPの上にEPMシステムとして実装されます（したがって、さまざまな外部ソースからの事実データを統合できます）。





図：11. Bit.Financeでの予算編成のアーキテクチャBit.Finance



での予算編成自動化の利点：

• データを入力または読み取るためのフォームのコンストラクタ。UPPとは異なり、会計文書の形式はここでは固定されていません。カスタマイズして、かなり便利な形式にすることができます。
• コスト見積もりを管理するためのインターフェイス。原価計算ドキュメントを手動で作成するのではなく、ここで予算モデルを一元的に再計算できます。

マッピングはSCPよりも開発されています。



実際のデータの取得は、次の3つの方法で機能します。

• （SCPのように）証拠取得文書を通じて、
• 並列会計。このオプションでは、アカウンティングドキュメントは、保持されているときに、アカウンティングレジスタと予算レジスタの両方に同時にエントリを作成します。
• ブロードキャスト方式。このオプションでは、会計元帳のエントリが予算元帳に変換されます。

Bit.Financeでの予算編成の自動化のデメリット：

• ドキュメントの形式を処理します。ドキュメントの形式が柔軟になり（最初のプラスを参照）、一般に、この側面ではSCPと比較して多くの進歩が見られたにもかかわらず、製品はドキュメント指向の作業モデルから私たちが望む限り逸脱していません。私たちが言ったように、これは予算編成に不便です。
• インタラクティブな形式の入出力の欠如。1C：ERPとは異なり、ここには何もありません。

アナプラン

最近、世界市場で大きな人気を博しているフラッグシップ製品。クラウドバージョンでのみ提供されます。



他の一般的なソリューション（HyperionやPlanning Analyticsを含む）とは異なり、わずかに特殊な専門分野があります。これは、多数の依存関係を持つボリューム予算モデルをすばやく自動的に再計算できる原価計算サービスとして最適に機能します。





図：12. Anaplan予算編成アーキテクチャ（一般的な自動化シナリオ）



長所：

• 原価計算。この製品は計算に重点を置いており、すべてのデータをインメモリOLAPに保存します。これにより、すべてのモデルをオンラインで再計算できます。
• チームワーク（計画データの準備内）
• UXおよびフリーフォームモデリング。
• ETL。独自の非常に便利なETLツール
• 最小限のITサポートが必要です。特にモデリングに関しては
• 費用。ロシア市場にとっては少し高価ですが、国際的なリーダー（同じOracle Hyperion）と比較すると、総所有コストは低くなります
• 実装速度。HyperionおよびPlanningAnalyticsと比較して、この製品は使いやすく、実装も簡単です。

マイナス：

• 書式設定
• チームワーク（イベントの処理に関して：通知、郵送など）
• カスタム式の構文。一般に、独自のコードを使用することは、エンドユーザーの観点からは常に不利です。
• 階層。予算モデルごとに異なるディレクトリ階層を使用すると、以前は問題が発生していました。この問題は多くの企業にとって重要ではありませんが、一部の企業にとっては重大です。おそらく（そう願っています）Anaplanはすでにこの問題を解決しています。
• Ad-hoc . , : Anaplan , .

Anaplanのプラスとマイナスはどちらも、比較的明確な専門分野であり、会社のITエコシステムを侵害しないという事実です。プラスは、製品がその機能目的を明確に定義しており、その開発の方向性が非常に予測可能であることです。これは、What-If分析、計算、および計画（予算）の承認を行うためのサービスであり、これに基づいて顧客のアーキテクチャを計画する必要があります。欠点は、この製品が本格的な企業データウェアハウスに取って代わることができず、BIのすべての機能に取って代わることができず、複雑な企業ETLインフラストラクチャが構築されておらず、実際に企業コンピューティングシステム全体に取って代わることができないことです。製品がクラウドバージョンでのみ提供されていなければ、これらすべては問題になりません。



OracleやSAP（どちらもエコシステムであると主張している）とは異なり、Anaplanは、クラウドと会社のサーバー間でデータとツールを簡単に「移動」する機能を強調していません。したがって、彼の場合、クラウド製品の欠点（サーバーで使用されるデータの量に応じた料金を考慮に入れる）が最も顕著に現れます。



ユニバーサルな企業ストレージに置き換わるものではないため、場合によっては、計画データを自社のDWHに「追加」する計算サービスとして使用できます。このデータは、別のBIシステムに転送され、クイックレポートやダッシュボードが作成されます。





図：13. Anaplan予算編成アーキテクチャ（代替自動化シナリオ）



一般に、EPMシステムとBIシステムの両方を使用するのが通常の方法です。

Oracle Hyperion

OracleHyperionPlanningとOracleHyperionFinancialManagementの少なくとも2つのバージョンがあります。

現在、新しいOracle EPMCloud製品に積極的に置き換えられています。



エコシステム主義により、アーキテクチャにはさまざまなタイプがありますが、典型的なものは次のようになります。





図：14. Hyperionの予算編成アーキテクチャ（可能なオプション）



図では、例としてBIシステムを示しました。これは、OracleEssbase分析データベースがBIツールでのビッグデータの分析の優れた基盤であるためです。



Oracle Data Integratorは、Oracleエコシステムのユニバーサルデータ統合メカニズムとして機能するETLソリューションとして提供されます。



Oracle Hyperionでの予算編成自動化の長所：

• エコシステム。Oracleの場合、Oracleは最大のデータベースベンダーの1つであり、Oracle DBMSに取り組んでいる企業（およびそのような企業が多数あります）の統合には本当に利点があるため、プラスとして注意します。特に、クラウドとサーバー間で機能を分散する方が便利です。さらに、同僚はOracleのアーキテクチャのセキュリティに関して非常に深刻な利点について話します（私はこれの専門家ではありません。ここに何かあれば訂正してください）。
• アドホック（「オンデマンドのレポート」）。

Oracle Hyperionでの予算編成自動化のデメリット：

• エコシステム。入手可能な情報によると、Hyperionは主にOracleテクノロジースタックに取り組んでいる企業によって選択されており、長期的にはOracle以外の環境で使用することから、影響が少なくなる可能性があるため、マイナスとしても注意します。
• . , 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 Business Planning＆Consoldationの予算編成アーキテクチャ（例）



SAP BPCに基づく予算編成の利点：

• データ統合。複雑ですが、機能的で高速であり、大企業にとって不可欠です。
• 視覚化。
• ワークフロー。

SAP BPCに基づく予算編成のデメリット：

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• 価格。総所有コストの観点から、それは実際には世界で最も高価なEPMシステムの1つであり、アーキテクチャの変更の影響を受けています。

ETL-ツール

よく知られているETLツールを使用してETLプロセスを構築します。その中には、BI / EPMソリューションを作成する同じベンダーの製品が多数あります。

• IBM DataStage
• Informatica PowerCenter
• タレンド
• アパタール
• SAPデータサービス
• Oracle Data Integrator
• Microsoft Azure Data Factory
• と他の多く 博士

記事は徐々に更新される予定であり、おそらく新製品に関する情報や、「ゼロから」予算を立てるためのソフトウェア製品の開発の原則が追加される予定です。