多軸単純集計キューブ

This page is in Japanese version. The English version is in preparation.

コンテキスト

経営管理の基礎には数値集計があります。各部署から集めた予算や見込み数値を集計する必要があるし、実績数値についても、多くの組織では財務会計システムや販売管理システムでの集計単位とは別の括りで集計する必要があります。売上高や粗利を商品群別に集計したいのだが、管理会計に必要な集計の括りは販売管理システムの商品マスター上の集計コードとして提供されていないか、あるいは、提供されていても責任部署の違いなどに起因して経営管理担当者が望むほどタイムリーには更新されず、結局、信用が置けないかもしれません

数値の集計は多軸で行われることがあります。売上高や受注高は、商品群別のほか地域別や得意先の業種別に集計したいかもしれません。それぞれの軸内に大分類＞中分類＞小分類といった階層を設けて、それに沿って集計できることが必要です。商品群は中分類別、得意先は大分類別といったように、軸ごとの集計階層を組み合わせて売上高などが集計され報告されます
事業部門別・地域別にP/Lの全科目値を集計して報告するといった実践もごく普通に見られます

集計数値は月次の業績報告など「レポーティング」に用いられます。レポーティングでは、事業部門別内訳、予実対比、月別推移というように、同一の基礎データにもとづいて様々な形式の報告資料が作成されます。こうした資料はふつうエクセルで作成されます

資料の作成単位は、データソースの種類とかならずしも一致しません。会計システムのデータは部門別に集計し、販売管理システムの売上データは、部門別だけでなく得意先（及びその分類別）、商品別に集計する場合、会計データと販売データを結合してひとつの報告資料に表示したいでしょう。たとえば、部門別P/Lの売上高の直下に、その内数として、主要な商品のその部門での売上高を表示したいかもしれません

問題

多軸での単純集計で、レポーティング業務を支援したい。 経営管理業務では、Excelが過剰に使われていて、エクセルメタボ状態になっています。エクセルメタボの主な症状は以下の通りです：

ファイルの肥大化 管理しているExcelファイル数が膨大。部門追加などちょっとした変更があちらこちらのファイルとシートに影響する。
動作の重さ ファイルが重くなりすぎて開くのに時間がかかる。外部参照が張り巡らされている
属人化 複雑な関数やマクロが組まれ、作成者以外メンテナンスできない
整合性の喪失 コピペミスによる数字の不一致が頻発、部門ごとにフォーマットが異なり集計ミスが発生
データトレースの困難さ エクセルシート上で販売データを毒時に集約して商品グループ別の売上高を集計して報告資料に表示する、といった場合、どの品目がどのグループに含まれているかわかりづらく、また、集約値からその詳細にドリルダウンすることが困難になりがち
業務の遅延 現場が入力したデータを経営管理用に転記する作業が多く、PDCAサイクルが迅速に回らない

上記のように列挙すると、現場レベルの問題に見えますが、属人化、整合性の喪失や、データトレースの困難さは、単なる現場レベルでの作業面の問題ではありません。経理・企画が提示する経営数値の信頼性が毀損され、経営報告が形骸化するというより深刻な問題につながっています

配慮すべきことがら

