サービス&アプリケーション・基本編 2017年11月版 最新のITトレンドとビジネス戦略 サービス&アプリケーション・基本編 2017年11月版

ご案内 知識の定着は、ネットを眺め、資料を読むだけでは不十分です。実際に第三者を相手に自分の言葉で説明してみるのが最も効果的です。 また、本プレゼンテーションは、ロイヤリティ・フリーです。ご自身の資料として、加工編集して頂いても構いません。 知識の確かな定着と仕事の生産性向上のために、ご活用下さい。 ネットコマース株式会社 斎藤昌義 最新のアップデートは、「ITビジネス・プレゼンテーション・ライブラリー／LiBRA」にて随時更新しております。 http://libra.netcommerce.co.jp/

サービス&アプリケーション／基本編 ERP ビジネス・インテリジェンス

ERP

ERPとは 5

ERPシステム 登場の歴史的背景 ERP メインフレーム時代 部分最適 複製システム・分散システム時代 部分最適 ERP時代 全体最適 業務 業務 業務 業務 業務 業務 業務 業務 業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 業務 機能 業務 機能 業務 機能 業務 機能 SYS SYS SYS SYS SYS SYS SUB SYS SUB SYS SUB SYS 業務 機能 統合マスター データベース ERP 業務 機能 部分最適 から 全体最適 へ 【図解】コレ１枚でわかるERPの歴史   1960年代に入り、ビジネス用途で使えるコンピューターが、普及しはじめます。当時、業務は、電話や紙の伝票の受け渡しで行われていましたが、その業務の流れをコンピューターのプログラムに置き換えようという使い方です。当時は、個々の業務の現場で使われている紙の伝票の流れに合わせて、プログラムのフローを設計したことから、業務個別に最適化されたシステムが作られてゆきました。 ただ、このようなシステムであっても、電話や伝言、紙の伝票での業務処理に比べれば、作業の生産性は劇的に向上したことから、情報システムの開発需要は、どんどん増えてゆきます。ただ、当時は、ユーザー企業の情報システム部門が、それぞれ独自に自社の業務に合わせてプログラムを内製するのが普通であったため、この需要に追いつけなくなってゆきました。 この状況を打開するため、最初から個々の業務に最適化された情報システムを作るのではなく、既に完成し稼働しているプログラムをコピーして、新しい業務に合わせて変更しなければならない部分だけを修正し、需要の増加に応えていたのです。それでも、完全に業務の流れに対応できないときは、人的な運用で代替することで凌いでいました。 また、1980年代に入り、小型のミニコンピューター（ミニコン）やオフィース・コンピューター（オフコン）、パーソナルコンピュータ（パソコン）が登場します。当時業務システムとして使われていた大型のメインフレームでのシステム開発では、要望してもすぐに開発してもらえず、コストも掛かることから、業務部門は、独自にこれら小型のコンピューターを導入し、さらにパッケージ・ソフトウェアを使って個別システムを構築するようになります。 このような取り組みにより、情報システムの適用範囲は拡大してゆきましたが、部分最適なシステムが増えたために、業務間の連係がうまく行えなかったり、データの不整合や二重入力といった弊害が増えたりと、いろいろな問題を抱えるようになったのです。 そんな中で、業務の重複や無駄を廃し、業務の効率化を図りたいという需要が高まってゆきます。また、エンロン事件やワールドコム事件のような、大規模な不正が大きな社会問題となったことなどもあり、内部統制への関心も高まります。そのために一貫性や完全性が保証されたデータで経営や業務状況を把握したいという需要も増えてゆきました。 そこで、これまで業務個別に最適化され開発されてきた情報システムを全社最適の視点で再構築しようという気運が高まります。そこで、全社最適の観点での業務プロセスを再構築し、業務個別に構築されていたマスターデータを全社で統合したデータベースに集約するとともに、その統合化されたデータベースを中核に業務システムを構築する「ERP（Enterprise Resource Planning）システム」が、注目されるようになったのです。 現場の業務をそのままシステム化 元の書類の流れに合わせたシステム 部分最適なシステム構築 様々な部門が様々なシステムを導入 重複業務（顧客マスター登録など） 別々のDB（顧客データなど） システム間でデータの互換性が無い 業務 機能 業務 機能 部門SYS 部門 SYS 部門SYS 業務 機能 業務 機能 業務 機能 業務 機能 業務のシステム化 業務システムの適用領域拡大 業務システムの統合化

個別業務システムとERPシステムの違い 個別業務システム ERPシステム 販売 生産 ・・・ 販売 生産 ・・・ 統合データベース ・・・ 会計 人事 ・・・ 会計 人事

ERPシステムとは 人事 生産 販売 会計 人事 生産 販売 会計 個別業務システム ERPシステム 業務個別に プロセス 個別 システム 個別 システム 個別 システム 個別 システム ERPシステム 人事 生産 販売 会計 業務システム 経営 個別DB 個別DB 個別DB 個別DB 全社統合DB データベース 業務個別に プロセス・データの整合性を確保 会社全体として業務間の プロセス・データの整合性を保証 【図解】コレ１枚でわかるERPシステム   ERP（Enterprise Resource Planning）とは、企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を会社全体で一元的に把握し、それを適切に分配して有効活用する計画手法であり、その計画を重視する経営手法のことです。このERP経営を実現するための情報システムが、ERPシステムです。 業務個別に作られた情報システムは、それぞれ、台帳や帳票を収めたマスターファイルと業務処理を行うためのプログラムで構成されています。このようなシステムの場合、個々の業務処理には最適化されていますが、他の業務間の連係がうまく行えなかったり、似たような業務を重複して行っていたり、データの不整合や二重入力といった弊害が増えたりと、いろいろな問題を抱えることになります。例えば、「顧客情報」は、お客様の購買情報を管理し、販促キャンペーンでチラシを郵送するために販売システムで使われます。また、お客様に荷物を輸送する必要がある場合は、物流システムにも必要ですし、請求書を発行し、入金を確認するためには、会計システムでも使われます。しかし、マスターファイルが、個別に管理されていると、顧客情報が変更されたり、商品を販売したことで情報が更新されたりした場合、関係する全てのデータを書き換えなくてはなりません。また、ある業務システムのプログラムが修正された場合、影響をうける他の業務システムのプログラムを洗い出し、それを修正しなくてはなりません。 一方、ERPシステムは、会社全体で統合化されたマスター・データベースを用意します。全ての業務処理は、この統合化されたデータベースを使用します。そのため、データの一貫性は保証され、データの不整合や二重入力の手間はかかりません。また、データ相互の関連は、業務の流れ（ワークフロー）と一体となってデータベースに格納されますので、業務プロセス全体の整合性も保証されます。 さらに、データが全て一元的管理され、常に最新の状態に保たれていることから、会社全体の動きや状況をリアルタイムで捉えることができます。 ただ、このようなERPシステムを構築するためには、既に業務毎に個別最適化された業務プロセスを見直し、会社全体で最適化された業務プロセスに再構築しなければなりません。このような取り組みをBPR（Business Process Re-engineering）と言います。また、個別に作られたマスターファイルを整理し、統一のデータベースに作り直さなければなりません。 既に個々の業務の現場に最適化されたシステムが稼働し、それに馴れている人たちからは、抵抗されることも少なくありません。会社全体が抱える課題や現状についての危機感を正しく共有し、経営トップの強力なリーダーシップの元に取り組まなければ、実効性のあるERPシステムを構築することは、困難と言えるでしょう。 特　徴 処理にタイムラグが発生 二重入力によりマスターの分散 個別設計・構築 データやプロセスの不整合 個別維持管理による運用負担 プロセス全体の可視性なし リアルタイム処理 マスターの統合 全体最適化された設計・構築 データやプロセスの整合性を保証 プロセス全体の可視性を確保

