第2回：管理会計システム構築における考慮点（1）

管理会計システムの勘所

2012.11.29

今年も冬がやってきました

11月も終わりに近づき、大分寒くなってきましたが、いかがお過ごしでしょうか？

毎年の季節の変わり目は、プロジェクトマネジメント上の難関の一つです。
風邪やインフルエンザの流行る季節がくると、必ず風邪で仕事に穴をあけるメンバーがちらほら。
システム開発の現場では毎年口をすっぱくしてメンバーに体調管理を促すのですが、如何せん言うは易しで、実際見えないモノと戦うのは至難の業です。

逆に私は比較的風邪をひかない方なので、時に自分の体の丈夫さを恨みたくなったりします。
しかし、この違いは何なのでしょうか？
俗によくいわれる体の変化に無頓着（おバカ？）説にも、自分で納得してしまう部分が多々あるのですが、できれば全力で否定したいところなので、他に理由を考えてみました。

１．職場が家から近く通勤経路が短いため、感染する機会が少ない。
２．働いてばかりなので、感染する機会が少ない。
３．晩酌のおかげで、感染する機会が少ない（アルコール消毒！）

…いかにも枯れた理由しか出てこないところに悲哀が漂います。
しかし、お陰様で最近はお客様先への訪問などで出歩く機会も増え、気をひきしめていかねば！と思っているところです。
みなさまも風邪にはくれぐれもご注意を。

さて、では前回予告の通り、今回は予算管理システム構築の例に触れつつ、私なりの勘所をご紹介してみたいと思います。

構築事例その１：管理会計システムのニーズ例

今回ご紹介する事例は、構築当初、たくさんの課題をいかにしてクリアするか、苦労した案件です。
管理会計システムの構築におけるニーズとしては一般的な部類かと思いますが、

「来年度予算を昨年実績と対比して作りたい。」
「レジ番号別の売上計画と実績を集約したい。」
「トップダウン予算とボトムアップ予算を対比して予算を作りたい。」

といったお客様のご要望があり、いかに答えていくかが課題でした。

この事例では、多次元データベース「Oracle Hyperion Essbase（以下、Essbase）」と、データ加工を行うETLツール、「Waha!Transformer」を使用し、フロントエンドは「Essbase」のスプレッドシートアドイン機能を用いて「ExcelVBA」でカスタマイズして構成しました。

「Essbase」は高額ながら、アーキテクチャが管理会計にマッチする部分が多いため、この分野ではかなりのシェアを持っています。デファクトスタンダードといってもよいと思います。

（Essbaseに代表される多次元データベース　(M-OLAP（※）製品、あるいはRDBと対比してMDBとも呼ばれる)　についての詳細はまた別の回で触れます）

※OLAP：OnLineAnalyticalProcessingの略。いわゆるオンライン多次元分析。
RDB（リレーショナルDB）を用いたものをR-OLAP、MDB（多次元DB）を用いたものをM-OLAP、両者を組み合わせたハイブリッドのH-OLAP等のカテゴリがある。

勘所１．大規模な組織階層

管理会計では、「予算をどういった単位で立てるのか」、というところが重要です。
シンプルな例では「組織別、月別、科目別」でしょうか。

簡単に表現すると、「○○部では、月々の売上はこれくらい、経費がこれくらい」
というように部門単位で予算を立て、すべての部門分を集めると、最終的に「全部の部門を合計して、全社ではこれくらい。」という全社サマリの予算ができあがる、というイメージですね。

この事例では、このうち「○○部」にあたる組織の階層規模が大きく、○○部からさらに細かく、お店だったり、さらに人別や、お金の入ってくるレジの管理番号までが組織の階層に含まれていたりしました。
そんなわけで階層の末端は数万種類もの数にのぼりました。

しかも、ただそれだけではなく、組織階層の中身は移動します。

考えてみれば当たり前の話ですが、通常、「翌年度」の予算は「当年度」のうちに作成します。
予算編成が始まったタイミングで「当年度」はまだ続いていますから、「翌年度」以降の組織はまだ固まっておらず、しかも予算編成の状況によって、さまざまに組み合わせが変わる可能性がありました。

その一方で、今現在の実績をベースに収益を初めとする企業の状態を分析する場合は、今の組織階層で見たいというニーズもありました。

一般的に企業データを分析しようとすると、分析用データベースは、汎用機やERP系の基幹システムから受け取ったマスタデータをもとに、階層構造を実装して作成したりしますが（Business Intelligenceの分野がまさにコレです）いざ予算を立てようとしたときは、今時点のマスタだけでは足りません。

ところが、予算管理の目的のひとつである、「実績と対比してパフォーマンスを測り、PDCAサイクルをまわす」ということを実際に行う場面では、「データを一元化して組織階層をサマリから詳細までシームレスに見たい」というニーズの方が強くなります。

この両方のニーズに一遍に答えるべくデータを一元化しようとすれば、組織の階層を個別に持つか、なんらかの形で差異を吸収することが必要になります。

この事例では、当期の収益分析用に、実績分析DBと予算編成DBをそれぞれ分けて実装することになりました。
また、予算編成にあたって、「現行の組織マスタから、移動や新設する組織を追加・管理できるツール」を実装し、当年度の実績データを付け替えて、人や管理単位の移動を加味した実績データと対比しながら、例えば「今年よりも10%アップする予算を作成する」といったことが可能になる仕組みを実現しています。

