近年、DX推進を背景として、ERPをはじめとした様々な業務システムのデータを1箇所に集約し、経営に活かす全社的な取り組みが増えています。集約したデータをもとに洞察を得て意思決定を行ったり、新たなビジネス価値を創出したりといった動きの中で、データ活用がますます注目を集めています。

本ブログでは、全社的なデータ活用の取り組みを効果的に進めていくためには一体どのようなポイントをおさえておくべきなのか、解説します。

ERPデータ活用のための3つのポイント

データ活用を進めていくには「目的」、「基盤」、「組織」の3つのポイントが重要になってきます。

1. 「目的」について
   「とりあえずいろいろなデータを1箇所に集めること」に意味はなく、目的は「意思決定のために活用すること」にほかなりません。その目的のためには何が必要なのか、ここを十分に整理していくことがはじめの一歩としては欠かせません。
2. 「基盤」について
   大きくは「データ収集」、「データ蓄積」、「データ分析」の3つのポイントに分けられますが、エンドユーザーが継続的に利用できるデータ基盤を提供していくためにはいくつかのポイントをおさえていく必要があります。
3. 「組織」について
   データ基盤は作ったらおしまいではなく、企業の成長に合わせて継続的にビジネス価値を創出していく必要があります。そのためにはデータ基盤を進化させるための組織づくりが欠かせません。

上記3点について次章以降で解説していきます。

ERPデータ活用のための目的と要件の整理

データ基盤を構築するにあたって「既存のBIシステムと同等かそれ以上のことができること」を要望として掲げられるケースが多いのではないかと思われますが、はたしてそのアプローチは正しいのでしょうか？
そもそもデータ分析の結果を利用して、どのような課題を解決し、どのような価値を創出したいのか、ということをこの機会に改めて定義すべきだと思われます。
データ基盤構築に限らずどのようなプロジェクトにおいても「既存の仕組みをベースに考えた結果、アドオンやカスタマイズなどの開発費用が当初計画よりも大幅に膨らんでしまった」というのはよく聞く問題かと思います。このような問題を防ぐためにも、目的を明確にし、どういった課題に対してどのようなことを実現したいのか、といった幹をはっきりとしておくことで、本当に必要な価値にフォーカスした要件の取捨選択を進めていくことができると考えます。

データ活用の大きな目的を定めたあとは、どういった情報が必要になるのかといった具体的な要件を整理する必要があります。その際、「業務帳票やエンドユーザーがEUC的に作成しているレポートなど、既存の情報をもとにデータ基盤に必要となる情報を整理する」といったアプローチを選択するケースが多いかと思われます。しかし、エンドユーザーが作成しているレポートを整理しようにも、その数が全部で数百～数千に及ぶことも珍しくなく、これらすべてを1つ1つ確認して整理をしていくというのは現実的ではありません。
こういったケースについては、個別の既存レポートをもとに必要な情報を紐解いていくアプローチよりも、ERPなどの基幹業務システムで提供できるデータをもとに既存レポートに不足しているものを付け足していくアプローチのほうが効率的です。

分析に用いる指標というのは多少の違いはあれ多くは共通化できるものかと思います。例えば、売上情報の場合、分析軸としては年月/得意先/品目など、値としては売上数/売上金額/売上原価などが考えられると思います。市販のBIツールの中にはテンプレートとしてこういった共通指標を最初から備えているものもあるので、パッケージを利用したアプローチというのは非常に効果的な方法の1つだと考えられます。

共通指標をある程度決めた上で個別のレポート確認等を行い、不足しているものがあればその重要度がどれくらいであるのか、5W1Hなどの形で整理していきます。また分析のために求められているのが固定帳票なのかそれとも自由分析なのかを整理しながら、最終的には目的に紐づいたレポート要件に落とし込んでいくことが重要となってきます。

ところで、データ分析については以下のような4種類の考え方があることをご存知でしょうか？

「記述的分析」と「診断的分析」の2つは、過去から現在を分析するためのBIツールが該当し、多くの企業がこのレベルの分析にとどまっていると言われています。

一方、「予測的分析」と「処方的分析」の2つは、BIツールに加えて、機械学習をはじめとしたAIが適用される形となります。
データ基盤を構築していく上で中長期的な視点も含め、どこまでの分析を行っていくことを目標とするのか、上記の視点も含め整理してくことが求められています。

ERPデータ活用のためのデータ基盤の構築

データ基盤を構成するコンピュータシステムは「データ収集」、「データ蓄積」、「データ分析」の3つに大きく分けられます。

1. 「データ収集」システム
   ERPなどデータ基盤の外部にあるデータの発生源である「データソース」からデータを集める機能を担います。
2. 「データ蓄積」システム
   データを「データレイク」、「データウェアハウス」、「データマート」に分けて保持します。
   詳細な説明はほかに譲りますが、
   　- データレイク：もとのデータをそのままコピーしたものを格納する場所
   　- データウェアハウス：複数のデータを統合・蓄積して意思決定に活用できるように共通指標を整理したデータを格納する場所
   　- データマート：特定の用途や利用者向けに加工/整理したデータを格納する場所
   となります。
   すべての仕組みが上記のように3つに分かれているわけではなく、「データレイク」と「データウェアハウス」もしくは「データウェアハウス」と「データマート」を兼ねている、など様々なケースがありますが、基本的には上記3つの役割のいずれかを担う形になっているかと思われます。
3. 「データ分析」システム
   蓄積したデータを分析することで、エンドユーザーに対して価値を提供します。

データ基盤の構築にあたっては、3つのポイントの中でも、「データ収集」がある意味もっとも取り扱いが難しい部分となります。
データ収集のためには、データソースごとに収集方法を使い分ける必要があることが大きな理由となります。

