0.5秒でコネを検索。社内に埋もれた宝の山を掘り起こすデロイト

　
一見地味だけど、けっこう効きそう。そんな事例である。

世界4大監査法人のひとつである デロイト（Deloitte）のITリーダー、クリス・ディンケル氏が同社のSAP HANA活用事例について講演を行っている（2012年5月、SAPのカンファレンス Sapphire Orlandoにて）。その使い方がユニークで面白いので、かいつまんでご紹介したい。

詳しく知りたい方は下記の動画を参照のこと（英語、18分44秒、要ログイン（無料））。

Get the Inside Story on Deloitte’s Implementation of SAP HANA

http://www.sapvirtualevents.com/sapphirenow/sessiondetails.aspx?sid=2269

なお同講演の資料（PDF）はこちら。
http://sapvod.edgesuite.net/SapphireNow/sapphirenow_orlando2012/pdfs/22845.pdf

※以下の画像ファイルの出典はすべて上記PDFである。

-----

みなさんこんにちは、デロイトのクリス・ディンケルです。社内向けIT部門で、デロイト社員にビジネス・インテリジェンス等のサービスを提供しています。

当社では現在、3つのユースケースでHANAを活用しています。

■人脈／コネ検索（Contact and Influence Finder）

当社では、ある企業にアプローチしたい場合、コンタクトがある社員を探すために、全社員あてに一斉メールを送って、運がよければだれかが返信をくれる、といったことをやっています。しかしこのアプリケーションを使えば、わずか0.5秒で結果がわかります。

この業界に詳しくない方のために、少し解説を。

　デロイトは監査、税務、コンサルティング、財務アドバイザリなどのサービスを提供しており、その中核戦力はいわゆるCPA（公認会計士資格）を持ったプロたちである。
　一方、デロイトの顧客（直接のカウンターパート）はというと、企業の経理・財務部門が中心であるが、その中核メンバーや部門長もまたCPAであることが多い。
　さらに、人材の流動性が高いアメリカのこと、CPAたちは所属ファームを変え、また時には企業側に回ったり戻ってきたりしながらキャリアを積んでいく。
　つまり、大雑把にいうと、「あっち側もこっち側も元同僚」だったりするわけである。

　そういった状況の中、たとえば新規顧客A社を開拓しようとする場合、デロイトの営業担当はどうするか？A社の経理・財務部門に人脈／コネがあるデロイト社員をまず探す。そして見つかったら、そのツテを利用してコンタクトを試みるわけである。
　「もしもしジョン？デロイトのアリスだけど。3年前に、B社で一緒にプロジェクトをやってた... そうそう。お久しぶり！お元気？ところでさ、うちのトムっていう営業が御社に営業したいって言ってるんだけど、一度連れていってもいいかしら？」というわけだ。
　営業のトムにしてみれば、コールドコールをかけるよりずっと速くキーマンにたどり着ける。

　結果、デロイト社内では、毎日のように全社員あてメールが飛び交っている。全社員と言っても、北米だけで51,000人（！）もいるのだ。
　「今、A社にアプローチしてるんですが、誰かA社のキーマンにコネのある人はいませんか？...」と。そして運がよければ誰かが返信してきてくれてコネが見つかるが、みな多忙ゆえ、いつも見つかるわけでもなく...。

　この人脈／コネ検索は、こうした旧来のやり方を画期的に変えようとしている。

このシステムでは、構造化データとともに、非構造化データ（自由記入テキストなどの文字列）も扱っています。

データはSAPシステムだけでなく、非SAPシステム、さらには社外データなども取り込んでいます。

HANAのパフォーマンスを極限まで試すため、Universe は使わず、すべてのデータをHANAに直接持たせ、検索結果は SAP Crystal Report を使って整形して出力しています。

8つのテーブルから成り立っていますが、その中で最大のテーブルは「課金時間」つまり顧客への費用請求データで、1億2000万件あります。

このプロジェクトでは、いろいろと驚かされました。

まずプロジェクトの着想から完成までがわずか6週間だったことです。しかもそのうち3週間はハードウェアの調達にかかった期間です。アプリ開発は残りの3週間で完成しました。

HANAのデータ・モデリングツールを使っていますが、普通のデータベース製品と違って、HANAではデータモデリングがごく簡単で、早くて数分、長くても数時間で終わります。だから、設計にあれこれ悩むよりも、まず作ってみて、気に入らなければ捨てればよい。そんな感じです。

開発はすべて、デロイトの社内データセンターの中でやりました。すべてコンフィデンシャルなデータなので。

で、この1億2000万件のデータ全件をランク付けし並べ替えて表示するのに、10秒しかかかりません。

もし特定の1社だけに絞り込んでよければ、500ミリ秒以下になります。

また、全データをロードするのに15分かかりません。一括（バルク）ローダーを使わずに、です。

ご覧のように、データモデルはそれなりに複雑です。すべてをCalculation Viewに組み込んでおり、複数のテーブルをユニオンしています。

データソースは4つです。

SAP NetWeaver BWにある「稼働実績」データ、つまり誰がどのプロジェクトに入っていつからいつまで働いたか。

次がSQLサーバーのDBで、これは社内開発した顧客管理（CRM）システム。

3つ目がアルムナイ* データです。これは個人情報管理の側面もあるため外部委託しており、そこからCSVファイルでデータを受け取ります。