ERPシステムの全体像 ERPシステム 統合データ アナリティクス 可視化 可視化・分析・計画 アプリケーション 営業・販売 経理・財務 効率的義用務運営 リアルタイム経営 内部統制 ERPパッケージ利用のメリット ベストプラクティスの活用 法律・制度変更への迅速な対応 構築に関わる期間とコストの削減 経営 営業・販売 可視化 可視化・分析・計画 アプリケーション 経理・財務 営業・販売 アプリケーション アナリティクス 経理・財務 アプリケーション 統合データ 倉庫・物流 アプリケーション 調達・管理 アプリケーション 【図解】コレ１枚でわかるERPシステムのメリット   ERPシステムの価値は、以下の3つだといえるでしょう。 効率的業務運営 従来業務ごとに分散し、分断されていたマスターデータ（製品や取引先など）や取引データ（各種伝票など）を、統合データベースによって一元管理できます。そのため、全ての業務処理は、単一のデータを参照し、更新されるため、ある業務処理が実行されると同時に、そのデータに関連する全ての業務にもその更新が反映されます。 例えば、顧客情報が更新されると、それを使用する販売、会計、出荷などの全ての業務システムが、更新された同一のデータをすぐに利用できるため、業務プロセス全体で直ちに整合性が担保され、部門間の連携がスピーディに行えます。また、同じデータを複数の業務システムに個別に入力する、あるいは転記すると言った手間がなくなり、業務の効率化が実現されます。 また、販売、生産、会計など複数の業務をつなぐ処理手順（ワークフロー）も統合データベースで管理されます。そのため、業務の流れとデータ更新の整合性が常に担保されることから、正確で円滑な業務処理が実現されます。 リアルタイム経営 業務に関わるデータは、常に全体として最新の状況が反映されていることに加え、売上や原価、在庫や進捗などの数字も全て一元的に管理されているため、会社全体の状況をリアルタイムで把握することが可能になります。BI（Business Intelligence）アプリケーションなどを使用し、経営や業務の状況を分析、可視化し、経験や勘ではなく、データに基づく意志決定を正確、迅速に行うことを可能とします。 内部統制 統合データベースによるデータの整合性の保証、また、ワークフローに基づく利用者権限や利用履歴の一元管理により、会社の業務全般にわたっての内部統制が、容易に行える環境を整えます。 これらパッケージとして導入する場合、以下の３つのメリットを享受することができます。 ベスト・プラクティスの活用 ERPパッケージの開発元や導入支援企業は、多くのユーザーでの実務経験を収集し、それぞれの業種や業務に応じたベスト・プラクティスのテンプレートを提供しています。 ERPパッケージには、業務処理に必要な基本機能をプログラムとして実装していますが、それらをどのように使用するかをプログラムそのものに手を加えることなく、パラメーターやスクリプト言語によって設定できます。その設定のセットが、テンプレートです。このテンプレートを使うことで、他社のノウハウやベスト・プラクティスを利用することで、自社のERP経営に向けた業務改革を加速させることができます。 法律・制度変更への迅速な対応 自社で独自の情報システムを構築する場合、税務や会計などの法律や制度が替わるたびに、プログラムの改修が必要になります。ERPパッケージでは、このような変更をパッケージの開発元が実施し、対応してくれます。そのため、制度変更への対応の負担が少なく、迅速に対応することができます。 構築に関わる期間とコストの削減 ERPパッケージを導入するに当たっては、現状業務の分析と整理、ERPパッケージが提供するテンプレートとのギャップを明らかにしなくてはなりません。その上で、変えなくてはならない業務プロセスは何か、テンプレートの何をカスタマイズするか、追加すべきプログラムは何かを明確にします。 本来であれば、ERPパッケージが提供するベストプラクティスに沿って業務改革（BPR：Business Process Reengineering）し、パッケージをそのまま利用することが導入コストと期間という点では望ましいと言えますが、既に各企業において最適化された業務プロセスを変更することは容易ではありません。そんな現実を踏まえながら、BPRを推進することで、独自開発を減らすことができれば、導入・構築に関わる期間短縮とコスト削減の効果を大きくすることができます。 生産・製造 アプリケーション 人事・給与 アプリケーション 倉庫・物流 調達・管理 ERPシステム 倉庫・物流 調達・管理

「ERP」と「ERPシステム」と「ERPパッケージ」 ERP Enterprise Recourse Planning あるべき姿のひな形を使って、経営や業務の全体最適化を加速 企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を 適切に分配し有効活用する計画を重視する経営手法 ERP システム ERP経営を実現するための 情報システム ERP パッケージ ERP経営を支える理想的な業務プロセスをパッケージ化した情報システム 業務分析や業務プロセスの標準化(BPR)に手間やコストがかかり、実現が困難 【図解】コレ１枚でわかるERPとERPシステムとERPパッケージの違い   「ERP」と「ERPシステム」と「ERPパッケージ」の違いをご存知でしょうか。よく似た言葉ですが、それぞれに意味が違います。歴史的な背景を踏まえながら、その違いを解説します。 ERP ERP（Enterprise Resource Planning）とは、企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を会社全体で一元的に把握し、それを適切に分配して有効活用する計画手法であり、その計画を重視する経営手法です。 ERPという言葉は、製造業における資材所要量計画 (MRP：Material Requirements Planning) といわれる生産資材を管理し、計画する手法から派生した言葉で、資材以外の人員、設備など製造に必要なすべての資源を管理し、さらに、企業全体の在庫、決済、資産の管理を行うように発展したのがERP（企業資源計画）です。情報システムそのものを意味する言葉ではありません。 ERPシステム ERP経営を実現するための情報システムです。ERP経営を実現するためには、会社全体で業務の重複や無駄を排除し、部門個別に最適された業務プロセスではなく、会社全体として最適な業務プロセスを実現しなければなりません。そのためには、徹底した業務分析と業務プロセスの改革、標準化に取り組まなくてはなりません。この取り組みは、BPR（Business Process Re-engineering）と呼ばれています。ERPシステムは、このBPRを実施した結果明確にされた、全体最適化された業務プロセスを前提に構築される情報システムです。 ERPパッケージ 企業規模が大きくなればなるほど、部門の利害はぶつかり、部門を越えた会社全体での最適化をめざすBPRは困難を極めます。加えて、ビジネス環境の変化は、業務プロセスを常に変化させ、全体最適を維持するために業務プロセスの継続的見直しと最適化を行うこと（BPM：Business Process Management）は、容易ではありません。その変更に合わせてERPシステムに手を加え続けるとなると、手間もコストも膨大なものになってしまいます。そこで、登場したのか、ERPパッケージです。 ERPパッケージは、ERP経営を支える理想的（ベストプラクティス）な業務プロセスを予めパッケージ化した情報システムです。 ERPパッケージには、ERP経営を実践する上で必要となる業務プロセスや全社データを一元的に把握、管理するためのデータ構造のひな形が、業種や業務に応じたテンプレートとして、予め用意されています。このテンプレートを使い、業務の変革をすすめ、ERP経営の実現を加速しようというのです。 本来であれば、ERPパッケージが提供するベストプラクティスに沿ってBPRを推進すれば、ERP経営が実現できるわけですが、既に個別最適化された業務プロセスを持つ各業務部門が、それに合わせることは容易なことではありません。そんな現実を踏まえながら、最低限のテンプレートのカストマイズ、および、独自開発システムで対応できれば、ERPパッケージ導入の効果を享受することが可能となります。 ERPパッケージを、自社独自の基幹業務システムを開発するに当たり、最初から全てを作るのではなく、パッケージの機能を流用することで開発生産性を高めるための手段と捉えている企業もあります。しかし、それは、ERPパッケージ本来の目的でありません。「ERP経営実現を加速するための手段」ととらえ、カスタマイズや追加独自開発を極力少なくする取り組みを行わなければ、本来の価値を引き出すことができないことを理解しておく必要があります。

ERPシステム/パッケージとクラウドでの利用形態 アプリケーション SaaS 業務遂行に必要なソフトウエア 標準アプリケーション （クラウド・サービス） 他のクラウド・サービス タレント・マネージメント マーケティング・オートメーション 経費管理　など プラットフォーム PaaS 開発や実行に必要なソフトウエア ユーザー個別 アプリケーション インフラストラクチャー IaaS プロセッサー、メモリー、ストレージ、 ネットワークなどのシステム資源、施設 標準アプリケーション （パッケージ・ライセンス） ユーザー個別 アプリケーション ホステッド・プライベートクラウド

SAPの製品ラインナップ

ERPのグローバル展開と ２層ERP（Two-tier ERP） 13

ERPの理想と現実 2層ERP 理 想 Global Single Instance / One Global Standard 現 実 理　想 国内外のグループ企業の全拠点に同一ERPシステムを導入し、データフォーマットを統一、業務やデータの連係を円滑に行う。その結果、業務処理を効率化でき、経営状況をリアルタイムで把握できるようにする。 Global Single Instance / One Global Standard 拠点毎に個別最適なパッケージを導入 親会社のシステムをひな形とする 親会社のマスターに合うようにデータを変換する 2層ERP 2 Tier ERP 【図解】コレ１枚でわかる２層ERP   企業活動のグローバル化に伴い、経営資源もまたグローバルに全体最適を求められるようになりました。その対応として、国内外のグループ企業の全拠点に同一のERPシステムを導入することで、データフォーマットを統一し、業務やデータの連係を円滑に行うことで、業務処理を効率化し、経営状況をリアルタイムで把握できるようにしようというニーズが高まってきました。全拠点を単一の企業組織のように扱おうというこの考え方は、Global Single Instanceと呼ばれています。 しかし、本社とは異なる事業を行っていたり、海外の地元企業との合弁会社であったり、商習慣が異なっていたりする拠点においては、業務フローやデータ構成が本社と異なることは避けられません。このような拠点に同一のシステムを導入すると、現場の業務内容とERPシステムの機能とのギャップを人手による運用で埋めなくてはならず、逆に業務負担が増えてしてしまうことがあります。 また、本社は、大企業であっても、海外の拠点は、小規模な組織で運用されていることもあり、本社と同様の大規模なERPシステムでは、コスト的に見合わず、その維持管理に、十分な人材を割くこともできません。 また、国によっては、政治情勢や経済状況の変化が、日本のようには予測できず、事業を直ちに統廃合しなければなければならないといったことも考えられます。そのため、本社と同一の大規模なERPシステムを全拠点に導入することは、大きなリスクを伴うことになります。 このようなリスクを回避し、グローバルでの全体最適をめざす手段として登場したのが、「2層ERP（Two-tier ERP）」という考え方です。 2層ERPとは、本社で稼働している大規模なERPシステムとは別に、各拠点の事業内容や規模に応じて最適なERPシステムを導入し、本社のERPシステムと、一定のルールに基づきデータの組み替えを行い円滑なデータ連携を図ろうというものです。本社のERPシステムを「1st tier ERP（または、コアERP）システム」、各拠点のERPシステムを「2nd tier ERPシステム」と呼びます。 各拠点は、それぞれの業務や規模に合わせてERPシステムを選定できるため、先に挙げたリスクを回避できます。加えて、本社は、各拠点のERPシステムのデータをコアERPシステムに容易に取り込むことが可能となり、グローバルな全体最適を実現しやすくなります。 各拠点のERPシステムは、コアERPシステムとのデータ連携が可能であれば、様々なERPパッケージの中から選定することができます。ただ、本社からの運用支援や連携を効率よく行うために、できるだけ同一のものを採用する傾向にはあるようです。 昨今、2nd tier ERPシステムをクラウド版のERPシステムで導入しようという動きが増えています。クラウド版のERPシステムは、サーバ購入や運用管理要員の雇用のためのコストがかからず、短期間での導入できます。更に、ビジネスの展開に合わせて、機能や性能の伸縮を柔軟に行うことできるため、ビジネスの不確実性が高い海外拠点で導入するには、最適な選択肢となっています。このような理由から、クラウドERPを利用した2層ERPの採用は今後増えてゆくものと考えられます。 現　実 本社と同一の大規模ERPシステムの全拠点導入は大きなリスクを伴う 本社と異なる事業、地元企業との合弁、商習慣の違いにより、業務フローやデータ構成が本社と異なる。 同一のシステムを導入すると、現場の業務内容とERPシステムの機能とのギャップを人手による運用で埋めなくてはならず、逆に業務負担が増えてしてしまう。 海外の拠点は、小規模な組織で運用されていることもあり、本社と同様の大規模なERPシステムでは、コストに見合わず、その維持管理に、十分な人材を割くこともできない。 政治情勢や経済状況の変化が予測できず、事業を直ちに統廃合しなければならないことも考えられる。

