業務プロセスとデータの枠組み
分析屋の下滝です。別連載で「DXとマーケティング」を書いています。
この新しいシリーズでは、業務プロセスとデータとの関係を中心に、データ活用を考えるのに役立つような枠組みを考えていきたいと思います。
データ活用という文脈での枠組み作成にあたり、まずは「業務プロセス」と「データ」、そしてそれらに付随して考えると良いかもしれない対象を考えました。付随する対象としては「KPI」と「意思決定者」があると良いかもしれないとして追加しました。「KPI」は単に「目的」や「評価基準」としても良いかもしれません。
これら要素をもとに、単純な枠組みとして以下を考えました。
この枠組の解釈としては以下のようになります。
・意思決定者は、業務の成果の基準としてのKPIを参照する。
・意思決定者は、KPIを達成するために、業務プロセスに関して何らかの意思決定を行う。
・業務プロセスは、データを生み出す。
・意思決定者は、データをもとに、意思決定を行う。
これらの概念（コンセプト）が、この連載の議論の範囲を決めます。したがって、枠組みとなります。この枠組みは、現実をうまく表現しきれていないという意味で間違っているかもしれません。「すべての現実を正確に表現できること」が枠組み自体の評価基準とはなりませんが、目的の設定は必要かもしれません。ただ、まだ私自身も目的がはっきりしていないので、このまま進めます。こういう枠組みがあると、データ活用の世界を理解しやすくなるのではないか、というくらいの意識です。
枠組みから分かること
この単純な枠組みからは、たとえば、以下のような単純な状況のパターンが予測できます。
・KPIが間違っている状況
・業務プロセスに対する意思決定が間違っている状況
・業務プロセスが間違っている状況
・業務プロセスから生み出されるデータが間違っている状況
・意思決定者のデータに対する扱い方が間違っている状況
別の言い方もできます。各要素の評価を行うことで、状況の適切さが分かるという視点です。
・KPIが適切か評価するプロセスが必要
・業務プロセスに対する意思決定が適切か評価するプロセスが必要
・業務プロセスが適切か評価するプロセスが必要
・業務プロセスから生み出されるデータが適切か評価するプロセスが必要
・意思決定者のデータに対する扱い方が適切か評価するプロセスが必要
評価ということなら、さらに考えることができます。
・KPIが適切か評価するプロセスが必要。それには、評価項目の設定が必要。
・業務プロセスに対する意思決定が適切か評価するプロセスが必要。それには、評価項目の設定が必要。
・業務プロセスが適切か評価するプロセスが必要。それには、評価項目の設定が必要。
・業務プロセスから生み出されるデータが適切か評価するプロセスが必要。それには、評価項目の設定が必要。
・意思決定者のデータに対する扱い方が適切か評価するプロセスが必要。それには、評価項目の設定が必要。
これらのくらいの話になると、それぞれが実務的な課題として扱えるような気がします。評価するプロセスを、明示的に定義していることは少ないと思われます。もちろん、検討した上で定義していないという事はありえます。
枠組みでは、各要素に対して評価するというプロセスがある、ということは煩雑になるので表してはしませんが、存在するとしておきます。
表現できるか試してみる
枠組みが、より具体的な現実をうまく表現できるか試してみます。ここでは、デジタルガレージの渋谷直正氏の記事の例を試してみます。
データ分析をしていいことは何？ デジタルガレージ渋谷氏が解説
渋谷氏によれば、データ利活用の道筋は大きく分けて以下の3つがあるとのことです。詳しくは記事を参照してください。
１．既にデータを使っている業務を、より効率化・高度化する
２．現在は勘や経験に基づいて行っている業務を、データを使って効率化・高度化する
３．データを使うことで、新たなサービス、ビジネスを生み出す
今回は１について考えたいと思います。１の例として以下があげられています。
・毎月の経営会議や営業現場における実績数字の集計と報告
・一部の部署における売上需要予測
この例の１つ目にさらに着目したいと思います。少し長くなりますが、引用します。
ここは最も取り組みやすく、効果が実感しやすいものだ。例えば、月次の経営会議に報告される実績数字の集計は既にできているといっても、実はその集計のために担当者が1週間かけて数字を集めてExcelと格闘しているかもしれない。あるいは、最初につくった担当者のフォーマットがブラックボックス化していて、後任者は中身が分からず引き継いだやり方でただ数字を拾って埋めているだけかもしれない。大きいメッシュで集計された紙の表を見た経営陣は、会議の席上でより詳細な、例えば「東北地区の営業所別の年間の月別実績推移を見たい」と言い出すかもしれないが、そもそもそういうメッシュでのデータはすぐに出せないため、「後日集計してご報告します」となることもしばしばありそうだ。貴重な経営会議の場でリアルタイムの議論ができないのは大きな損失だが、固定化した「作業」と化してしまっている定例報告資料づくりでは、そういう特定の用途の集計（分析以前のレベル！）ですらままならない。こうした定例報告数字にまつわるあるあるは、比較的容易にデータドリブン化が可能な領域でもある。
いわゆる見える化やダッシュボードづくりを進めることが最適解となる。きれいなグラフをつくり出すことよりも、集計された数字がどういうロジックで生み出されているのかをひもとく過程の方が、多くの気付きや無駄の排除を与えてくれる。正しい数字と思っていたものが実は部署ごとに基準が違っていたり、重複カウントがあったりといったミスが発覚することもある。求められる最小粒度の数字をデータベースにあらかじめ毎月自動で格納しておくようにすれば、後はどのような軸でも集計が簡単にできるようになる。先の会議の席上での経営陣の要求にも、その場で動的にグラフを見せることが可能になるだろう。何よりも毎月担当者が多くの工数をかけていた作業が大幅に削減される効率化効果は計り知れない。
データ分析をしていいことは何？ デジタルガレージ渋谷氏が解説
上記の状況を、我々の枠組みで表現できるか？ 表現できない要素は何か？ という視点で見ていきます。
1つ目から。
例えば、月次の経営会議に報告される実績数字の集計は既にできているといっても、実はその集計のために担当者が1週間かけて数字を集めてExcelと格闘しているかもしれない。
ここでは、いったん、以下のような抽象度と汎化の度合いで要素を特定しました。
・集計と報告の業務プロセスがある。
・集計と報告を行う担当者がいる。レポート作成者と呼ぶことにします。
・集計と報告を行うために使うツールがある。
・報告されるレポートをもとに意思決定する人がいる。レポート利用者と呼ぶことにします。
いくつかの要素はいったん無視しました。「月次の経営会議」「1週間かけて数字を集めて」「実績数字」です。また、「Excel」は「ツール」としました。集計と報告の業務プロセスは分解できますが、一連のものとして一つにまとめて扱うことにしました。
では、最初の枠組みでどのように表現できるか考えてみます。
ここで、「集計と報告のプロセス」は、データを入力とし、レポートを出力するプロセスとして表現しました。もちろん、表現しきれていない現実もあります。たとえば、データだけでは何を集計し、何を報告すればよいのか分からない、ということです。枠組みとして、どこまで表現するのか、また、それを表現することでどのような利点があるのかは、段階的に評価してきたいと思います。
また、「集計と報告のプロセス」も業務プロセスの一種ではないのか、という指摘もあると思います。より厳密なモデリングに関しては後に議論したいと思います（Meta-Object Facilityのような領域になるかと思います）。
では、以下に戻ります。
例えば、月次の経営会議に報告される実績数字の集計は既にできているといっても、実はその集計のために担当者が1週間かけて数字を集めてExcelと格闘しているかもしれない。
ここで「担当者が1週間かけて数字を集めてExcelと格闘しているかもしれない」というのは、「集計と報告のプロセス」の評価と言えそうです。プロセスの生産性の評価、といってもいいかもしれません。暗黙的には、効率化できる、効率化することが課題だということだと言えそうです。
枠組みからは以下のように「集計と報告のプロセス」の評価に関係する要素が特定できそうです。
・「データ」に問題がある。たとえば、そもそもデータが膨大。
・「レポート作成者」に問題がある。たとえば、経験不足。
・「集計と報告ツール」に問題がある。たとえば、処理が遅い。
・「レポート」に問題がある。たとえば、見た目の加工多い、複雑。レポート数が多い。
・「集計と報告のプロセス」に問題がある。たとえば、効率が悪い。
次の文に移ります。
あるいは、最初につくった担当者のフォーマットがブラックボックス化していて、後任者は中身が分からず引き継いだやり方でただ数字を拾って埋めているだけかもしれない。
これに関しても、「集計と報告のプロセス」の評価と言えそうです。
・報告内容の変更容易性が低い
ということかもしれません。
次の文に移ります。
大きいメッシュで集計された紙の表を見た経営陣は、会議の席上でより詳細な、例えば「東北地区の営業所別の年間の月別実績推移を見たい」と言い出すかもしれないが、そもそもそういうメッシュでのデータはすぐに出せないため、「後日集計してご報告します」となることもしばしばありそうだ。貴重な経営会議の場でリアルタイムの議論ができないのは大きな損失だが、固定化した「作業」と化してしまっている定例報告資料づくりでは、そういう特定の用途の集計（分析以前のレベル！）ですらままならない。こうした定例報告数字にまつわるあるあるは、比較的容易にデータドリブン化が可能な領域でもある。
これに関しては、枠組みの表現不足のように感じました。「レポートをもとにした意思決定プロセス」というようなプロセスを明示的に表現できているべきかもしれません。そして、そのプロセスの評価として、「リアルタイムでの集計容易性」といったものがあるかもしれません。このプロセスをどのような基準で評価するのかを考える必要がありそうです。
枠組みを更新しました。
・「レポートをもとにした意思決定プロセス」を追加しました。
・「レポート利用者」を「レポートをもとにした意思決定者」に変更しました。
枠組みからは以下のように「レポートをもとにした意思決定プロセス」の評価に関係する要素が特定できそうです。
・「レポート」に問題がある。たとえば、間違っている。
・「レポートをもとにした意思決定者」に問題がある。たとえば、レポートを解釈できる前提知識が足りない。
・「意思決定結果」に問題がある。たとえば、誤った意思決定がなされる。
また、既に述べたようにプロセス自体の評価も対象になりそうです。
・「レポートをもとにした意思決定プロセス」に問題がある。たとえば、リアルタイムで新たな集計を容易に実施できない。
次の文に移ります。解決策のパートです。
いわゆる見える化やダッシュボードづくりを進めることが最適解となる。きれいなグラフをつくり出すことよりも、集計された数字がどういうロジックで生み出されているのかをひもとく過程の方が、多くの気付きや無駄の排除を与えてくれる。正しい数字と思っていたものが実は部署ごとに基準が違っていたり、重複カウントがあったりといったミスが発覚することもある。求められる最小粒度の数字をデータベースにあらかじめ毎月自動で格納しておくようにすれば、後はどのような軸でも集計が簡単にできるようになる。先の会議の席上での経営陣の要求にも、その場で動的にグラフを見せることが可能になるだろう。何よりも毎月担当者が多くの工数をかけていた作業が大幅に削減される効率化効果は計り知れない。
まずは最初の文から。
いわゆる見える化やダッシュボードづくりを進めることが最適解となる。きれいなグラフをつくり出すことよりも、集計された数字がどういうロジックで生み出されているのかをひもとく過程の方が、多くの気付きや無駄の排除を与えてくれる。正しい数字と思っていたものが実は部署ごとに基準が違っていたり、重複カウントがあったりといったミスが発覚することもある。
見える化やダッシュボードづくりを実施するプロセスにおいて、どんな利点がありえるのかを述べていると解釈しました。
暗黙的には、既存のプロセスの置き換えるプロセス、と言えるかもしれません。我々の枠組みで言えば、「集計と報告のプロセス」と「レポートをもとにした意思決定プロセス」が対象と言えそうです。
枠組みで表現してみます。
ここでは、「見える化・ダッシュボード化プロセス」を新たに追加しました。ここでは、「既存の集計と報告プロセス」を置き換えるプロセスだとしています。つまり、あるダッシュボードが作成された後、状況に応じてダッシュボードを更新していく業務プロセスとは別だと扱っています。
「見える化・ダッシュボード化プロセス」では、「既存の集計と報告プロセス」を入力して受け取ると考えました。プロセスがプロセスを入力とするのは、概念的には整理ができていませんが、現状のプロセスの情報を集め、ダッシュボード化のプロセスを進める、といったニュアンスです。
枠組みからは以下のように「見える化・ダッシュボード化プロセス」の評価に関係する要素が特定できそうです。
・既存の「集計と報告プロセス」に問題がある。たとえば、「正しい数字と思っていたものが実は部署ごとに基準が違っていたり、重複カウントがあったりといったミスがある」。
・「ダッシュボード化担当者」に問題がある。たとえば、ダッシュボード化ツールの経験値が低い。
・「ダッシュボードツール」に問題がある。たとえば、遅い。欲しい機能が備わっていない。
・「ダッシュボード」に問題がある。たとえば、間違っている。
・「見える化・ダッシュボード化プロセス」に問題がある。たとえば、レポートをダッシュボードに置き換えていく業務効率が悪い。
最後のプロセスの評価は、それら以外の関係要素から派生する結果かもしれません。
次の文に移ります。
求められる最小粒度の数字をデータベースにあらかじめ毎月自動で格納しておくようにすれば、後はどのような軸でも集計が簡単にできるようになる。先の会議の席上での経営陣の要求にも、その場で動的にグラフを見せることが可能になるだろう。
これは、「レポートをもとにした意思決定プロセス」と「ダッシュボードをもとにした意思決定プロセス」の違いであると言えそうです。
枠組みを更新しました。わかりにくくなってきたので、プロセスの色を変えました。
「ダッシュボードをもとにした意思決定プロセス」と関連する要素を追加しました。
枠組みからは以下のように「ダッシュボードをもとにした意思決定プロセス」の評価に関係する要素が特定できそうです。
・「ダッシュボード」に問題がある。たとえば、間違っている。
・「ダッシュボードをもとにした意思決定者」に問題がある。たとえば、ダッシュボードで表現されている情報を解釈できる前提知識が足りない。
・「意思決定結果」に問題がある。たとえば、誤った意思決定がなされる。
・「ダッシュボードをもとにした意思決定プロセス」に問題がある。たとえば、見たい軸がありすぎて議論が発散する。
問題の視点からプロセスを評価に関係する要素が特定しましたが、プロセスの比較ができるようになったので利点も議論できそうです。
・「ダッシュボードをもとにした意思決定プロセス」は、「集計と報告プロセス」に比べて優れている。たとえば「その場で動的にグラフを見せることが可能になる」。我々の言葉を使うならば「リアルタイムでの集計容易性」が高い。
他にも、比べることで何らかの示唆が得られるかもしれません。
・「ダッシュボード」は、「レポート」に比べて優れている。たとえば、何でしょうか。
・「ダッシュボードをもとにした意思決定者」は、「レポートをもとにした意思決定者」に比べて優れている。これは、どのような比較になるのか分かりませんでした。
・「意思決定結果」に関しても分かりません。プロセス違いが、出力としての「意思決定結果」の品質を決める、ということだけかもしれません。
最後の文に移ります。
何よりも毎月担当者が多くの工数をかけていた作業が大幅に削減される効率化効果は計り知れない。
これは、プロセスの比較の評価として解釈できそうです。
・「ダッシュボードをもとにした意思決定プロセス」は、「集計と報告プロセス」に比べて優れている。たとえば「作業が大幅に削減される」。
何を学んだか
ここまでを評価してみます。枠組みを使うことで、データ活用の世界の理解がどのように容易になりそうでしょうか。
今のところ、次のように考えています。業務プロセスの概念の中に、データ活用の概念が存在する。我々がまず着目すべきは、業務プロセスである。
では、この枠組みとこの枠組みの改善が「業務プロセスとデータ活用の世界の理解」をどのように容易にしていけそうかを見ていきます。
汎用的な要素の視点：まず、枠組みとして要素を明示的に表すことで、体系的な視点が得られるようになりそうです。前節で見たように、「プロセス」、「プロセスへの入力」、「プロセスの出力」、「プロセスの実行者」、「プロセスの実行において使用されるツール」が汎用的な概念として存在しそうです（これら汎用的な概念はまだ枠組みでは明示的には表現されていません）。そして、これら汎用的な概念（要素）は、より特化した具体的な要素として表現されます。たとえば「プロセス」は「集計と報告のプロセス」となります。
要素の評価の視点：そして、それぞれのより特化した具体的な要素において、どのような課題や問題が発生しそうかを評価するような視点が得られます。この視点を含める理由は、議論としては少し暗黙的ですが、我々は暗黙的により良いプロセスを目指している、という前提があるためです。たとえば「レポートをもとにした意思決定プロセス」での「リアルタイムでの集計容易性」が低い問題を、「ダッシュボードをもとにした意思決定プロセス」で置き換えることで、より良いプロセスを目指している、と言えそうです。
要素の変化の視点：次に、現段階での枠組みでは、十分に強調して表現されていませんが、「世界は変化する」という視点を持てるかもしれません。もう少し具体的に言えば、特定の目的を達成するための業務プロセスは、必ずしも永続的でない、と言えそうです。「良いプロセスを目指す」中で、特定のプロセスが現状のプロセスを置き換えるようなことが起こります。また、プロセスが置き換える準備ができているかどうかは、外部環境の状況によります。十分に使えるようなダッシュボードが存在しなければ、プロセスの置き換えはできません。
要素の変化のパターンの視点：同じく、現段階での枠組みでは、十分に強調して表現されていませんが、要素の変化には繰り返し発生するようなパターンがあるという視点を持てそうです。たとえば、「レポートをもとにした意思決定プロセス」は「ダッシュボードをもとにした意思決定プロセス」で置き換える、というのは、多くの企業で発生しようなパターンです。このようなパターンが発生するのは、特定の抽象度での問題が繰り返し発生するためだと考えられます。問題が繰り返し発生するならば、その問題を解決するための方法も繰り返し発生すると考えられます。
まとめると。
・汎用的な要素の視点を持つことで、考えられなければならない範囲が決まります。そして、その範囲内で要素の評価を行えます。要素の評価の結果、要素の変化が起こります。要素の変化には、パターンがあります。
そして、
・いくつかのパターンが十分に得られたのであれば、そのパターンの適用できる状況を把握し、状況が適切ならばパターンを適用することでより適切な状況に向かって改善していくという流れが考えられます。
最後に、表現した方がよさそうだけども、まだ表現しきれていない要素もあります。
・KPIや目的、目標といった概念。
・業務プロセスを評価する業務プロセスといった、メタの概念。
・具体的な業務プロセスが何らかのデータを生み出すといった、具体的な要素の例。汎用的な意味合いでは、「業務プロセスはデータは生み出す」という関係性は最初に定義しました。
まとめ
この記事では、業務プロセスとデータの枠組みを定義しました。この枠組を使い、実際のデータ活用の取り組みを表現できるかどうかを試しました。
次回は、今回の渋谷直正氏の記事を続きとして以下の行いたいと思います。
・一部の部署における売上需要予測
続きはこちら。
株式会社分析屋について
【データ分析で日本を豊かに】
分析屋はシステム分野・ライフサイエンス分野・マーケティング分野の知見を生かし、多種多様な分野の企業様のデータ分析のご支援をさせていただいております。 「あなたの問題解決をする」をモットーに、お客様の抱える課題にあわせた解析・分析手法を用いて、問題解決へのお手伝いをいたします！
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。