実際の開発時にはスケジュール終盤に近いところでこのツールの必要性が認識されたため、泣きながら会社で年越しをした思い出があります（笑うところです）。

組織移動に関わる運用規模の大きい会社の場合は明らかに負荷がかかる部分だと考えられるので、ある程度自動化、あるいは機能化するといった例は他社事例でも結構あるのではないかなと思います。

予めこれらをしっかり考慮して、検討に臨まれることをお勧めします。

勘所2．組織以外にも…セグメントの変化

管理会計は企業のモノサシということを前回書きましたが、つまるところ、その用途はそのモノサシに沿って予算や目標を立て、実績と対比して進捗を測るということです。

どういう単位で立てるかは、企業や業態によって変わってきます。
いわゆる「セグメント」（事業区分）がそれにあたる事が多いですね。
厳密には組織もセグメントのひとつですが、これはどんな会社にもありますから、各企業で異なってくるのは組織以外の「セグメント」です。

代表的なのは、「ビジネスのカテゴリ」別の目標値（組織とは異なる括りの各事業セグメントで個別の目標値があったりするケース）、あるいは顧客をカテゴリ別に分け、カテゴリ毎に目標を立てるケース。あるいは扱う商品のカテゴリ別に目標を立てていたり、地域で分けていたりと業態によって様々に変わります。また、更にデータの粒度によっても分けられますね。

これら、管理会計システムに実装される「モノサシ」が、その企業の事業内容にきちんと合致したものであれば、意思決定者は、パフォーマンスを的確に把握し、必要なときに必要な手を打つことができます。
その構成は業態によって様々ですが、基本的には上記のセグメントの組み合わせでほとんどのケースが構築されます。

（少し前に手がけた案件で更に独特なセグメントを実装した企業もありますが、少々特殊な業態かつ結構先進的な話になるため、これは当コラムの別の回で触れたいと思います）

前述の「組織」の変化に限らず、これらのセグメントも日々変化していきます。
会計期間毎の戦略によって、扱う商品も変わるかもしれませんし、攻めるべき顧客のカテゴリも変わるかもしれません。
そして、それらの戦略をどう変えて行くかは、意思決定者や管理者が、企業活動をどういったモノサシ（＝セグメント）で捉えているかに大きく左右され、状況によって柔軟に変化していくものです。

…そう、意思決定者や、管理者が何を重視するかでセグメントは常に変化するのです。
こうした変化はどんな企業にもありますが、これが管理会計システムの構築を難しくする、最大の要因かもしれません。

そして、これらの変化の度合いを事前にどの程度織り込むか、あるいはすっぱり切り捨てるかを、適切にジャッジできていることが、扱いやすいシステムを作るコツのひとつ、といえるでしょう。

更に言えば、昨今の不確実な経済環境・経営環境の中で、変化しないままのモノサシをずっと使い続けることのできる企業は、そう多くないのではないか？とも思います。
「変化に対応できてこその管理会計システム」といえるかもしれません。

勘所3．インプットの粒度と負荷

データベースはインプットが無ければ始まりません。
インプットの粒度が細かくなればなるほど、経営者をはじめとする意思決定者や、各組織の管理者は、こうした予算管理単位で実績を比較し、今現在の状況がどうなっているかを的確に測る事ができるようになりますが、そこで「待った」がかかります。

忘れてはいけないのは、そもそも「その予算を誰が立てるのか」「実績は誰が入力するのか」、という点です。インプットの粒度が細かければ細かいほど、「入力する人」の負荷が高まるのです。

ちなみに、いままで扱ってきたシステムを見ていくと、企業の規模が大きくなればなるほど、予算編成単位は細かくなる傾向がありますね。

矛盾するように思えますが、規模が小さいうちは、粗い単位で予算を立てていても案外、まわってしまうものです。そんなに細かい単位で予算を立てなくてもコントロールできるからです。
むしろ、企業の規模に合わないあまりに細かい予算管理では、管理のためのコストばかりが増大し、結果として本末転倒な事態を招きかねません。

ですが、規模が大きくなると、専任の予算担当者を配置するほどのコストをかけてでも、コントロールするためのモノサシには精度が求められてきます。

少し具体的にいうと、例えば、全社で組織が10個くらいしかない会社と1000個もの組織単位を持つ会社では、勘定科目一つ取ってもサマリするとその金額には莫大な開きがあります。
規模が大きければ大きいほど、より細かい単位に分けないと、コントロールしづらくなってしまう、というわけです。

とはいえ、現場の予算担当者は大変です。細かければ細かいほど、負荷は上がりますから、大規模な企業向けのシステムでは、簡単に入力できることが大事だったりします。
（フォームの整備、あるいはオートコンプリート等の機能実装、はたまた、それぞれ別個のシステムで同じものを入力する等の負荷軽減を考慮）
また、予算の単位自体をどこまで入力できるかで調整する、といった考慮が必要になり、結果として運用コストも開発の難易度も上がっていく、という構造になるわけです。

これらのバランスを、各企業の現場に合わせてコーディネイトするのも重要なポイントですね。