2層ERP(2-Tier ERP)の考え方 ERPの目指す理想型 本 社 2層ERPの考え方 本 社 子会社 子会社 本　社 子会社 2層ERPの考え方 本　社 子会社 同一経営プロセス/同一アプリケーシュン 同一勘定科目・管理基準 複数企業体が、同一企業体のごときオペレーション 個別経営プロセス/個別アプリケーション 本社勘定科目・管理基準に準拠 複数企業体の個別オペレーション／データ組替連携

Two-tier ERP (2層ERP)の構成 親会社 ERP Business byDesign 子会社

1st Tier 2nd Tier 2層ERPの仕組み データ変換のためのインターフェイス (Core ERP) 販売 生産 物流 大企業向けパッケージ 販売 生産 物流 統合データベース 購買 会計 人事 データ変換のためのインターフェイス 2nd Tier 中小向けパッケージ クラウドERPなども活用 1st Tierとのインターフェイス 販売 生産 物流 購買 会計 人事 統合データベース 販売 生産 物流 購買 会計 人事 統合データベース 販売 生産 物流 購買 会計 人事 統合データベース

ERPと EA・BPR・BPM 18

部分最適なシステム構築 サイロ化 現場の業務をそのままシステム化 ・元々の「書類の流れ」に合わせたシステム ・部分最適なシステム構築 ・様々な部門が様々なシステムを導入 ・重複する業務（顧客マスターの登録など） ・別々のDB（顧客データなど） ・システム間でデータの互換性が無い 1964年に発表された世界初の汎用機であるIBM System360は、「360度全ての用途に使える」コンピュータでした。 生産管理・販売管理・会計処理などをひとつのシステムで行うことができました。 1台のマシンで全てのアプリを動かすわけですから、開発・運用もほとんどの場合ひとつの会社が請け負います。 システム構成や他のアプリも熟知していますから、アプリ間の連携がとれない、などという事態は起こらなかったわけです。 しかし、メインフレームは数十億円もするシステムですから、導入できる企業は限られています。 1970年代以降、ダウンサイジングの波が起こり、コンピュータの価格が劇的に下がり、それまでコンピュータを導入できなかった企業にも浸透しはじめたのです。 その結果、事業部門毎に様々なシステムが入ることになりました。IT部門が頑張って整合性をとろうとする動きもあったでしょうが、全ての面倒を見ることはできません。 様々なシステムが、個々の事業部門の要求仕様に従って構築されたのです。どうしても、他部門のシステムとの統合にまで考えがおよばないケースもあったでしょう。 システム毎にメーカーが違ったり、開発業者が違うケースもあります。導入時期が違えば、使う技術も変わります。 しかし、発注元である現場部門としては、自分達の要求が満たされることが第一の目的です。 要求仕様をどう作るかというと、皆さんも経験があるでしょうが、現場でどういった業務を行っているかをヒアリングするのがまずは第一歩です。 その業務の流れを、そのままコンピュータ化するのがシステム開発です。いわば「その時点での『書類の流れ』をシステム上に実装したもの」ということができます。 このようなシステムの作り方だと、他のシステムとの連携も、必要最小限しか考慮されないでしょう。部門内の業務をメインに考えられた「部分最適のシステム」ができあがります。 そうなると、顧客マスターの登録業務を会計部門でも営業部門でも製造部門でも行っていたりすることになります。 各々の部門が「顧客マスター」のデータベースを持ち、どれが本物のマスターなのかが分からなくなります。正確な顧客リストが出せなくなるわけです。 うっかりすると、各マスター間で互換性が無く、名寄せもできない、などということが起こっても不思議ではありません。 このように、お互いに連携が不足で、孤立化した状況を「システムのサイロ化」などと言います。サイロとは、北海道などに良くある、牧草を入れておく塔のような建物のことです。お互いに孤立してますよね。 サイロ化

システム開発手法の変遷 Enterprise Architecture Business Process Re-engineering 従来は部分最適な業務システム 個別にシステム設計開発 現場の仕事をそのままシステム化 「その時点」での技術を使って開発 他システムとの連携は必要に応じて設計・実装 全社的最適化という視点はない 全社最適化手法 EA Enterprise Architecture BPR Business Process Re-engineering ERP Enterprise Resource Planning Enterprise Architecture 複雑化し非効率化した巨大な組織の業務手順や情報システム、組織を全社規模で最適化し、効率よい組織の運営を図るという考え方または方法論。 EAにより、巨大な組織内で複数の業務システムが別個に運用されていたものを標準化し、導入・運用コストの削減、重複した業務内容の統合を通じて組織の運営コストの削減を目指す。 Business Process Re-engineering 高度に専門化され、プロセスが分断された分業型組織を改革するため、組織やビジネスルールや手順を根本的に見直し、ビジネスプロセスに視点を置き、組織、職務、業務フロー、管理機構、情報システムを再設計し、最終的顧客に対する価値を生み出す一連の改革。 このように、ダウンサイジングによってコンピュータが普及した代わりに、企業内に部分最適の業務システムが乱立してしまいました。 システム間の連携が充分に考えられておらず、必要になった時点で開発する、などといった二度手間が生じるようになってきたのです。全社的な観点から見た開発効率としては、良くはありません。 これは、システムの設計開発にあたって全体的な視点というものが欠けていたことが原因です。 この反省に立って、全社的な視点からシステム開発を考えようという動きが起こりました。1980年代に提唱されたEnterprise Architectureです。 EAは、複雑化し非効率化した巨大な組織の業務手順や情報システムを抜本から見直し、全体規模で最適化しようとする、非常に大きな枠組みの考え方です。EAにより、システムへの要件が決まり、それをベースにシステムを構築すれば、全体最適化されたITシステムを構築できます。 このEAという大きな考え方の中で、ビジネスプロセスに注目し、これを根本的に見直していこうという部分がBPRということができます。

Enterprise Architecture 巨大な組織の業務手順や情報システムの標準化、組織の最適化を進め、効率よい組織の運営を図るための方法論 1987年にJohn A. Zachman(ジョン・A・ザックマン)氏が提唱 大企業・政府機関 米連邦政府 日本の電子政府 EAには、全社的な観点から業務を見直し、効率化するビジネス戦略の側面と、データの標準化やIT技術の活用というIT戦略の側面があります。経営改革の概念も含んでいるのです。 ビジネス戦略とIT戦略を結び付け、個々のシステムをデザインする際に従うべき規範や、業務とシステムの“あるべき姿”に到達するためのプロセスを定めることで全体最適化を図るのが目的です。 EAは4つのアーキテクチャから構成されています。 ・ビジネス・アーキテクチャ（BA：政策・業務体系） ・アプリケーション・アーキテクチャ（AA：適用処理体系） ・データ・アーキテクチャ（DA：データ体系） ・テクノロジ・アーキテクチャ（TA：技術体系） EAの起源は、1987年に「IBM Systems Journal」誌で提案された「Zachmanフレームワーク」とされます。1990年代に米連邦政府がEAの作成を義務づけたことから注目され、大企業がEAに取り組みました。日本でも東京三菱銀行や松下電器産業が取り組んだということです。日本政府も2003年から電子政府の取り組みのなかでEAを位置づけています。 しかし、EAは厳格すぎ、大規模すぎてうまくいかない例も多かったとされます。日本の電子政府の取り組みも、最近はトーンダウン気味のようです。 このEAの中のビジネスアーキテクチャの中に、プロセスモデルの定義があります。この部分にフォーカスし、プロセスモデルの最適化を行うために考えられたのが、ビジネスプロセスリエンジニアリングということができます。 http://itpro.nikkeibp.co.jp/article/lecture/20070403/267249/?ST=selfup 厳格過ぎ、大規模過ぎでうまくいかない例も – 最近見直しの機運