集計軸に関する制約の少なさ 集計の軸に関して制約が少ない方が望ましい。軸数自体に制約がないことが望ましく、軸に含まれるアイテム（多次元DBの用語で「メンバー」と呼びます）の数や集計の深さにも制約がないことが望ましい
同一軸内での任意集計 同一軸内で、複数の集計の仕方に対応できることが望ましい。たとえば店舗で区分されたデータは、地域別にも店舗の形態別にも集計できることが望ましい
同一軸内クロス集計 上述のように、同一軸内で、複数の集計の仕方に対応できた場合、さらにその組み合わせで集計できることが望ましい。上述の例で言えば地域別・店舗形態別それぞれで集計できるだけでなく、地域別勝つ店舗形態別にも集計できることが望ましい
期間軸での集計の特殊性 期間軸での集計は特殊である。月-四半期-半期-年度という通常の集計方法に加えて、10月度/年度累計、10月度/四半期累計、10月度/半期累計といった「累計」も用いられる。12月決算の場合、それぞれ、1月～10月、10月～10月、7月～10月が集計対象となる。また、期間軸での集計にあたってはフロー項目とバランス項目を区別する必要がある。第1四半期の値は、フロー項目の場合、1月～3月の合計だが、バランス項目の場合、3月値がそのまま第1四半期値となる
複数のデータソースからのデータの結合表示 複数のデータソースからのデータをひとつの報告資料上で結合して表示できること（「コンテキスト」の最終段落を参照）
データ取り込みの容易性 データは、ハンド入力あるいはExcelから投入したい場合もあるし、会計システム等の他システムから提供されたファイルから取り込みたい場合もある。こうしたケースに柔軟に対応できることが望ましい
データ種類の事後追加の容易性 会計システムのデータと販売管理システムのデータでは集計軸は一部異なる。例えば、部門という集計軸は両者で共通だが得意先と商品群は販売データのみで必要かもしれない。第1段階では会計システムのデータを対象にして、第2段階で販売管理システムのデータも取り込みたい。こうした場合、第2段階向けの設計まで見切らなければ第1段階を始められないのでは、プロジェクト進行が著しく困難になる。第2段階で必要な得意先や商品群といった軸は、第1段階時点では無視して設定を進められることが望まれる

解決策

集計軸をディメンションとして実装する。それらのディメンションを組み合わせた元帳、すなわち多次元のキューブを設ける

ディメンション内には、メンバーツリーと呼ぶ集計のためのツリーを作ることができ、これに沿った集計は、自動で、リアルタイムで行われます。データを末端レベルに入力すれば集計値は自動的に得られるわけです（必要であれば、集計レベルの数値を入力することもできます――Q＆Aの「集約科目で予算や見通しを入力することが出来ますか」を参照ください）

基幹系システムなどのデータは、Excel経由またはフォームを用いて元帳に取り込むことができます。インポートに際して、コード変換、データ集約も可能です

元帳に取り込んだデータは、フォームやExcelで表示することができます。フォームには簡易版とフル機能版があります。まずは前者から使い始め、慣れてきたら後者も使ってみるのが得策です。fusion_place のExcelアドインツールである Excel-Linkを用いれば、元帳のデータをExcelシート上で自由なレイアウトで表示することができます。既存の報告資料のセルに元帳のデータを表示することができ、逆に予算入力シートの予算値を元帳に反映することもできます

素直なキューブデザイン

ディメンションと元帳のデザインは素直に行うのが基本です。多次元DB製品では、データ量の制限から、複数の切り口――例えば、得意先と商品群――をひとつのディメンションに集約せざるをえないといったことが起きがちですが、fusion_placeの場合、そうした懸念は現実化しない場合がほとんどです

逆に、データソースとなる既存システムは、仕様上の制約によっていくらかいびつなデータの持ち方をしている場合もあります。こうした場合、fusion_place側では、本来望ましい形に変換してデータを散り込むことが、一般的には適切です

例として、ERPの「原価センタ」コードが部門コードと事業区分コードの組み合わせになっている事例に遭遇したことがあります。こうしたケースでは、fusion_place側では、部門と事業区分それぞれについて別個のディメンションを設けた方が、一般的に言って使いやすくなります。入力データを事前処理で加工して、部門コードと事業区分コードのフィールド（列）を分けて取り込むこともできますし、フル機能版フォームを使うなら、インポート処理の中で文字列処理によってコードを分解することもできます

補足：データ入出力へのアプローチ

アプリケーション構築をコンサルタントに依頼するのではなく、自力で取り組んでいく場合、本パターンを適用したシンプルなアプリケーションの構築がその第1歩となると思われます。そうした場合、データの入出力には、まずは Excel-Linkと簡易版フォームを用いることをお勧めします。そうすれば、習得すべき知識を限定することができます。少し慣れれば、他システムからデータを取り込む手段としても簡易版フォームを活用しましょう。次には、フル機能版フォームを使ってみましょう。ユーザーマニュアルの「Excel-Link とフォーム、どちらを使うか」もご覧ください

