ビジネスインテリジェンス（BI）

ビジネスインテリジェンス（BI）は、企業が運営に使用するさまざまなビジネスシステムを通じて収集されたトランザクションデータに基づいて主に分析的なレポートを作成するためのエンタープライズソフトウェアの一種を指します。BIは、ITの専門家ではないユーザーにセルフサービスのレポート作成機能を提供することを目的としています。これらのセルフサービスの機能は、既存のレポートのパラメータを調整することから完全に新しいレポートの作成までさまざまです。ほとんどの大企業は、トランザクションデータベースの上に少なくとも1つのBIシステムを運用しており、これにはERPも含まれることがよくあります。

起源と動機

近代的な分析レポートは、20世紀初頭に主にアメリカで最初の経済予測者^{1 2}によって登場しました。この初期のバージョンは非常に人気があり、メインストリームの報道や広範な流通を受けました。この人気は、高情報密度の数量的レポートに対する明確な関心があることを示しました。1980年代には、多くの大企業がビジネス取引を電子記録として保存し、通常はいくつかの早期のERPソリューションを活用してトランザクションデータベースに格納し始めました。これらのERPソリューションは主に既存のプロセスを効率化し、生産性と信頼性を向上させることを目的としていました。しかし、多くの人々はこれらの記録にまだ未開拓の可能性があることを理解しており、1983年にSAPはERP内で収集されたデータに基づいてレポートを生成するためのABAP³プログラミング言語を導入しました。

ただし、1980年代に一般的に販売されていたリレーショナルデータベースシステムは、分析レポートの作成に関して2つの主要な制限がありました。まず、レポートの設計は高度に訓練されたITの専門家によって行われる必要がありました。これにより、プロセスが遅くなり、費用がかかり、導入できるレポートの多様性が厳しく制限されました。第二に、レポートの生成はコンピューティングハードウェアにとって非常に負荷がかかりました。通常、レポートは会社の業務が停止した夜間に（バッチで）のみ生成できました。これは一部は当時のコンピューティングハードウェアの制限を反映していましたが、ソフトウェアの制限も反映していました。

1990年代初頭、コンピューティングハードウェアの進歩により、異なるクラスのソフトウェアソリューションであるビジネスインテリジェンスソリューションが登場しました⁴。RAM（ランダムアクセスメモリ）のコストは着実に低下しており、そのストレージ容量は着実に増加していました。その結果、ビジネスデータの専門化されたよりコンパクトなバージョンをメモリ（RAM）に格納して即時にアクセスすることが、技術的および経済的な観点から実現可能なソリューションとなりました。これらの進歩により、10年前に実装されたレポートシステムの2つの主要な制限が解消されました。新しいソフトウェアフロントエンドは、非専門家にはるかにアクセスしやすくなりました。また、新しいソフトウェアバックエンド（以下で説明するOLAPテクノロジーを備えたもの）により、最大のIT制約のいくつかが解消されました。これらの進歩により、10年代の終わりまでには、BIソリューションは大企業の間で主流となりました。

コンピュータハードウェアが進歩し続ける中、新世代のBIツールが2000年代後半に登場しました⁵。1980年代のリレーショナルデータベースシステムは、便利にレポートを生成することができなかったが、2000年代にはビジネスの全トランザクション履歴をRAMに保持することがますます可能になりました。その結果、専用のOLAPバックエンドなしで複雑な分析クエリを数秒で完了することができるようになりました。したがって、BIソリューションの焦点はフロントエンドに移り、ますますアクセスしやすいWebユーザーインターフェース（主にSaaS（ソフトウェアサービス））を提供する一方で、リレーショナルバックエンドの柔軟性を活用したインタラクティブなダッシュボードが増えていきました。

OLAPと多次元キューブ

OLAPはオンライン分析処理の略称です。OLAPはBIソリューションのバックエンドの設計に関連しています。この用語は、1993年にエドガー・コッドによって作られ、1990年代以前の多くのソフトウェア設計アイデア⁶を統合しています。これらの設計アイデアは、1990年代にソフトウェア製品の異なるクラスとしてBIの出現に重要な役割を果たしました。OLAPは、レポートの作成に関与するデータ量が処理が迅速に行えるほど大きすぎる場合でも、タイムリーに新鮮な分析レポートを作成できるようにするという課題に取り組んでいます。

新鮮な分析レポートを作成するための最も直接的な手法は、データを少なくとも1回読み取ることです。しかし、データセットが非常に大きい⁷ために、データ全体を読み取るのに数時間（場合によっては数日）かかる場合、新鮮なレポートを作成するには数時間または数日かかることになります。したがって、秒単位で更新されたレポートを作成するためには、レポートの更新が要求された際に完全なデータセットを再度読み込むという手法は使用できません。