Business Process Re-engineering ビジネスプロセスの改善に注目 企業改革を目的としてビジネスプロセスを見直し ビジネスプロセスの視点で職務、業務フロー、管理機構、情報システムを再設計するという経営コンセプト ビジネスプロセスの考え方は1980年代に製造業の品質管理手法として考案されたシックスシグマが最初 1990年に元マサチューセッツ工科大学教授のマイケル・ハマー（Michael Hammer）がHarvard Business Review誌に論文を発表 BPRの原点は古典的なビジネス構造の否定 「重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス・プロセスを根本的に考え直し、抜本的にそれをデザインし直す」 1990年代終わりになると、非連続的な大改革が逆に大混乱を招く 1997年、MITシステムダイナミックス・グループが 「リエンジニアリングの70％は失敗」などと報告 BPRという考え方は、EAよりも少し後、1990年に元マサチューセッツ工科大学教授のマイケル・ハマーが発表した論文が始まりとされます。 http://www.itmedia.co.jp/im/articles/0401/14/news089.html ただ、ビジネスプロセスという考え方そのものの歴史はもう少し古く、1980年代にモトローラやGEなどが取り組んだ品質管理手法であるシックスシグマが取り入れたのが最初と言われています。 ハマーは、高度に専門化され、プロセスが分断された分業型組織に見られる職能別の古典的なビジネス構造を全面的に否定し、プロセス志向の新たな組織構造・価値観・評価システムをゼロから作り出すことを勧め、抜本的な変化を起こすための一連の手順としてBPRを考え出しました。 BPRの定義は「コスト、品質、サービス、スピードのような、重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス・プロセスを根本的に考え直し、抜本的にそれをデザインし直すこと」です。 これは要するに「既存のやり方は全部駄目」という考え方で、BPRの導入はまず既存のプロセスの破壊から始まったのです。 このため、BPRを導入しようとした企業の多くが「プロセスの見直しのしすぎ」で混乱に陥り、97年にはBPRの70%が失敗に終わったという報告が出されました。 しかし、逆に言えば30%の企業では効果があったとも言えます。業態や取り扱い製品の違いなどによるものなのでしょうが、BPRの考え方そのものが間違っていたわけではなく、やり方がよくなかったということでしょう。

ビジネスプロセス ひとまとまりの目的が定義できる 入力と出力がある 何度でも繰り返せる 販売管理のビジネスプロセス 効果が測定できる 受注 請求 入金 出荷 効果が測定できる 階層化されている ところで、ビジネスプロセスとは何か、というのは、実は大変に難しい問題なんですが、ここではあまり深いところまでは行かずに、ビジネスプロセスとは何かを考えて行きましょう。 例えば、とある企業における販売管理の業務プロセスを考える場合、こういった流れになったとします。受注して、請求処理をして、入金を確認したら商品を出荷する、という流れです。 この販売管理プロセス自身、さらに細かいプロセスから構成されます。例えば、請求処理であれば、金額・納期の確認や請求書の発行、発送といったプロセスに分解できるでしょう。 一方で、このプロセスは、より上位のプロセスの一部でもあります。営業活動や製造・在庫管理などと連携しています。 ビジネスプロセスの要件としては、一連の作業をひとまとめにして、ひとつの目的を達成できること、というのがあります。 そして、情報の入出力があること。どういった情報が必要で、プロセスの終わりにどういった情報を出力するかを明確に定義できなければなりません。 さらに、必要な情報さえ揃っているならば、ビジネスプロセスの単位で独立してそれを繰り返すことができること。 硬化が測定できるというのは、アウトプットが明確でそれを定量化できるということです。 そして、ご覧のようにビジネスプロセスは階層化されています。 このように業務手順を分解してビジネスプロセスに落とし込むことにより、業務の流れが可視化され、繋がりが明確になり、どのような情報がどのように流れているのかがわかるようになります。 それらが明らかになることにより、ビジネス環境の変化が起きた場合に、どこを直せば良いかがすぐにわかり、変化に柔軟に対応できるようになります。 さらに、このようにビジネスプロセスを明確にしておくことにより、ITシステムへの実装がやりやすくなります。このあとお話しするSOAに結び着くわけです。 ビジネスプロセスを考えるときに特に難しいのが、どこまでをひとつのプロセスとして切り出すか、という「粒度」の問題なんですが、ITシステムとして考える場合には、開発するシステムの目的とか業務内容によって都度考えて行く、ということにしかなりませんので、ここでは突っ込みません。そここそが難しい、という問題はあるわけですけれども。 業務の流れ、繋がりを可視化 変化への柔軟な対応 ITとの連動 (SOA)

ビジネスプロセスの継続的な見直し ① ② ③ ① 受注 受注処理 生産 受注 受注処理 生産 例外処理 構成チェック 構成チェック 「望ましい」業務プロセス 書類 「望ましい」 業務プロセスでは効率が悪い 環境の変化により「望ましい」業務プロセスに戻す必要がある 受注 構成チェック 受注処理 生産 ① 問題 発生 例外処理 「修正した」業務プロセス 書類 しかし、ビジネスプロセスの見直しは、一回行ったらそれで終わり、ということにはなりません。具体的な例を挙げてご説明します。 ある製品の受注処理を行う場合の本来望ましい業務プロセスな上のようなものだったとします。 前提として、この製品は構成が難しく、きちんと動かすためには受注した構成を1度工場でチェックするのが望ましいとします。 またこの当時は本社と工場の間がオンライン化されておらず、校正チェックのためには受注書類を1度向上に郵送しなければならないとします。 このような場合受注して書類を工場にいったん送りそれがおおきであればもう一度本社に戻して受注処理を行った後に最終的に生産のためにもう一度工場に送るというプロセスになります。あまりやりそうにない話ですがビジネスプロセスをご理解いただくための例としてお考え下さい。 しかしこの書類のやり取りを郵送で行っていると、いかにも時間がかかります。そこでこの企業では、オーバーヘッドを減らすために、受注処理前の校正チェックを行わないというプロセスを考えました。受注書類を工場に送ると同時に、本社で受注処理をしてしまうのです。そうすれば書類を送るのは1階ですみます。 構成が間違っていた場合には、受注処理をやり直すことになりますが、その可能性が10分低い場合には有効な考え方です。 さて、時代が進み、本社と工場がコンピュータネットワークで接続されかとします。環境の変化です。この場合には書類のやり取りによる時間のロスが発生しませんから、本来望ましい業務プロセスに戻す必要があります。そうすれば例外処理もなくなり更に効率化望めるからです。 しかし大にしてこの望ましい業務プロセスの変更は行われないことが多いようです。業務プロセスの修正から時間が経ってしまうとなぜその業務プロセスを採用しているのか、誰も疑問を持たなくなりますし、過去の経緯を知っている人も少なくなってしまうからです。このため本来望ましい業務プロセスがあるにもかかわらず、効率の劣る業務プロセスを使い続けるという結果になってしまいます。 オーバーヘッド の低減 ネットワークの普及・高速化などの環境変化

BPRからBPMへ BPR BPM BPR継続のための仕組み 改善・再ち構築 分析 モニタリング 設計 実効 業務内容や業務構造・手順を 根本的に見直して売り上げの 拡大やコスト削減を目指す 一連の活動 これがBPRの問題点です。BPRはビジネスプロセスを根底から見直すと言う作業を行いますが、それを継続するという考え方が抜けていました。 これを改善したのがBPM、Business Process Managementです。 BPMではPDCAサイクルを回してBPRに継続的に取り組むための仕組みを作ることを要求しています。

Enterprise Resource Planning EA→BPM→ERP 理念 Enterprise Architecture 巨大な組織(enterprise)の業務手順や情報システムの標準化、組織の最適化を進め、効率よい組織の運営を図るための方法論あるいは、そのような組織構造を実現するための設計思想・基本理念(architecture) 全体最適 プロセス ある仕事のスタートから完了までの流れを業務単位（プロセス）に分解して検証し、新しいプロセスが必要になった場合にもできるだけ他のプロセスに影響を与えないように挿入するなど、改善や再構築をしながら常に分析し、ビジネス効率を高めること。Enterprise Archtecture による全社的最適化との連携も重要。 分析 設計 実効 モニタリング 改善・再構築 BPM これまで話してきたように、EAは全体最適を目指すという「理念」です。 このEAの中の、ビジネスプロセスの見直しとそれを継続的に行う仕組みを取り入れた上で、EAが定める4つのアーキテクチャを定義し、全体最適なITシステムを開発するという考え方がERP、その考え方に基づいて構築されたシステムがERPシステムです。 つまり、全体最適なERPシステムの構築のためには、まず全社規模でのBPRを行い、それを元にアプリケーションアーキテクチャ、データアーキテクチャ、テクノロジアーキテクチャを作成することが必要になるということです。これは大変な作業です。 手法/ システム ERP Enterprise Resource Planning BPRに基づき全社最適化を行い、各業務システム間の連携まで含めてシステムを開発する考え方とそのための統合型パッケージ