* アルムナイ（Alumni）とはもとは大学の「卒業生」のことだが、転じてデロイトなどの企業の”卒業生”つまりかつて在籍したことのある人、の意味で使われる。上述のように、過去のコネクションが仕事上大いに役に立つ業界なので、企業側もアルムナイとの関係を保つことに注力しており、アルムナイ側もまた同様である。デロイトでは外部に委託して、アルムナイの”卒業後”の履歴についても情報をアップデートする仕組みを持っているとのこと。

そして最後がレジュメ、つまり当社の入社する際の履歴書です。半構造化されており、いつ、どのプロジェクトで、どんなポジションで、誰と、働いたのか、を文脈から判断して取り込むようにしています。

現在アメリカでは履歴書もWebサイトから入力する形が当たり前になっており、そうでなくてもPDFファイルにしてメールで送るため、スキャンして文字データとして取り込むことができる。したがって「社員のCさんは2005年から2007年にかけてD社のEプロジェクトで働いていた」といった情報も取り込まれるわけだ。

結果画面はこんな感じです。特定の顧客（この例では CABOT Corporation）に対して影響力のあるコンタクトを持っていると推定される社員が、上から順に並んで出力されます。

■ベンダー分析

2つめは「ベンダー分析」です。こちらも、わずか2週間半でできました。

デロイトの社員は北米だけで51,000人ほどいますが、うち48,000人は毎週飛行機に乗っています。

コンサルタントは出張が多い職業として知られている。クライアントとなる大企業の本社が全米各地に分散しているため、毎週平日は客先近くのホテル暮らしで、自宅に戻るのは週末だけ、という生活パターンが常態化している。（そのため離婚も多いという話もあるｗ）

そんな業界事情があるため、飛行機、レンタカー、ホテルなどの出張経費は莫大である。

経費節減のため、社員はデロイトとコーポレート契約を結んでいる「指定ベンダー」を優先的に使うよう要求されていますが、経費監査チームが実態はどうか？をときどき確認しています。

コーポレートカードで精算された経費を全件HANAに読み込み、「指定ベンダー」がちゃんと使われているかを確認します。そのデータは、現在の試行環境では2,900万件。本番稼働時には5,000万件になる予定です。この膨大な量のデータに対して、HANAではどんな検索をかけても数秒以内に返ってきます。

従来はMS Accessを使って確認していたのですが、全件は処理しきれないため、ごく一部、1万件ほどの抽出データだけで確認していました。これが全件になれば、監査チームの作業効率や監査精度は格段に向上します。

さらにHANAでは、ワイルドカードつきのテキスト検索もできます。ベンダー名だけでなく、顧客名、都市名、郵便番号（ZIPコード）などでも絞り込んで結果を表示することができるため、自在に絞り込みが可能です。

たとえばこの図は、レンタカーの利用状況に関してベンダー分析してみた画面です。

明らかに、レンタカーに関する指定ベンダーはエイビス（Avis）なのであろう。したがってエイビス以外を使った社員が誰か？もたちどころにわかる、というわけだ。

■経費明細レポート（Expense Detail Report）

3番目は経費明細レポートです。経費精算の実績を、明細レベルでさっと引き出すことができるようになりました。

もともと経費明細はBW上にあり、そのファクトテーブルは1,000万件あって、物理サイズは2,757メガバイトありますが、これがHANAでは296メガバイトに圧縮されています。圧縮率は9倍以上です。

1,000万件から1つの明細を引き出すのにかかる時間はわずか4秒。従来のデータベースと比べて、200倍以上に高速化されました。

検索結果はこんな感じです。これは「経費の多い社員、上位15人」というレポートです。

-----

いかがだろうか。

筆者は、とくに最初の事例、「人脈・コネ検索」にはびっくりした。とくに履歴書の内容までスキャンして取り込み利用する、というあたりは画期的である。（※あくまで採用した社員の履歴書だけで、採用しなかった応募者のデータは厳正に破棄している、とのこと。念のため。）

なにしろ「社員の人脈」とは、埋もれたままにしておけば価値ゼロ。ところが効率的に掘り出して使うことができれば、効果は抜群でしかもコストはゼロという資産なのだ。

もちろん「あっち側もこっち側も元同僚」という特殊な業界ではあるが、人脈がモノを言う業界は他にもあるのではないだろうか。

最初は「〇〇社に知り合いはいませんか」というメールが毎日大量に飛び交うこの現状をなんとかできないものか、というシンプルな問題意識からスタートしたのであろうが、それがインメモリDBという飛び道具を得て、一気に具現化されたというわけだ。営業担当者にとっては「宝の山」データベースであろうことは間違いない。

-----

また2番目と3番目は、単純な「仕入れコスト分析」にすぎないとも言える。しかしコストの大半が人件費および社員が使う経費で占められている同社においては、その見える化と抑制は企業経営の生命線であり、業績に直結するインパクトがある。

たいていの大手企業では、支出項目はすでに電子データ化されているはずだ。しかし件数が多すぎて、従来型のデータベースでは重すぎて扱いづらい。

ところがHANAだと、全件をHANAにインポートして秒単位の時間で扱えるようにするのに、わずか2～3週間しかかからない、とこの事例は語っている。

ちなみに講演後のQ&Aによると、同社が保有しているHANAサーバーの物理メモリ量は1テラバイト、HANAライセンスとしては768ギガバイトだが、現在HANA上にあるデータは（3システム合計で）220ギガバイトほどとのこと。

ということは、実際には256GBほどの量があれば十分に乗るということだ。

シンプルにして効果的。御社でも試してみてはいかがだろうか。

※当記事は公開情報をもとに筆者が構成したものであり、デロイト社のレビューを受けたものではありません。