データ基盤には様々な業務システムからデータを収集することが予想されるため、OracleやSQL ServerといったDB製品の違いから、業務システム固有の制約など、様々な要件に対応をしていくことが求められます。
例えば、ERP製品のデファクトスタンダードであるSAP ERPの場合、DBは独自の特殊データを保持する形となっているため、DBを直接参照してデータエクスポートをしただけではデータの使用はできないようになっています。
また、日々蓄積される業務データを毎回全件転送するようではデータ転送に多くの時間がかかることとなるため、差分でデータ転送ができる仕組みが不可欠となります。
加えて、テーブルによっては単純に登録日、更新日だけではなくSAP標準の変更文書情報を用いなければ最新のデータを差分取得できないなど、様々な制約条件が存在します。
さらに、これらの特徴を踏まえたデータエクスポートの仕組みを開発する場合、独自のプログラム言語ABAPを用いることとなり、開発には多くの費用がかかることが予想されます。
上記を踏まえ、データソースごとにどういった収集方法を用いるのか、個別に開発するのか、市販のパッケージを利用するのかなど、自社にあったツールを検討しておく必要があります。

ERPデータ活用を支える組織と役割

データ基盤の構築および運用、維持、改善をしていくためにはデータ基盤を支える組織の存在が欠かせません。一般的には情報システム部門がその役割を担うケースが多いかと思いますが、近年、データマネジメントやその知識体系をまとめたDMBOKなどの考え方をもとに様々な役割が定義されてきています。
例えば、MicrosoftではAzureデータの基礎の中でデータを扱う仕事上の役割として「データベース管理者」、「データエンジニア」、「データアナリスト」の3つの役割を定義しています。また、その他にもデータマネジメントの世界では一般的にもよく知られることとなった「データサイエンティスト」や「データアーキテクト」といった役割が定義されているほか、全社横断的な役割として「チーフデータオフィサー(CDO)」や「チーフデータアーキテクト(CDA)」といった役割も定義されています。
このように様々な役割の中でも、本ブログでは「データスチュワード」に注目をしてみたいと思います。

「スチュワード(steward)」は日本ではなかなか聞き慣れない単語ですが、日本語に訳すと「執事」や「幹事」、「世話役」といった意味合いになります。「データスチュワード」は「データ活用者（いわゆるエンドユーザー）」にとっての相談窓口になります。「データ活用者」のニーズを確認し、ニーズを実現するにはどうすればいいのか「データアーキテクト」と協調しながら改善案を策定していくこととなります。「データアーキテクト」がデータ基盤などシステムの専門的なスキルセットを持った役割だとすると、「データスチュワード」には業務に関する専門的なスキルセットが要求される役割となります。そのため「データスチュワード」はシステム部門からではなく業務部門から選出されることが望ましいといえます（「データアーキテクト」には業務面の、「データスチュワード」にはシステム面の、専門的レベルではないにしてもそれなりの知見があることが望ましいです）。

ある企業の取り組みを例に、「データスチュワード」について解説します。
この企業では、データ基盤構築プロジェクトの社内体制を構築する際、情報システム担当者と業務担当者を交えたチームを組成しました。この組織では、「データスチュワード」といった役割を明示していたわけではありませんが、結果的に業務担当者が中心となり、「データスチュワード」的な役割を実施する形となっていました。また、当該プロジェクトでは、弊社エンジニアが「データアーキテクト」としての立場で支援作業を行っていました。
具体的な流れとしては、エンドユーザーから上がってくる様々な改修要望に対して、業務担当者を中心に要望を取捨選択いただき、それでも必要となる改修要望については弊社エンジニアと実現内容の調整を行う形となっていました。この中で、業務担当者からは業務面の知見を交えて改修要望に関する業務上の位置づけや経緯等を踏まえてご説明いただくことができました。また、弊社エンジニアからの改修要望に関する仕様確認なども、どこまで対応ができていれば「データ活用者」が業務で利用をできるのか等を踏まえた上でご回答いただくなど、双方にとって納得感のある形で各種対応を進めることが出来たことは非常に大きなメリットがあったと感じています。
もし、業務的な知見を持つ「データスチュワード」的な役割を担う担当者がいなかった場合、改修要望に対して決してシステムには明るくない「データ活用者」へ都度確認を行うこととなり、対応には非常に時間がかかってしまうことが予想されます。

ERPデータの活用に向けて まとめ

全社的なデータ基盤を構築するプロジェクトは、規模も大きく、当然ながら数多くの課題が発生します。その中でも本ブログに記載の内容が何かしらのお役に立つことがあれば幸いです。

もし、SAP ERP（もしくはSAP S/4HANA）をご利用中であれば、弊社電通総研が提供しているBusinessSPECTREを用いることで、すでに用意されている共通指標/データセットをもとに、SAP ERPから取得するデータを用いたレポート要件の整理にお役立ていただいたり、SAP ERPからのデータ収集をすぐに実現いただいたりと、SAP ERPまわりのデータ活用の課題解決の一助を担うことが可能です。
◆ BusinessSPECTREご紹介ページ：https://erp.dentsusoken.com/solution/sap-bi-businessspectre/

また、弊社電通総研は、データマネジメントの専門家として、全社的なデータ活用の推進/データ基盤の構築について様々なアドバイスやご支援が可能です。
データ活用についてお悩みの場合は、是非、電通総研までお問い合わせください！！
◆ お問い合わせページ：https://itsol.dentsusoken.com/snowflake/inquiry/

＊本記事は、2023年2月1日時点の情報を基に作成しています。
　製品・サービスに関する詳しいお問い合わせは、電通総研のWebサイトからお問い合わせください。