既存システムを繋ぐEAI 全社最適化手法 従来は部分最適な業務システム EA Enterprise Architecture 個別にシステム設計開発 現場の仕事をそのままシステム化 「その時点」での技術を使って開発 他システムとの連携は必要に応じて設計・実装 全社的最適化という視点はない 全社最適化手法 EA Enterprise Architecture BPR Business Process Re-engineering ERP Enterprise Resource Planning 既存システムを相互接続して統合 EAI これまで全体最適化のためのERPシステムについて見て来ましたが、ERPは大規模なシステムであり、中小の企業が簡単に導入できるものではありません。一度に全てのシステムを入れ替えると言うのもハードルが高いでしょう。 このため、既存のシステムをうまく相互接続して統合できないかというアプローチが考えられました。 1990年代末に発表された、EAI (Enterprise Application Interconnect) です。 これは、バラバラに開発された個別最適のシステム同士をデータ変換やプロトコル変換を通して相互に接続しようとするものです。ちょうどハブのような構造になっており、システムとの結合部分は「アダプタ」と呼ばれます。 個々のシステム用にアダプタを開発するだけで、システムを統合できるため、非常に手軽で安価です。このため、EAIは現在でも広く使われています。 アダプタの開発についても、多くのシステムで共通する機能があるため、当初よりも開発は容易になっており、最近ではクラウド向けのアダプタが用意され、ハイブリッドクラウド環境への対応も進んでいます。 EAI (1990年代末) ばらばらに開発された業務システムをプロトコル変換などで統合

SOAの狙いと成果 柔軟性の向上 管理の容易さ 迅速な開発 業務プロセスを見直し、サービス単位に分割 サービス間のデータ交換ルールを決め、メカニズムを構築 サービス単位でプログラムを開発し、相互に接続 情報システムを分割し、疎結合させる こうしてみると、SOAの本質は「情報システムをビジネスプロセスに分解して個々にサービスとして実装し、お互いを緩く連結してシステムを構築すること」と言えます。 これにより、システムの柔軟性を高め、管理が容易になり、開発速度を向上させることができます。アジャイル開発なども、SOAの考え方が大きく影響しています。 柔軟性の向上 管理の容易さ 迅速な開発

補足資料 29

エンタープライズ・システム・アーキテクチャー ビジネス プロセス コスト削減 システム 課題とニーズ 変化への柔軟性 スピード経営 非効率 重複 不整合 欠落 機能不全 グローバル対応 戦略と施策 BPR EA 標準化を目指す アプローチ手法 部分最適から 全体最適へ 向かう取り組み BPM SOA プロセス標準化 のための手法 MDM ESB ERP 経営資源管理の一元化 マスター・データ の一元化 業務基盤強化 から 戦略基盤強化 ETL B I　 原因・理由の探索 集計と統計分析 DWH BA　 計画の最適化 モデル化と シミュレーション

オンプレミス型からクラウド型へのシフト http://www.strategyand.pwc.com/media/file/Beyond-ERP.pdf 継続してオンプレミスでERPを導入するニーズは20％にとどまっており、クラウドで利用できるのを前提とした利用で、オンプレミスと連携できる環境を求めている比率が64%となっています。 Pwcのデータに調査によると、オンプレミスERPは2016年までに30％減少減少し、クラウド型のERPが追い抜く状況となっている。 http://www.epicor.com/company/whats-next.aspx

OSS ERP http://it.impressbm.co.jp/articles/-/11256?page=3

アナリティクスとビジネス・インテリジェンス

ビジネス・インテリジェンスの目的 集計・分析・予測 可視化 判断・行動・実施 顧客属性 購買履歴 天気予報 収支データ 他店での 売れゆき 商品特性 収支データ 集計・分析・予測 運動会当日の天気予報が晴の時は、鮭おにぎりが売れる傾向が高い 紙おむつを買う男性は、缶ビールを一緒に買うことが多い 世帯収入が、1000万円を超える場合、投資信託Aの契約確率が高い 可視化 【図解】コレ１枚でわかるビジネス・インテリジェンス（BI）の適用目的   1960年代から急速に遡及したコンピューターは、企業内の様々な業務をデータとして捉える環境を整えてゆきました。このデータを使って社内業務に関わる分析レポートや管理資料を作成し、経営や業務に関わる意志決定を行う仕組みとして登場したのがビジネス・インテリジェンス（BI）です。なお、昨今BIととともによく使われる「アナリティクス」という表現との関係については、下記に説明していますので、よろしければ、合わせてご覧下さい。 >> 【図解】コレ１枚で分かるアナリティクス3.0 http://blogs.itmedia.co.jp/itsolutionjuku/2015/04/30_1.html かつてコンピューターがバッチ処理主体で使われていた時代、管理レポート１枚を作るにもCOBOLなどのプログラム言語を駆使して作成しなくてはならなかりませんでした。そのため、プログラミングの専門知識がある情報システムの専門家にそれを依頼しなければならなかったのです。しかし、業務現場の意図を正しく伝えることや試行錯誤して視点を変えて表を作ってみようとなると、その都度彼らに依頼しなければならず、大変手間も時間もかかっていました。 この状況を打開するため管理レポート作成や業務分析を情報システムの専門家に頼らなくても業務の現場や経営者ができるようにとの目的で作られた仕組みがBIです。 例えば、コンビニの地元地域で、今週末に小学校の運動会があるとしましょう。そのとき、何のおにぎりをいくつ仕入れれば、廃棄損失と機会損失を最も少なくできるかを判断したい場合を考えて見ましょう。過去の販売履歴や他店での同様のケース、天気との関係から、「運動会当日の天気予報が晴の時は、鮭おにぎりが売れる傾向が高い」という結果が、表やグラフで分かり約表示されます。そこで、店長は、「鮭おにぎりの仕入れをいつもより増やす」と判断することができます。 スーパーマーケットのPOS（レジ端末。商品のバーコードを読み取り、商品名や金額、時間、性別、大まかな年齢などを入力する装置）端末のデータから、「紙おむつを買う男性は、缶ビールを一緒に買うことが多い 」ということが分かりました。そこで、紙おむつの横にあるビールの割引クーポンを置いておくことで、その商品の販促につなげることができます。 また、銀行の場合、これまでの取引データから、「世帯収入が、1000万円を超える場合、投資信託Aの契約確率が高い」ことが分かったとします。この条件を満たすお客様が、投資信託を検討されている場合は、投資信託Aをすすめることで、成約率を高めることができます。さらに、別の手続きのために来店されたお客様が、この条件を満たしていた場合、投資信託Aをすすめることで、投資信託の販売を増やすことができます。 このように、経験や勘に頼らず、データを分析・整理し、わかりやすく表現し、的確で迅速な意志決定を可能にすることが、BIの目的なのです。 鮭おにぎりの仕入れを増やす 紙おむつの売り場にビールのクーポン券を置く 世帯収入1000万円超の顧客に投資信託Aを告知する 判断・行動・実施

ビジネス・インテリジェンスの適用例 BI：Business Intelligence BA：Business Analytics 現在の在庫状況は？ 在庫管理システムへの問い合わせで解決 様々なデータを駆使し仮説検証、予測モデル、 シミュレーションにより検討 複数の業務システムにまたがるデータを付き合わせ 検索・分析し、レポーティングする 1ヶ月後の在庫状況は？ 受注管理、生産管理システムなどの データと突き合わせ 年間の在庫量推移は？ 販売計画、生産計画などの データと突き合わせ BI：Business Intelligence 【図解】コレ１枚でわかるビジネス・インテリジェンス（BI）   ある商品の在庫状況を知りたければ、在庫管理システムに問い合わせれば、確認することができます。しかし、１ヶ月後の在庫状況を知りたければ、在庫管理システムのデータに加え、受注管理システムにある受注状況のデータや生産管理システムの生産、および、倉庫への出荷予定に関わるデータと付き合わせなくては、分かりません。また、年間の在庫の推移となると、さらに販売計画や生産計画のデータと付き合わせる必要があります。 このように、複数の業務システムにまたがるデータを付き合わせなければ分からないような問い合わせや、その結果をレポートにまとめたいというニーズは、少なくありません。 そこで、関係する業務システムから必要なデータを抜き出し、データベースを（DWH: Data Warehouse）を作り、これを使って管理レポートを作成（リポーティング）したり、様々な視点からデータの組合せを変えて分析（OLAP分析）したり、統計的な手法でデータに内在する法則や関係を見つけ（データマイニング）たりなどの作業が行われます。 さらに、「在庫量を最小化するための製造パターンを知りたい」といった場合には、上記に加え、統計的な予測モデルを使ってシミュレーションを行い、最適解を求めることが必要になります。 在庫量を最小化するための 製造パターンは？ 過去のデータからの販売傾向などを 加味した分析 BA：Business Analytics

