業務分析(経営分析)のシステム的側面 | Technolog.jp - ICTウェブマガジン

業務分析(経営分析)のシステム的側面

今回は、業務分析(経営分析)をシステム的側面から見た場合にどういった仕組みが必要になるかを簡単に述べたいと思います。

まず、分析をするためにはその元ネタとなるデータが最重要要素となります。そのデータとは日々の販売データ、在庫データ、顧客データなどであったりするわけですが、この精度が低いと分析も意味をなさないものになってしまいます。コンビニや店舗販売を展開する企業などではPOSを導入して、そのデータが直接または間接的に基幹システムへ送られるため、精度の高いものが期待できるのですが、人間が手入力で行った場合、入力ミスや誤字脱字などで同一商品が別物として取り扱われ、売上がバラバラになってしまうこともあります。

そして、次の工程として重宝されるのがETL(Extract : 抽出, Transfer : 変換, Loading : 読込)と呼ばれるツールです。基幹系システムのデータはたとえPOSなどを利用しても分析向けに加工する作業が発生します。異なるシステム間で商品コードの統一を図ったり、特殊なアルゴリズムのために新たなコードを作成したりとデータに対するお化粧を施します。そして、最終的に分析用データベースに(*1)格納される。

これまでの工程は分析に必要とされるデータの土台作りだったわけですが、ここからは実際に利用者の目に触れるアプリケーション(インターフェース)作りになります。WEBシステムであれば、自社でPHPやJAVAなどを用いて独自の画面を用意するのでしょうが、この開発にはとんでもない工数が必要とされてくるため、企業ではパッケージベンダーが販売するソフトウェアを利用することが多いようです。

代表的な製品としては、SAP/BW, BusinessObjects, Cognosなどがあるのですが、これらは開発に独自の設定が伴うのため、ベンダー側から認定資格を発行しています。そして、最終的に利用者の目に触れるレポートを作成していきます。

上記は一般的な開発工程になりますが、業務要件を取りまとめる際には逆の順序を取ることをお勧め致します。つまり、まずは分析レポート要件をヒアリングし、それに必要なデータの選別を行います。基幹系システムにも業務上必須要件が存在すると思いますので、両者の業務要件定義が完了した段階でお互いのデータの照らし合わせ、基幹系で網羅できる部分はそちらに任せ、それ以外の部分をETLまたはDWH上でどのように生成するか検討します。

このようにしてサービスを開始していくわけですが、開発の現場ではプロジェクトの体制やコントロールにそれ以上の苦労が伴います。

(*1) 分析用データベース
DWH(データウェアハウス)などといった呼び方をする場合もあります。通常、基幹系システムは日々の業務で使用されているため、トランザクションが多く、余計な負荷をかけてしまうとレスポンスの低下にもつながります。また、分析には複雑なSQLの発行が伴うため、この二者を同一のデータベースおよび筺体(サーバ)で運用することは好ましくありません。

KEYWORD