例

フュージョンズのWebサイト中「資料ダウンロード・ビデオ」ページに、多軸単純集計キューブを題材とするチュートリアルやサンプルアプリケーションがいくつかあります：

「トレーニング/学習」セクションからダウンロードできる「はやめぐり」は、シンプルな多軸単純集計キューブを題材としたチュートリアルです
「アプリケーションギャラリー」からダウンロードできる用途別アプリケーション「売上予算管理」は、小売業 (国産自動車ディーラー) を題材とした売上予算管理への適用例です。これも多軸単純集計キューブです

適用の帰結

利点

集計軸に関する制約の少なさ fusion_place では、ひとつの元帳に適用できるディメンションの数に制限がなく、その数が増えても、リソース（主にサーバーメモリー）の必要量が顕著には増えない（メモリー消費量は、キューブに実際に収容される集計前データの件数―セル数―に主に依存する）
同一軸内での任意集計 fusion_place では、ひとつのディメンション内に複数のメンバーツリーを設けることができる。メンバーツリー間でメンバーは共有できるので、店舗で区分されたデータを、地域別あるいは店舗の形態別に集計できる
同一軸内クロス集計 ひとつの元帳（キューブ）に、得意先と商品群のように複数のディメンションを適用した場合、ディメンション間でクロス集計が可能である。これは多次元データベースの一般的特性である。一方で、ディメンション内に複数メンバーツリーを設けた場合、それぞれのメンバーツリーに沿った集計は可能だが、それらのメンバーツリー間でクロス集計できるかは別の問題である。ここでの例にしたがえば、店舗のデータを地域と店舗形態の組み合わせでクロス集計することがそれにあたる。fusion_placeの場合、クロス集計は「ビュー元帳」という仕組みを使えば可能である。詳しくは、Q&A集の記事「クロス集計する方法」を参照ください
期間軸での集計の特殊性 fusion_place では、相対期間と表示形式という2つのディメンションを用いて、期間軸での特殊なデータ集計に対応できる。詳細は、ユーザーマニュアルの「期間表」のパートを参照ください
複数のデータソースからのデータの結合表示 元帳は複数設けることもできる。たとえば、P/Lのデータと売上の詳細データ用にそれぞれ元帳を設けることができる。それぞれを専用のアプリケーションに収容してもよいが、共通のディメンションを複数の元帳で共用したいのであれば、それらの元帳をひとつのアプリケーションに含める

キューブとデータソースは1対1に対応する必要はない。たとえば、P/Lデータと売上詳細データは、それぞれ別のキューブに取り込む方が一般的ではあるが、そうしなければならないわけではない。これら2種類のデータを単一のキューブに取り込むこともできる

元帳を複数設けた場合、複数の元帳のデータを結合して報告資料や照会画面に表示することができる。データを結合する際には元長間で共通のディメンションが結合キーを提供する
データ取り込みの容易性 データ取り込みは、Excelでも（Excel-link）、専用の画面（フォーム）、いずれでも行える。フォームを用いる場合、CSVやTSV形式のデータのインポートが可能である。インポートに際してコード変換も行える
データ種類の事後追加の容易性 fusion_place では、キューブの追加が容易である。第1段階では会計システムのデータを取り込むP/L元帳（キューブ）だけを用意し、第2段階で販売管理システムのデータを取り込む売上元帳を追加できる。このように元帳を分けておいても、共通のディメンション（例えば「部門」）を手掛かりに両元帳のデータを結合して、ひとつの画面や報告資料に表示することができる。キューブを分けた場合、ディメンションの共有ができず、複数キューブのデータを結合表示することが難しい製品もある。こうした製品では、事実上、単一のキューブにすべてのデータ収容しなければならない。そのため、第1段階で、将来にわたるすべての要件を見通した上でディメンションとキューブを設計することを強制される。fusion_place は、その問題を免れている