ビジネス・インテリジェンスとビジネス・アナリティクス 過去 現在 未来 BI：過去の可視化 Business Intelligence BA：未来の可視化 Business Analytics 集計 ＋ 統計解析 モデリング ＋ シミュレーション 原因や理由を見つける 最適な計画を作る 製品不良の傾向を明らかにし、その原因を特定。 業績の推移から、業績を左右する要因とその影響度合いを明確化。 事業投資と経営指標に及ぼす影響を推測。 人材とスキルの関係、業績への貢献度合いを明示。 お客様の購入商品からアップセル可能な商品のレコメンド。 事業における最適な予算や人材の配分。 目的地へ物資を運ぶ上での最適な輸送ルート。 季節ごとに集客を最大化できるホテルの客室料金設定。 売上を最大化するための顧客モデルと対象顧客の発見。 来店客を増やすための広告宣伝の組合せ。 これらを行うためのアプリケーション・システムの総称が、BI（Business Intelligence）です。ただし、前者のような過去から現在について分析・整理し、レポートするものを狭義のBI（Business Intelligence）、未来における最適解を導き出すものを狭義のBA（Business Analytics）と呼んで区別することもあります。 例えば、BIは、過去や現状を可視化することで、そこに内在する関係や構造から、何らかの結果に至った原因や理由を見つけ出すことが主な目的です。 製品不良の傾向を明らかにし、その原因を特定。 業績の推移から、業績を左右する要員とその影響度合いを明確化。 事業投資と経営指標に及ぼす影響を推測。 人材とスキルの関係、業績への貢献度合いを明示。 お客様の購入商品からアップセル可能な商品のレコメンド。 一方BAは、将来のある時点における目標を達成するための最適な計画を作ることが目的です。 事業における最適な予算や人材の配分。 目的地へ物資を運ぶ上での最適な輸送ルート。 季節ごとに集客を最大化できるホテルの客室料金設定。 売上を最大化するための顧客モデルと対象顧客の発見。 来店客を増やすための広告宣伝の組合せ。 経験や勘だけに頼るのではなく、データに基づく的確で迅速な意志決定を行えるようにすること。それが、BIの目的なのです。  

アナリティクスの適用例: ダッシュボード、スコアリング、ゲージ 複雑な情報を速やかに伝達するために、さまざまな企業システムのデータを、ゲージチャート、地図、グラフなどのグラフィカルな要素を使用した視覚性に富んだ形式にして、さまざまなビジネス状況をまとめて表示したもの

EPM アナリティクスの目的 膨大なデータに内在する相互の関係や構造を分析・整理し わかりやすく表現して、事実に基づく意思決定を支援すること 経験や勘ではなく､事実に基づいて、ビジネス上の判断をできるようにすること 営業戦略 売り上げの増大 企業経営の最適化 事業活動の最適化 EPM Enterprise Performance Management マーケティング戦略 企業価値の向上 製造の効率化 コスト削減 製品開発 競争力強化 カスタマー・サポート 顧客満足の向上 「何かが起こってから変わる企業」から「何かが起こる前に変わる企業」へ

アナリティクスの目的 業務システムの膨大なデータに内在する相互の関係や構造を分析・整理し わかりやすく表現して、意思決定を支援すること 経験や勘ではなく､事実に基づいて、ビジネス上の判断をできるようにする 不正取引の発見 優良顧客の絞り込み 与信・取引リスク評価など 視聴率の分析 広告効果の評価 回線トラフィックの把握　など ロイヤリティの把握 購買行動の把握 プロモーション効果分析など 金融・保険 通信・放送 小売・流通 品質・歩留まりの向上 原材料トレーサビリティ向上 需要予測　など アクセス・クリックの向上 コンテンツ効果の評価 流入・流出傾向の把握　など 気象・地震の傾向把握・予測 エネルギー・消費動向の把握 犯人追跡・証拠発見　など 製造 メディア 公共・公益 「何かが起こってから変わる企業」から「何かが起こる前に変わる企業」へ

アナリティクスの目的 業務システムの膨大なデータに内在する相互の関係や構造を分析・整理し わかりやすく表現して、意思決定を支援すること 経験や勘ではなく､事実に基づいて、ビジネス上の判断をできるようにする 月別・年別売上げ推移 利益率の変遷 取引先ランキング　など 給与情報の検索 スキルや人事考課の分析 残業時間の分析　など 経　営 人　事 顧客別取引傾向の分析 顧客別購買履歴の管理 出荷や生産状況の管理　など 苦情分析 市場分析 製品別売上げ傾向分析　など 営　業 マーケティング 「何かが起こってから変わる企業」から「何かが起こる前に変わる企業」へ

「情報」と「ビジネス・インテリジェンス・プロセス」 業務 アプリケーション ソーシャル メディア 判断 決定 情　報 業務システムやネット から生成される素材 　構造や体系を与え整理 　必要性や信頼性に 　基づき取捨選択し、 　内容を分析して、 　解釈や価値判断を追加 Data Information Intelligence Decision 【図解】コレ１枚でわかるDataとInformationとIntelligenceの違い   私たちが、普段使っている「情報」という言葉に相当する英語の意味を考えてゆくと、３つの単語に分かれることに気付かされます。この違いを正しく理解できれば、BIアプリケーションとは何かを理解することができます。 Data 業務システムやWebサイト、ソーシャルメディアから日々生成される数字や文字列、特徴や出来事に関わる記述などを収集したものです。それらだけをみても、そこにどのような意味があるのか分からない状態の素材に当たる「情報」です。 Information 素材であるDataを「営業店ごとの商品別売上一覧」とか「製品Aについての製造歩留まり率の推移」というように、なんらかの基準に基づき構造や体系を与え整理したものです。表やグラフといった形でわかりやすく整理されている「情報」です。 Intelligence 次のようなケースを考えてみましょう。 「『営業店ごとの商品別売上一覧（=Information）』をみると支店Xの商品Aの売上が、6月度に大幅に減っている。その原因は、競合他社が、商品Aを狙い撃ちして地域限定のキャンペーンを行ったことが原因。競合他社は、この成功を参考にして同様のキャンペーンを全国に展開する可能性がある。従って、先手を打って、こちらが先にキャンペーンを仕掛けることが賢明である。」 このように、与えられたInformationを必要性に基づき取捨選択し、内容を分析し、価値判断を与えられたものがIntelligenceです。 Informationを分析、評価して「洞察（insight）」した結果の「情報」と言えるでしょう。この洞察がないものは、Informationであって、Intelligenceとは言えません。 米国にCIAという組織がありますが、正式な名称は、Central Intelligence Agencyです。世界中から政治や経済、軍事などのDataを集め、Informationに加工し、国家の政策決定に影響を与えるものはどれかを分析、評価して、専門家の解釈を加えたIntelligenceを、大統領や政策決定者に報告する組織です。大統領や政策決定者は、そのIntelligenceに基づき、意志決定（Decision）を行います。 BIアプリケーションは、これまで、DataからInformationを創り出すための手段として使われてきました。そこに、最適化された将来計画を示してくれるBA（Business Analytics）が加わり、Intelligenceをもカバーするようになりました。さらに、人工知能の適用が拡がれば、より高度なIntelligenceをシステムが提供してくれることになるでしょう。 ETL BI BA 業務DB DWH 人工知能