OLAPは、関心のあるレポートを反映したより小さく、よりコンパクトなデータ構造を活用することを提案しています。これらの特定のデータ構造は、新しいデータが利用可能になるたびに段階的に更新されることを意図しています。その結果、新鮮なレポートが要求された場合、BIシステムは完全な履歴データセット全体を再度読み込む必要はありません。代わりに、レポートの生成に必要なすべての情報を含むコンパクトなデータ構造のみを読み込むことができます。さらに、データ構造が十分に小さい場合、トランザクションデータ用の永続ストレージよりも高速にアクセスできるようにメモリ（RAM）に保持することができます。

次の例を考えてみましょう：100のハイパーマーケットを運営する小売ネットワークを想像してください。CFOは、過去3年間の各店舗ごとの1日あたりの総売上高をユーロで示したレポートを作成したいと考えています。過去3年間の生の売上データは、この期間におけるすべての店舗でスキャンされたすべてのバーコードを表す10億行以上のデータであり、生の表形式では50GB以上の容量があります。しかし、100の列（ハイパーマーケットごとに1つ）1095行（3年間×365日）のテーブルは、0.5MB未満です（数値ごとに4バイトの速度で）。さらに、トランザクションが発生するたびに、テーブルの対応するセルを適切に更新することができます。このようなテーブルの作成と維持は、OLAPシステムが内部でどのように見えるかを示しています。

上記のコンパクトなデータ構造は、通常、OLAPキューブまたは多次元キューブと呼ばれます。セルは、キューブの全体的な構造を定義する離散次元の交差点に存在します。各セルには、元のトランザクションデータから抽出された測定値（または値）が格納されます。このデータ構造は、ほとんどの主要なプログラミング言語で見られる多次元配列に似ています。OLAPキューブは、コンピュータのメモリに収まるほど小さければ、次元に沿った効率的な投影や集計操作（合計や平均など）に適しています。

インタラクティブなレポートとデータの可視化

BIツールの採用において、ITスペシャリストではないエンドユーザーに対してレポート機能を利用可能にすることが重要な要素でした。そのため、BIツールはリッチなユーザーインターフェースに依存するWYSIWYG（what-you-see-is-what-you-get）デザインを採用しました。これは、通常のリレーショナルデータベースとの対話方法とは異なり、専門言語（SQLなど）を使用してクエリを作成する方法です。OLAPキューブを操作するための通常のインターフェースは、スプレッドシートプログラムのピボットテーブルのような行列インターフェースであり、ユーザーはフィルタ（BI用語では「スライスとダイス」と呼ばれる）を適用したり、集計（平均、最小、最大、合計など）を実行したりすることができます。

特に大規模なデータセットの処理を除いて、OLAPキューブの必要性は2000年代後半には低下しました。この時期には、コンピューティングハードウェアの進歩に伴い、新しい「薄い」BIツールが導入されました。これらの薄いBIツールは、主にリレーショナルデータベースとの対話を目的として設計されており、OLAPキューブを活用した統合バックエンドを持つ従来の「厚い」ツールとは異なります。この進化は、当時のリレーショナルデータベースのパフォーマンスが、データセットが一定のサイズ以下に収まる限り、秒単位で複雑なクエリを実行できるようになったため可能となりました。薄いBIツールは、サポートされているさまざまなSQL方言の統一されたWYSIWYGエディタと見なすことができます（実際には、これらのBIツールはSQLクエリを生成します）。主な技術的な課題は、生成されたクエリの最適化によって、基礎となるリレーショナルデータベースの応答時間を最小化することでした。

BIツールのデータの可視化機能は、デスクトップアプリやWebアプリを介してクライアント側でのデータの表示に関するものでした。データの表示能力は、2000年代までにエンドユーザーのハードウェア（ワークステーションやノートブックなど）がデータの可視化に必要な計算リソースを大幅に超えるようになったことから、着実に進歩しました。現在では、最も複雑なデータの可視化でさえも、データの抽出と変換に関連する計算リソースの消費に比べれば取るに足らない処理です。

BIの組織への影響

アクセスの容易さは、多くのBIツールの採用において決定的な要素でしたが、大企業のデータの景色をナビゲートすることは困難です。なぜなら、利用可能なデータの多様性が非常に高いからです。さらに、BIツール自体は比較的アクセスしやすい場合でも、企業がBIツールを通じて実装するレポートロジックは、ビジネスの複雑さを反映しており、そのロジック自体が実行をサポートするツールよりもはるかにアクセスしにくい場合があります。

その結果、BIツールの採用により、ほとんどの大企業では専門の分析チームが設置され、通常はIT部門と並行してサポート機能として機能しています。パーキンソンの法則によれば、「作業は完了するために利用可能な時間いっぱいに広がる」ため、これらのチームは報告書の生成数に関係なく、時間とともに拡大する傾向があります。企業が報告書にアクセスすることで得られる利益（認識された利益または実際の利益）に関係なくです。

BIの技術的な制約