アナリティクスとビジネス・インテリジェンス アナリティクス1.0 アナリティクス2.0 アナリティクス3.0 BI(Business Intelligence) 業務システム ソーシャル Webサイト 業務システム ソーシャル Webサイト 業務システム IoT/センサー DWH Data Warehouse Big Data DWH Big Data DWH データに基づく 社内業務に関連した 意志決定の支援 意志決定方法の改善と リアルタイム化 価値の高い製品やサービス の提供 　　　　　　RDB+列指向DB 　　　　　　NoSQL+Hadoop 　　　　　　人工知能 【図解】コレ１枚で分かるアナリティクス3.0   「経験や勘ではなく､事実に基づいて、ビジネス上の判断をできるようにすること」 その手段として、「ビジネス・インテリジェンス（BI: Business Intelligence）」が、これまでも使われてきた。ここに来て、人工知能が普及し、「アナリティクス（Analytics）」という言葉とともに、その融合がすすみつつある。両者はどう言う関係にあるのか。Harvard Business Review 2014.5月号「アナリティクス3.0」を参考に独自の解釈を加えつつ、コレ１枚にまとめてみた。 アナリティクス1.0 1960年代から急速に遡及したコンピューターは、企業内の様々な業務をデータとして捉える環境を整えていった。このデータを使って社内業務に関わる分析レポートや管理資料を作成し、経営や業務に関わる意志決定を行う仕組みとして登場したのがビジネス・インテリジェンス（BI）だ。 かつてコンピューターがバッチ処理主体で使われていた時代、管理レポート１枚を作るにもCOBOLなどのプログラム言語を駆使して作成しなくてはならなかった。そのため、プログラミングの専門知識がある情報システムの専門家にそれを依頼しなければならなかった。しかし、業務現場の意図を正しく伝えることや試行錯誤して視点を変えることなど行おうとすると、その都度彼らに依頼しなければならず、大変手間がかかっていた。 この状況を打開するため管理レポート作成や業務分析を情報システムの専門家に頼らなくても業務の現場や経営者ができるようにとの目的で作られた仕組みがBIだ。 BIでは、業務データから取り出したデータを解析専用のデータベース（DWH: Data Warehouse）に格納し、それを使って管理レポートを作成（リポーティング）したり、様々な視点からデータの組合せを変えて分析（OLAP分析）したり、統計的な手法でデータに内在する法則や関係を見つけ（データマイニング）たりなどの作業を行われるようになった。これを「説明的アナリティクス」と呼んでいる。 企業内の業務システムで生成されたデータを使い、企業活動をデータで説明するための分析を行う段階を「アナリティクス1.0」という。 アナリティクス2.0 情報システムの適用領域が広がり、業務結果やプロセスのデータ化はさらに拡大した。加えて、ECサイトの普及やマーケティングにおけるWebの利用、SNSの活用、さらにインターネットの普及により企業をまたがるデータも扱うようになり、益々扱うデータが増大してゆく。世に言うビッグデータ時代の幕開けだ。これらデータを活かして意志決定のきめ細かさや精度を高めると共に、リアルタイムな変化に即応することで、ビジネス・チャンスを逃さないための取り組みが始まった。 しかし、膨大なデータが集まるようになっても、従来のリレーショナル・データベース（RDB）やDWHのために使われていた列指向データベースでは、リーズナブルなコストで効率よく扱うことができなかった。そこに登場したのが、NoSQLデータベースやHadoopといわれる大規模分散処理システムだ。さらに、ハードウェアの価格性能比が大幅に向上したことと相まって、より高度な分析を行えるようになった。 このような仕組みを使い高度な予測モデルを使って将来を予測し、最適なビジネス・プランを策定するなどの領域へと拡がっていった。これを「予測的アナリティクス」という。 社内外の大規模データを使い意志決定の改善とリアルタイム化をすすめる共に、最適なプランニングへと適用範囲を拡げた段階を「アナリティクス2.0」と呼ぶ。 アナリティクス3.0 IoTの普及と共に企業が取り扱うデータは、飛躍的に拡大しようとしている。これらデータを業務や経営の効率化や最適化のためだけに使うのではなく、競争力のある商品やサービスの創出、あるいは、リアルタイムな市場の変化に連動して広告やサービスを自在に変化させることで、競争力の拡大や強化を図ってゆこうという時代に移ろうとしている。 そのためにリアルタイムなデータを使って大規模な解析やシミュレーションを行い、最適解を導き出し、再び現場へとフィードバックするCyber-Physical Systemsを基盤とした仕組みが作られようとしている。そのための手段として、これまでの集計や統計的アプローチに加え、人工知能を活用してゆこうという動きが始まっている。 これら手段を駆使し、システム自身が判断を下し現場への指示を行う「指示的アナリティクス」の段階を「アナリティクス3.0」と呼ぶ。 アナリティクスの進化は、これからも続くだろう。その牽引役は人工知能になる。人工知能は、アナリティクス2.0の時代まで人間が経験と統計学知識で行ってきた最適モデルの設定や結果の解釈、意志決定を自ら行おうとしている。データサイエンティストや現場管理者が行っていた仕事を奪うかもしれない。そんな変化の中で、どう折り合いを付けてゆくかが、今後の課題となってゆくだろう。 説明的アナリティクス リポーティング、OLAP分析、データマイニング 予測的アナリティクス 予測モデルとプランニング 指示的アナリティクス 大規模テストと最適化 Harvard Business Review 2014.5月号「アナリティクス3.0」を参考に独自作成

ビジネス・インテリジェンスの適用とツール 経営戦略や経営計画の立案 事業部門への指示と実行 月次などで行う経営会議での モニタリングと問題点の分析 の指示 問題点の分析と問題点を修正 するための意思決定と指示 ソーシャル・メディア Webサイト 業務システム IoT/センサー 全社の戦略に沿った部門別 の計画立案 部門での業務実行 日々のモニタリング 問題点の分析と上位部門へ の報告や修正 経営層の目的 現場部門の目的 ビックデータ DWH 構造化データ 非構造化データ アナリティクス Analysis BI Business Intelligence レポーティング OLAP分析 データマイニング プランニング 問題の兆候を発見する 問題の要因を検証する 対処のヒントを得る 計画の根拠を得る 集計、推移、比較、内訳、順位、関係、シグナル表示 多次元データベース、スライシング、ドリルダウン＆ドリルアップ、ドリルスルー クロス分析、相関分析、回帰分析 モデリング、シミュレーション Webリポート（リポートをWebページなどで多数のユーザーに公開） ダッシュボード（複数のリポートを単一の画面で表示） 大量の分析元データの処理 最新の分析元データの共有 大量の分析元データの処理 より高度なマイニングアルゴリズムの利用 多くの部署から収集された計画データの統合 BI：Business Intelligence BA：Business Analytics

アナリティクスとビジネス・インテリジェンス 判断・意志決定 行動・実行 データ収集・評価 Business Intelligence ビジネス判断を行う上で役立つ情報 可視化 分析 ソーシャル インターネット Analytics アナリティクス TwitterやFacebookなどの ソーシャルメディアやWebサイト 分析 CRM 業務データ SCM ERP

Business Intelligence アナリティクス・プロセス ソーシャル・メディア Webサイト 業務システム IoT/センサー アナリティクス プロセス データ収集 データ蓄積 DWH 行動 検証・評価 集計・分析 Business Intelligence 洞察 【図解】コレ１枚で分かるアナリティクス・プロセス   「経験や勘ではなく、事実に基づいてビジネス上の判断をできるようにすること」 「アナリティクス」の目的のひとつだ。ではどのような手順でこれをすすめてゆくのか。そのプロセスをコレ１枚にまとめた。 業務システムからの業務データ、インターネットにつながるECサイトやマーケティングサイトからの取引や顧客に関わるデータ、IoTデバイスから送られるセンサー・データなど、膨大なデータが企業活動に伴い日々生みだされている。これらデータを収拾、蓄積する受け皿が、DWH（Data Warehouse）だ。 これらデータを、意志決定に関わる人が「何を見たいか」に従って集計し、統計的な分析を加えて、表やグラフなどでわかりやすく表現する。意志決定者は、それを見て様々な洞察を得ることができる。これがBI（Business Intelligence）だ。 次に、ビジネス上の目標をどのように達成すれば良いかを考える必要がある。そこで、将来を予測するための計算モデルを使い、目標達成のためにどのような施策を打てば、予測値がどのように変化するかをシミュレーションしてみる。既に得ている洞察を手掛かりに、シミュレーションを繰り返し、ビジネス目標達成のための最適な計画を作り上げてゆく。これをBA(Business Analytics)と言う。 作られた計画は、行動に移されるわけだが、その結果もまたデータとしてフィードバックされる。これを当初の計画に照らし合わせ、検証・評価して、必要とあれば再びBAによる予測・最適化を行い、計画を修正し行動を修正する。検証・評価の結果は、再びデータとして収集・蓄積され再びこのサイクルに還元される。 このサイクルは、アナリティクスのためのシステム・ツールを使わなくても、実際のビジネスの現場では行われていることだ。しかし、その多くは、狭い業務範囲に限られ、経験や勘に支配されている。これらを企業全体の視点で、データという事実で捉え、正確で的確な意志決定を行うためにアナリティクスのためのツールが使われる。 予測・最適化 Business Analysis 計画

Business Intelligence アナリティクスのプロセス 業務 アプリケーション ETLシステムから書き出されたデータを保管するデータベース。アナリティクスでの利用を前提として、企業内のデータを網羅的に一括して検索・分析できるよう、フォーマットや項目を揃え、蓄積する。 BIアプリケーション SCM 人工知能 CRM データ 収集 解析目的に適合したデータ、手法、モデルの選択 BI Business Intelligence 解析結果の解釈や解釈に基づく指示・アドバイス ETL ERP 生産管理 DB DWH BA Business analysis データ 抽出 【図解】コレ１枚でわかるアナリティクス・プロセス   CRMやSCM、生産管理システムなどの業務アプリケーションからは、日々膨大なデータが生みだされています。それらは、それぞれの業務を効率よく処理するために作られたシステムであり、生みだされるデータも、その目的のためのみに使用されています。これらデータの中から業務の状態を可視化するために、あるいは、業務上の課題や知見を見つけ出すために、データを抽出・収集し、BIアプリケーションのためのデータベースDWH（Data Warehouse）に集める必要があります。 しかし、業務システムのデータベースは、それぞれの業務処理に最適化されているため、そのままのデータ形式でDWHに集約・統合することはできません。そこで、各業務システムのデータをDWHのデータ形式に加工・編集する必要があります。そのためのシステムが、ETL (抽出:Extract, 変換:Transformation,書き込み:Load)システムです。ETLシステムは、次のような処理を行います。 【不要なデータの削除】分析では不要なデータや異常なデータについて削除する。 【値の変換】Null値の変換や、データ型の変換（日付→文字列など）を行なう。 【クレンジング】システム間でコードの意味が違う場合にそれを統一するなど、データの意味をそろえる。また、データ内に不整合があった場合にそれをエラーとしたり、一定のロジックで変換したりする。 【統合・集計】 複数のシステムから抽出した別のデータを1つのデータとして統合する。また、たとえば業務システムでは日単位のデータを月単位に集計するなどの集計処理を行なう。 ELTシステムによって加工編集されたデータは、DWHに書き込まれます。このDWHは、次のような特徴を持っています。 【項目別】基幹システムは「機能別」に設計されており、データには「目的」がある。DWHでは、これを項目（サブジェクト）毎に再構成する。 【統合化】様々なシステムからのデータを一つに統合するために、データフォーマットの変換や抽象化などを行う。 【非更新】データの修正があった場合でも、古いデータを削除したり、上書きしたりせずに、追記し、履歴を完全に残す。 【時系列】データを上書きせずに追記していくことによって、過去のある時点でのデータを参照できるようにする。 なお、多くの業務機能を統合したERPパッケージの中には、業務処理とBIアプリケーションでの使用を同一のデータベースで行おうという製品もあり、その場合は、ETLシステムは不要となり、DWHもERPシステムのデータベースに統合されています。 DWHのデータは、BIアプリケーションによって処理されます。その際、解析の目的に適合したデータや最適な解析手法、予測モデルを選択しなければなりません。また、解析の結果を解釈し、指示やアドバイスを導き出すことも必要です。この役割を担うのがデータサイエンティストです。 なお、この役割を人工知能に置き換えようという取り組みも行われており、IBMのWatson Analyticsなどは、そんな取り組みを行っています。 企業の基幹系システムなどに蓄積されたデータを抽出（extract）しDWHで利用しやすい形に加工（transform）し、対象となるデータベースに書き出す（load）。 業務DB 業務DB データサイエンティスト 効率的な業務処理 適切・迅速な意志決定

ETL (Extract, Transformation and Load) ERP 不要なデータの削除 分析では不要なデータや異常なデータについて削除する。 値の変換 Null値の変換や、データ型の変換（日付→文字列など）を行なう。 クレンジング システム間でコードの意味が違う場合にそれを統一するなど、データの意味をそろえる。また、データ内に不整合があった場合にそれをエラーとしたり、一定のロジックで変換したりする。 統合・集計 複数のシステムから抽出した別のデータを1つのデータとして統合する。また、たとえば業務システムでは日単位のデータを月単位に集計するなどの集計処理を行なう。 CRM SCM SFA DWH POS Extract Transformation Load 製造管理システム 販売管理システム DBのレプリケーションが主目的 リアルタイム性はあまり考えられていない 会計システム EAIやESBを使えばリアルタイムのデータ連係も可能 ただし、他システムへの負荷を考える必要有り

データウェアハウス DWH Data Warehouse 基幹システム データウェアハウス トランザクションを高速処理することが目的 頻繁に更新、長期保存は前提にせず リレーショナル・データベースが一般的 高速な検索や集計処理することが目的 追加のみ、更新は行われない 列指向型データベースが広く利用 データウェアハウスの要件 項目別 基幹システムは「機能別」に設計されており、データには「目的」がある。DWHでは、これを項目（サブジェクト）毎に再構成する 統合化 様々なシステムからのデータを一つに統合するために、データフォーマットの変換や抽象化などを行う 非更新 データの修正があった場合でも、古いデータを削除したり、上書きしたりせずに、追記し、履歴を完全に残す 時系列 データを上書きせずに追記していくことによって、過去のある時点でのデータを参照できるようにする

データウェアハウス（DWH）とデータマート（DM） 業務処理 分析処理 分析目的別サマリー・データベース 　　独立 　　データマート型 業務DB DM ユーザーが、目的に応じて個別にデータマートを作成する方式 規模が小さい場合や特定目的で簡単に作れる点では便利。 システム規模拡大するとＤＭが増殖し、タスキ掛けで相互にデータのやりとりが発生。データの重複保有も増加。 業務DB DM 業務DB DM 　　従属 　　データマート型 業務DB DM データウェアハウスから切り出されたデータを格納した目的別データマートを参照する方式 データロード・管理の複雑さやデータ品質、データ同期の問題を解消。 データベースの数は多く、データベースソフトウェアのライセンス費用や運用人件費などが高くつく。 DWH 業務DB DM 業務DB DM 分析に必要となるあらゆる情報を集めたデータベース 直接 データウェアハウス型 業務DB リアルタイムBIの基盤 DWH データマートを廃止し、ひとつのDWHに全データを統合、多数のユーザーを同時にサポートする方式 運用の容易さ、システム変更のしやすさ、維持コストの安さなど データマートの全廃が簡単でないことや高い処理能力を持つシステムが必要 業務DB 業務DB 低コスト・新鮮

統計分析 人工知能 データサイエンティスト ビッグデータ 経営や業務上の課題 顕在的・潜在的な問題 判断のつかない事態や選択肢 非構造化 半構造化 構造化 テキスト 動画 音声 XML JSON 文書 業務データ GPS センサー NoSQLデータベース 関係データベース 統計分析 人工知能 プログラミング・IT スキル データサイエンティスト 統計知識・解析 スキル コンサルティング スキル 【図解】コレ１枚で分かるデータサイエンティスト   ネットサービスやソーシャルメディアの普及、IoTの需要拡大により、収集・蓄積が可能なデータの種類と量が急激に増大しています。これらの膨大なデータ（ビッグデータ）は、何らかの目的を持って分析されて始めてビジネスや生活に役立つ洞察や知見を引き出すことができるのです。この分析に携わる専門家が、「データサイエンティスト」です。 彼らは、経営や業務上の課題を正しく理解し、ビッグデータに内在する関係や傾向を統計的な知識や手法、あるいは人工知能などを駆使して分析し、課題解決の手段や問題の原因、最適化の方法を探り出します。 例えば、次のような仕事が考えられます。 ECサイトへのアクセスから生みだされる膨大なデータから顧客がどう行動するかのパターンを推論し、最も売り上げが上がるページの配置や商品の紹介方法を提案すること ソーシャルメディアで交わされている会話を分析し自社の商品の評判やクレームなどを見つけ出すこと 製造工程での計測データやその後のクレーム対応状況から、製品の欠陥や不具合を見つけ出すこと　など 彼らがこのような役割を果たすためには、次の3つのスキルが求められます。 データ分析のための統計学の知識とこれを使いこなす解析スキル 業務や経営の課題を整理し、わかりやすく表現・説明できるコンサルティン・スキル ビッグデータを解析するためのプログラムを書くことや解析ツールを使いこなすためのITスキル ビックデータがいくらあっても、それを分析できなければ使い道はありません。そんなことから、このような「データサイエンティスト」という仕事にもいま熱い視線が注がれているのです。 ただ、このようなデータサイエンティストのノウハウを人工知能に代替させようという取り組みも始まっています。IBMのWatson Analyticsは、そんな取り組みのひとつです。例えば、次のような日常的な言葉で、質問をします。 今期予算が達成できなかったのはなぜか？ 自社の売り上げの主な促進要因は何か？ 締結できる可能性が最も高い契約はどれか？ どうすれば自社サービスの解約率を下げられるか？ 最も利益の高い製品の組合せはどうすれば良いか？ Watson Analyticsは、この質問の内容や意味を分析し、該当するデータや解法を選択、答えとなる表やグラフを提示してくれます。 「何のために、何を知りたいか」は、人間が決めなければなりません。また、結果を解釈し、どのように判断するかは、人間に任されています。しかし、必要なデータを揃え、どのような方法で分析すれば良いかは、機械が考えるといった役割分担が、当たり前になるのかもしれません。 経営や業務上の課題 顕在的・潜在的な問題 判断のつかない事態や選択肢 課題解決の手段 問題の原因 最適化の方法や数値モデル

IBM Watson Analytics データ分析作業をなくす 今期予算が達成できなかったのはなぜか？ 自社の売り上げの主な促進要因は何か？ 締結できる可能性が最も高い契約はどれか？ どうすれば自社サービスの解約率を下げられるか？ 最も利益の高い製品の組合せはどうすれば良いか？ Excelデータをインプットすると 何を調べて欲しいかの選択肢を提示 データ分析作業をなくす 質問内容・意味の分析 状況分析 最適解の選択

参考：Magic Quadrant BI 2015 http://www.gartner.com/technology/reprints.do?id=1-2ADAAYM&ct=150223&st=sb 実行能力に優れていますが、新たな顧客に最新かつ強力な価値を提案する戦略を欠いている。成熟市場で大手ベンダーがチャレンジャーに位置付けられることが多いのは、リスクを最小化することを選択しているため。 今日の市場ニーズに対応する成熟した製品をリリースしており、市場が進化した場合でもリーダーの座を維持できるビジョンも明示。自社製品への集中的な取り組みと投資を通して、市場全体の方向性に影響を及ぼす。 特定の市場セグメントで成功を収めているか、またはイノベーションを実現する能力や競合他社を上回るために必要な能力が限られている。この理由としては、1つの機能や地域に注力しているか、また市場への新規参入から日が浅いこと。 ビジョンを実現する能力が十分に実証されていない。新興市場では一般的。しかし成熟市場では、中小規模ベンダーの競争戦略（主流の需要が生まれる前に革新的な製品を販売するなど）や大手ベンダーが凡庸な製品を排して差別化に進もうとしている状況を反映していることがある。

ネットコマース株式会社 180-0004 東京都武蔵野市吉祥寺本町2-4-17 エスト・グランデール・カーロ 1201 180-0004　東京都武蔵野市吉祥寺本町2-4-17 エスト・グランデール・カーロ 1201 http://www.netcommerce.co.jp/