BIツールに関しては、しばしば利点とのトレードオフがあります。つまり、アクセスの容易さが増すほど、表現力が制限されるということです。この場合、データに適用される変換は、比較的狭い範囲のフィルタや集計に限定されています。これは最初の主要な制約です。多くの場合、ビジネスの問題はこれらの演算子では対応できません（例えば、「顧客の離反リスクは何ですか？」など）。もちろん、BIユーザーインターフェースに高度な演算子を導入することは可能ですが、そのような「高度な」機能は、非技術者の利用を容易にするという初期の目的に反します。そのため、高度なデータクエリの設計は、ソフトウェアの構築と同じくらい困難なタスクです。実証的な証拠として、ほとんどのBIツールは「生の」クエリ（通常はSQLまたはSQLに似た方言で）を書くことができる機能を提供しており、ツールが排除することが期待されていた技術的な手段に戻ることがあります。

2つ目の主要な制約はパフォーマンスです。この制約は、薄いBIツールと厚いBIツールの2つの異なるフレーバーで現れます。薄いBIツールには、生成されるデータベースクエリを最適化するための洗練されたロジックが通常含まれています。しかし、これらのツールは、バックエンドとして機能するデータベースが提供できるパフォーマンスに制限されます。一見単純なクエリでも、実行が非効率で、応答時間が長くなることがあります。データベースエンジニアは、この問題に対処するためにデータベースを変更および改善することができます。ただし、再び、この解決策は、非技術者の利用を容易にするという初期の目標に反します。

厚いBIツールは、OLAPキューブの設計によってパフォーマンスが制限されます。まず、多次元キューブをメモリに保持するために必要なRAMの量は、キューブの次元が増えるにつれて急速にエスカレートします。たとえば、中程度の数の次元（10個など）でも、キューブのメモリフットプリントに関連する深刻な問題が発生する可能性があります。一般的に、インメモリ設計（OLAPキューブが最も一般的です）は、メモリに関連する問題を抱えることが多いです。

さらに、キューブは元のトランザクションデータの損失のある表現です。キューブで行われる分析では、元々失われた情報を回復することはできません。ハイパーマーケットの例を思い出してください。このようなシナリオでは、バスケットをキューブで表現することはできません。したがって、「一緒に購入された」情報は失われます。OLAPの「キューブ」全体の設計は、表現できるデータを厳しく制限します。ただし、この制約こそが「オンライン」の特性を可能にするものです。

BIのビジネス的な制約

会社にBIツールを導入しても、それほど変革的なものではありません。単に数字を生み出すだけでは、会社にとっては価値がありません。実際の行動に結び付けられていない限りです。BIツールの設計自体は「無限の」報告書の生成を強調していますが、BIレポートに基づいて何かを自動化する際には、BIツールの限定的な表現力が制約となることが多いです。

また、BIツールは大企業の官僚主義的な傾向を助長する傾向があります。実証的な証拠、おおよその数字、そして健全な判断は、会社の優先順位を確立するためにしばしば十分です。しかし、BIのような自己満足的な分析ツールの存在は、先延ばしをする機会を提供し、疑問の余地のある行動不能なメトリクスの連続的な流れで水を濁すことがよくあります。

BIツールは、プロジェクトに誰のアイデアも含まれる「委員会による設計」の問題に対して脆弱です。このツールの自己満足的な性質は、新しいレポートの導入において包括的なアプローチを強調します。その結果、レポートの複雑さは、それらのレポートが反映すべきビジネスの複雑さとは独立して時間とともに増加する傾向があります。虚栄心のあるメトリクスという用語は、通常BIツールを通じて実装されるような、会社の収益に貢献しないメトリクスを反映するために広く使用されるようになりました。

Lokadの見解

現代のコンピューティングハードウェアの能力を考慮すると、1日に100万個の数値を生成するためのレポートシステムの使用は簡単です。しかし、読む価値のある1日に10個の数値を生成することは難しいです。BIツールは、ほとんどの企業にとっては少量の使用が良いものですが、大量に使用すると毒になります。

実際には、BIから得られる洞察は限られています。ますます多くのレポートを導入することは、各追加のレポートを通じて得られる新しい（または改善された）洞察に関しては、迅速に収益が減少する結果となります。BIツールからアクセス可能なデータ分析の深さは、クエリがユーザーインターフェースを介して専門家でない人々に簡単にアクセスできるようにするために、設計上制限されています。

また、データを通じて新しい洞察が得られたとしても、それが会社に何らかの行動に変えることを意味するわけではありません。BIは、その本質的にはレポート技術であり、会社への行動への呼びかけを強調していません。BIのパラダイムは、ビジネスの意思決定を自動化すること（日常的なものさえも）には適していません。

Lokadプラットフォームの特徴には、BIのような独自のレポート機能があります。ただし、BIとは異なり、Lokadはサプライチェーンに関連するビジネスの意思決定、具体的にはサプライチェーンの決定の最適化を目指しています。

ノート