プロセスマイニング

Introduction to Process Mining (17)Outlook for the Future of Process Mining

今回は、これまでのまとめも踏まえ「プロセスマイニングの将来展望」について解説します。

プロセスマイニングの分析対象の拡大

プロセスマイニングの分析は、2000年代当初からはまずSAPなどのERPシステムが主な対象となりました。したがって具体的には、「購買プロセス（P2P：Procure to Pay)」や、「受注プロセス（O2C: Order to Cash)「」、および経理業務に含まれる「買掛金管理プロセス（Account Payable）」、「売掛金管理プロセス（Account Receivable）」が多く分析されてきました。

近年は分析対象が拡大しつつあります。例えば、販売・マーケティングのプロセス、すなわち集客からの見込客獲得・育成を行うマーケティング活動、および有望見込客に対して行う、受注に至るまでの営業活動を分析する企業が増えつつあります。この背景には、マーケティング活動は、マーケティングオートメーション（MA)と呼ばれる支援ツールが普及し、また営業活動についてはSFA(Sales Force Automation）と呼ばれる支援ツールが普及したことがあります。すなわち、マーケティング、セールスのデジタル化が進んだことによって、プロセスマイニング分析対象となりうるイベントログデータが生成されるようになったわけです。

同様に、販売後のサービス活動、すなわちカスタマーサポートについても、コールセンターのシステムや、主にクラウドで提供されるカスタマサポート支援ツールが普及したことで、カスタマーサポートプロセスもプロセスマイニングの対象となることが増えてきました。

一方、データが多様でイベントログデータの抽出、前処理が難しいのが生産プロセスです。また生産プロセスの場合、デジタルで捕捉されない工程が多く含まれています。このため、生産プロセスを対象とするプロセスマイニングの実績はあまり多くないのが実情です。

しかしながら、生産ラインにIOTを設置することで、センサーにより生産工程の進捗度合いを自動的に記録する工場が増加しつつあることから、今後、生産工程のプロセスマイニング分析も増えていくことでしょう。

以上は、企業活動の中核となる価値創出プロセスにおける今後の展開について語りましたが、次に管理系プロセスおけるプロセスマイニングの展開を考えてみましょう。

前述したように、ERPからのデータ抽出が容易な買掛金管理、売掛金管理のプロセスマイニング分析は多く行われてきました。近年、活用が試みられているのは、人的資源管理（Human Resource Management）や研究開発（Research & Development）のプロセスです。

人的資源管理は、人材の採用、育成、評価、昇進など多岐にわたるプロセスが存在しますが、支援ツールによる管理がそれほど普及していないこともあって、そもそものデータが存在していないという課題があります。とはいえ、人材の採用から入社時の各種対応（オンボーディング）についてはツールが活用されていることも多く、このオンボーディングプロセスが分析されるケースが見られるようになってきました。

研究開発については、多くがプロジェクトベースで進められること、研究には試行錯誤が不可欠であり、直線的な標準手順というものが実質的に存在しないことから、そもそも改善すべき課題設定が簡単ではありません。ただ、プロジェクト管理という視点では、JIRAなどのプロジェクト管理ツールが用いられることが多いため、適切なプロジェクト運営が行われているかという視点でのプロセスマイニングは有効かもしれません。

全般管理とは、企業全体の戦略立案や遂行プロセスであり、これもかっちりとしたプロセスが定義できるような定型業務でないため、プロセスマイニング分析の対象とはなりにくい分野ではあります。

さて、企業内の各種プロセスの改善を目指したプロセスマイニングと並行して、今後大きく活用が増えると思われるのが、顧客の行動、特に購買行動プロセスを対象としたプロセスマイニングです。

すでに活用実績が積み重なりつつあるのが、Webサイト上での顧客の訪問履歴、すなわちページ閲覧行動についてのプロセスマイニングです。Webサイトでの顧客の訪問履歴は「アクセスログ」として詳細に記録されており、抽出してクリーニングを行えばすぐにプロセスマイニング分析が可能です。

また、リアルのショッピングモールやアウトレットでの来場客の回遊行動についてのプロセスマイニング分析も今後登場してくるでしょう。鍵を握るのは、モールやアウトレットの各所に設置されたIOTのセンサーです。IOTのセンサーが来場客の逐次の場所とタイムスタンプを記録したリアルなアクセスログを分析すれば、ファクトに基づく詳細な施設内回遊行動を明らかにできるのです。

このように、顧客の行動プロセスをプロセスマイニングで把握することは、「カスタマージャーニーマイニング」と呼ばれています。今後、最も進展が期待できる分野だと言えます。

テクノロジーとしてのプロセスマイニングの進化　 from Process Mining 1.0 to 2.0

次に、テクノロジーとしてのプロセスマイニングが今後どのように進化していくのかについて簡単にご説明します。プロセスマイニングベンダーは現在、この進化の方向に向かってツールの機能拡張に取り組んでいます。

そもそも、プロセスマイニングとは、業務システムから抽出したイベントログデータに基づいて、現行業務プロセス（as isプロセス）を可視化し、非効率な手順やボトルネックなどを発見する「分析アプローチ」です。その目的は、業務プロセスの継続的改善にあります。多くの場合、大量のデータを扱うことから、ビッグデータ分析のひとつと言えます。またデータマイニングとも近い関係にあります。

さて、日々遂行される業務プロセスの継続的改善を目的としていることから、プロセスマイニングの分析アプローチは「記述的分析」を起点に、「処方的分析」に向けて進化を始めています。なお、これは、一般的なデータマイニングにおける分析アプローチの進化と軌を一にしています。

記述的分析 – Descriptive Analytics

記述的分析とは、ありのままの現状を把握することです。

イベントログから現行プロセスを「プロセスフローチャート」の形で見える化する機能、すなわち「プロセス発見（Process Discovery)」で得られるものであり、プロセスマイニング分析の最も基本的な機能です。（したがって、この機能がないものはプロセスマイニングツールとは呼べません）

診断的分析 – Diagnostic Analysis

診断的分析とは、記述的分析で得られた現行プロセスモデルにおける問題点（非効率やボトルネックなど）の要因分析を行うものです。

「なぜ、この箇所は想定より時間が掛かっていて非効率となっているのか」、「なぜ、ここで処理待ちが多く発生しているのか、すなわちボトルネックなのか」というなぜを追求します。「根本原因分析（Root Cause Analysis）」と呼ばれる深堀り分析です。

予測分析 – Predictive Analytics

予測分析では、現在仕掛中の未完了案件（Running Case）をリアルタイムに分析し、今後どうなりそうかを予測します。

記述的分析、診断的分析では、完了済、すなわち過去のイベントログデータを分析しますが、さらに、予測モデルを開発することで、未完了案件の未来の振る舞いを確率的に予測します。すなわち、次に起こりえる活動（Activity)はなんになる可能性が高いか、また、終了までの所要時間はあと何時間になりそうか、といったことを予測し、担当者に伝えます。

ある案件の今後の流れが好ましくない方向に行きそうである、またKPIの目標値よりも所要時間が長くなりすぎて約束納期を過ぎてしまう、といったことを事前に知ることができれば、適切な予防策を講じることが可能となります。

処方分析 – Prescriptive Analytics

処方分析は、単に今後のプロセスの振る舞いを予測するだけでなく、プロセス改善のために、どのような打ち手が望ましいかをアドバイスするものです。

医師が患者を診療して、熱やセキなどの症状を記述し、インフルエンザと診断、今後高熱がさらに続くと予測して、解熱剤を処方するように、業務プロセスの将来の悪化を予測したときに、どのような改善策を講じるかを提案する。これが処方分析です。

以上、説明してきた進化の4段階のうち、記述的分析と診断的分析は、多くのプロセスマイニングツールの機能として既に実装されています。また、ユーザーもこの２つの分析を活用していることから、「プロセスマイニング1.0」と言えるでしょう。機能としては、プロセス自動発見機能と関連する分析機能によって、根本原因分析を行います。

そして、予測的分析機能や、処方的分析機能を持つものは、「プロセスマイニング2.0」と呼ぶ先進的なプロセスマイニングツールです。一部のリーディングベンダーがこれらの機能へと拡張を始めているところです。

Introduction to Process Mining (15)How to manage a process mining project

今回は、「プロセスマイニングプロジェクトの進め方」について詳しく解説します。

プロセスマイニングライフサイクル

「プロセスマイニング」を自組織に導入し、継続的に運用する場合には、基本的には下図のような流れで進めていきます。

スコーピング

プロセスマイニングの起点は左上の「スコーピング」です。スコーピングは、「分析計画作成」と言い換えたほうが理解しやすいでしょう。プロセスマイニングは、ビッグデータを扱うデータマイニングの一種であり、分析手法です。したがって、まずは分析計画を策定する必要があるのです。

スコーピングでは、分析対象となるプロセス（たとえば「購買プロセス」、あるいは「受注プロセス」など）を選定します。当該プロセスの選定にあたっては、なんらか改善すべき課題・問題があるかと思います。そこで、当該プロセスを選定した背景や、想定される課題・問題を併せて明確化します。

さらに、初めて対象プロセスを分析する場合は、「プロジェクト」として、目的・目標設定、およびスケジュールや予算、プロジェクトメンバーをアサインするなど、プロジェクト管理を行えるように計画を固める必要があります。

データの理解

プロセスマイニングは、業務システム内に記録されている大量のデータから、対象プロセスの分析を行うために必要なデータ項目を特定し、多くの場合SQLで各種DBなどから抽出します。

抽出されたデータもまた巨大であり、複数のファイルに分かれ、多数のデータ項目が含まれています。業務システムが自社開発の独自のものであった場合、データ形式、表記方法、マスターデータがファイルによって微妙に違うこともあります。

基本的に、業務システムから抽出された生データをそのままプロセスマイニングツールにアップロードできることはありません。プロセスマイニングツールで分析可能なイベントログを作るために、なんらかの前処理を行う必要があります。

そこで、適切にデータ前処理を行い、正しいイベントログを作成するために行わなければならないのが、データの理解を深めることです。抽出されたデータの項目一つひとつを確認し、NULL値の扱いはどうなっているのか、マスターファイルはどのようなものか、などなど検証すべき点は多岐にわたります。

また、データそのものを検証するだけではなく、そのデータが生み出された業務システム自体はどのような特徴を持つのか、当該システムに対する理解を深めることも有益でしょう。

イベントログ作成

プロセスマイニングの対象となるデータは総称して「イベントログ」と呼ばれます。前項で指摘したように、業務システムから抽出した’生’のデータは、しばしば多数のノイズが含まれてますし、ファイルによってタイムスタンプの表示形式が違うなど、そのままではプロセスマイニングツールにアップロードできません。

そこで、基本的にはデータの前処理によって、クリーンなイベントログを作成することが必要になります。データマイニングにおいても、このデータ前処理が全作業の8割を占めると言われますが、プロセスマイニングにおいてもやはり、データ前処理によるイベントログ作成に全行程の大半を割かねばならないケースが多いでしょう。

プロセスマイニング（分析）

クリーンなイベントログが作成できたら、プロセスマイニングツールにアップロードし、分析準備完了です。プロセスマイニングツールを操作して以下のような視点で分析を行っていきます。

　・頻度分析：処理案件数が多くなっている箇所はどこか。業務負荷量に偏りがあるか

　・所要時間分析：各活動の処理時間（サービスタイム）や、待ち時間（ウェイティングタイム）が長くなっている箇所はどこか。ボトルネックが存在するか。

　・バリアント分析：発見されたプロセスのバリエーションは何種類くらいあるか。理想的な手順を踏み、リードタイムの短い「ハッピープロセス」は含まれているか

　・適合性検査：理想プロセス（to beプロセス）と比較して、発見された現行プロセス（as isプロセス）には逸脱が認められるか

分析の視点はほかにも多数ありますが、最終的には、非効率なプロセスやボトルネックがなぜ(Why）発生しているか、という「根本原因分析」へとデータを深堀りしていくことになります。

評価（解釈）

プロセスマイニング分析で把握できるのは、プロセスのどこに非効率性やボトルネックがあるかというデータに基づく「事実（ファクト）」のみです。なぜ、非効率やボトルネックがある箇所で発生しているのかという原因は分析結果をいくら眺めてもわかりません。

プロセスマイニングツールでは、データを深堀りする、具体的には、「文脈的データ」とも呼ばれる属性情報（顧客名、サプライヤ名、製品名、材料名、価格など）の切り口で分析することで、どの顧客についてボトルネックが発生しやすいか、という問題の所在を突き止めることはできます。しかし、依然として「原因」がわかるわけではありません。

評価（解釈）の段階では、特定された様々な問題について、現場担当者へのヒアリングや観察調査などを追加的に行い、根本原因を明らかにするとともに、当該問題を解決する緊急性や重要度も併せて検討し、具体的な改善施策の立案へと結び付けていきます。

なお、分析結果の評価（解釈）には、リーンやシックスシグマなどの業務改革・改善手法の知識、ノウハウが必要となります。

運用

プロセスマイニングの目的は、分析結果の評価（解釈）に基づいて、適切な改善施策を講じ、改善されたプロセスでの業務運用を行うことです。ただ、外部環境の変化に応じて最適なプロセスもどんどん変化していきますし、放置しておくと運用手順が現場の事情で改変されがちです。

そこで、改善前、改善後のビフォア/アフターの効果検証に加えて、改善後のプロセスにおいて今走っている個々の案件をリアルタイムに監視し、問題発生のアラートを関係者に流すことで即時是正を図ることが望ましいでしょう。

プロセス枚にイングツールには、完了している過去のイベントログだけでなく、未完了の、今走っている案件データをリアルタイムで分析しアラートを出す仕組みが備わっているものもあります。

継続的なプロセス改善を目指すのであれば、プロジェクトとして、分析改善したらひとまず取り組み終了ではなく、プロセスマイニング実行体制を確立し、継続的な運用・監視を行うべきです。

プロセスマイニング実行体制

プロセスマイニングを実行するために必要なチームメンバーは以下の通りです。

プロセスオーナー

プロセスオーナーは、プロセスマイニングの分析対象となるプロセスに関して、直接の権限や責任を持つ方です。プロセスマイニングの結果、ボトルネックなどの問題が発見され、それに対する解決策が提示された場合は、それを承認（非承認）する立場になります。

分析対象プロセスが複数の部門にまたがる場合は、プロセスオーナーはそれぞれの部署のトップがプロセスオーナー になるよりは、より上位の事業部長クラス、あるいは役員クラスがプロセスオーナーになってもらうのがいいでしょう。

プロジェクトマネージャー

プロジェクトマネージャーは、文字通りプロジェクトの進捗管理を行う役割を担います。大企業になると、複数のプロセスを対象とするプロセスマイニングが並行して走ることが一般的であり、データサイエンティストなどの専門家のリソースが限られることから、並行するプロジェクトとのリソース配分も調整しつつ円滑にプロジェクトを推進していかなければなりません。

ドメインエキスパート(現場担当者)

ドメインエキスパートとは、分析対象プロセスに含まれる各活動を遂行する現場の担当者のことです。従来の業務分析におけるヒアリングでは、彼らドメインエキスパートに協力を仰ぎ、現場でどのような手順で業務を行っているかを確認します。

プロセスマイニングの場合、まずはイベントログデータで業務の流れを可視化します。したがって、ドメインエキスパートの役割は、プロセスマイニングの結果から洗い出された問題点の根本原因を堀りさげるために、イベントログでは拾いきれない詳細な業務内容を伝えることです。

IT管理者

IT管理者は、分析対象となるイベントログデータがITシステムのどこにどのように蓄積されているかを確認し、イベントログデータを抽出する役割があります。どのデータ項目が必要なのかは、データサイエンティストからの「データ抽出依頼書」の内容を参照します。

データサイエンティスト

データサイエンティストは、プロセスマイニング分析のための分析計画を立案するとともに、分析目的に照らして必要なデータ項目は何かを決定して「データ抽出依頼書」に落とし込み、IT管理者にイベントログデータ抽出を依頼します。

また、抽出されたイベントログデータに対して、ノイズとなるデータを除去したり、データを変換するなど、プロセスマイニングツールにアップロードするためのクリーンなイベントログを作成します。この作業を「データ前処理（Data Preparation）」と呼びます。データ前処理を行うイベントログデータは大容量であるため、ETLツールや、Python、SQLなどのスクリプトを活用します。

なお、プロセスマイニングツールは、多くの場合、データサイエンティストが操作しますが、ツール自体の操作はBIツールと同様、それほど技術的な素養は必要しないため、基本的な操作はプロセスマイニングの関係者全員がある程度行えるようになるのが望ましいでしょう。

プロセスアナリスト

プロセスアナリストは、BPM（Business Process Management）の知識を有し、プロセスマイニングの結果をプロセスだけでなく、人・組織、システムなど多面的な視点で評価し、非効率なプロセスやボトルネックを特定、根本原因分析のために、ドメインエキスパートへのヒアリングや、現場の観察調査などを行います。

プロセスコンサルタント

プロセスコンサルタントは、業務改革・改善のための方法論、リーンマネジメントやシックスシグマなどの知識を有し、プロセスマイニングを通じて炙り出した問題点の解決策を立案し、その実行を提案、管理することが役割です。

なお、果たすべき役割によってチーム編成を説明しています。データサイエンティスト、プロセスアナリスト、プロセスコンサルタントの３人については、求められる知識やノウハウ、経験がある程度重なり合います。現実には、一人のコンサルタントがこれらの役割を複数同時に担うケースがあります。

Introduction to Process Mining (14)Cases

今回は、プロセスマイニング活用事例について解説します。

プロセスマイニング活用状況

プロセスマイニング市場はまだまだ新しいため、市場全体を把握できるデータや資料がほとんど存在しません。そんな中、イタリアのITコンサルティング会社、「HSPI Management Consulting」が2018年から毎年発行している「Process Mining: A DATABASE OF APPLICATION」は、プロジェクト件数ベースでのプロセスマイニング活用状況を伝えてくれる貴重な調査資料です。

具体事例を紹介する前に、上記調査資料の最新版、2020 Edition（2020年1月20日公開）の一部をご紹介します。なお、以下に示すデータは、世界各国のプロセスマイニングツールベンダーや、プロセスマイニング導入を支援するコンサルティング会社等に協力を仰ぎ、任意に提出された過去のプロジェクトの件数や概要に基づくものです。調査に協力していないベンダー、コンサルティング会社等のプロジェクトはカウントされていない点にご留意ください。

年別プロジェクト件数推移

まずは、年別のプロセスマイニングのプロジェクト件数の推移を見ましょう。以下のグラフからわかるように、2011年からの伸びがめざましく、2019年は100件に届こうとする勢いです。昨年2019年は75件と減少していますが、HSPIによれば今回の調査時期が2019年秋だったため、未完了プロジェクト分がレポートされたためだろうと述べています。2021年版で明らかになりますが、実際には、2019年の年間プロジェクト件数は100件を大きく超えていると思われます。

産業別プロジェクト件数

次に、2005-2019年の総プロジェクト件数551件の産業別の内訳を見てみましょう。最も多いのは、航空、自動車、建設、物流などの業界で21％。航空業界だと、エアバス、ルフトハンザ航空、また自動車業界では、BMW、PSI、フェラーリ、ポルシェなどがプロセスマイニングに取り組んでいることが知られています。

次いで、「銀行・保険」で17％。様々な手続きに係る社内業務が煩雑であることから、コスト削減余地が大きい業界だからでしょうか。

3位につけているのは「医療・医薬」で16％です。プロセスマイニングは、初期の頃、病院での医療行為（医療検査など）への適用事例が多く報告されていますが、近年は製薬会社での導入も進んでいます。

地域・国別プロジェクト件数

地域・国別のプロジェクトの構成比については簡潔に触れるに留めます。プロセスマイニング発祥の地、欧州が最も多く37.9%を占めています。次いで、米国5.0%、ブラジル4.0%､オーストラリア38%と続いています。

プロジェクト対象プロセス・目的

この調査資料は、DATABASE OF APPLICATIONとあるように、各プロジェクトについて、企業名（匿名の場合もある）、業種、プロジェクト概要が収録されています。簡潔なプロジェクト説明ですので詳細はもちろん推測するしかないのですが、価値ある事例集だと言えます。

2019年の最新事例をざっと眺めてみると、従来から多かった購買プロセス（P2P: Procure to Pay）、受注プロセス（O2C: Order to Cash）や、ヘルプデスクのITSMプロセス以外の多様なプロセスへと適用が広がっているのがわかります。また、RPAによる自動化を目的に、タスクレベル分析、すなわちタスクマイニングの事例もいくつか登場していることが特筆できるでしょ

ここからは、具体的な活用事例をご紹介していきます。

FREO – 日々の業務改善にプロセスマイニングを活用

FREOはオランダで消費者向けローンを提供しています。ユーザーの主なローン使途は、自動車購入、住宅リフォーム、既存ローンの借り換えなどです。ローンの申し込みはWeb、または電話で受け付け。ローンの申込件数は年間10万件以上、かかってくる電話は同2万件以上に上ります。

同社では、日々の業務管理（Operational Management）のため、BIツールのPower BIなどとともにプロセスマイニングツールを活用して、プロセス上の問題点を発見、継続的な改善を行っています。

さて、FREOの日々の業務、すなわちローン申し込みの受け付けから契約までは以下の段階で構成されています。このプロセスに従事するFREOのスタッフは60人以上です。

１　ローンの申し込み（Loan Application) – ユーザー

　ユーザー（消費者）から、Webまたは電話でローンの申し込みを受け付けます。

２　ローンの提案（Loan Offer) – 顧客接点チーム

　顧客接点チームが、申し込み内容に対して適切なローン商品を提案します。

３　書類確認（Loan Validation) – 顧客確認チーム

　顧客確認チームが、ローン申し込み者について必要な書類が揃っているかを確認します。

４　ローン審査（Credit Approval）- ローン審査チーム

　ローン審査チームが申込者の書類を審査し、ローンを提供するかどうかを決定します。

５　ローン契約（Contract)

審査がOKだった場合、ユーザーとローン契約を締結し、融資金額を銀行口座に振り込みます。

FREOでは、上記の日常業務に関してKPI（Key Performance Indicator)を設定しています。KPIは、大きくは以下の５つのカテゴリーです。

１　品質（Quality)

　工程が一回で問題なく終了するか（First Time Right)

２　迅速性（Timeliness）

　製品・サービスの提供スピードは速いか

３　受け入れ能力と生産性（Capacity and Productivity）

　効率的にメンバーの対応キャパが使われているか

４　費用と利益（Cost and Benefits)

　運用コスト、利益に与える影響度合い

５　顧客・従業員満足（Satisfaction）

　製品・サービスの提供プロセスに対する顧客、および構成メンバーの満足度

FREOでは、KPIの最初の３つ、すなわち「品質」、「迅速性」、「対応能力と生産性」が高まれば、結果的に「費用と利益」、および「顧客・従業員満足」は高まる関係にあると考え、最初の３つの改善に取り組んでいます。

そして、具体的なKPIの指標としては、マネジメントレベル、チームレベル、および日常業務レベルでそれぞれ以下のようなものがあります。

●マネジメントレベル

　・ローン申し込みから契約までの平均スループット（総所要時間）

●チームレベル

　・申し込みから初回コンタクトまでの平均所要時間（顧客接点チーム）

　・書類受領から書類確認終了までの平均所要時間（顧客確認チーム）

　・確認後書類受領からローン審査終了までの平均所要時間（ローン審査チーム）

●日常業務レベル

　・申込件数（全チーム）

　・24時間で連絡した申込件数（顧客接点チーム）

　・24時間で書類確認した申込件数（顧客確認チーム）

　・24時間で審査した申込件数（ローン審査チーム）

同社ではこれらKIPをBIのダッシュボードで日々モニタリングすると同時に、問題点を発見するための深堀り分析にプロセスマイニングを活用しています。

プロセスマイニングでは、日々のKPIをモニタリングしているだけではわからない、実際の業務の流れが可視化できます。FREOのローン申し込みから契約までの業務プロセスにも様々な問題が発見できました。

たとえば、ユーザーが申し込んだ後、顧客接点チームが連絡してもユーザーから返信がない、あるいは商品を提案した後、書類が揃わない、などの理由で、それぞれ適切なフォロー施策を展開するため、様々な業務手順の分岐が発生しています。また、ローン受け付け、書類確認、ローン審査のそれぞれの段階に移る箇所で処理待ち、すなわちボトルネックが発生していることが定量的に把握できます。同社では、手順の組み換えやリソース（担当者）のアサインを柔軟に見直すなどして、問題の解消に当たっています。

同社では、プロセスマイニングを単なる問題発見ツールとしてだけでなく、実際の業務プロセスが可視化できることで、関係するメンバーが「すごい（Sense of Excitement)」と思ってもらうこと、また、非効率性やボトルネックが一目瞭然となることから「すぐに改善しなければ（Sense of Urgency）」という気持ちを喚起できる仕掛け、すなわちプロセス改善を着手させ（Initiator)、促進する(Katalysator)ことのできる有益なアプローチとして活用しています。

AIG (USA) – Process Wind Tunnel（プロセス風洞）で確実な改善効果を

グローバルに展開する保険会社、AIGでは様々な業務プロセス改善に取り組んでいます。特に、米国AIGの”Data-Driven Process Optimization”と呼ばれる部署では、プロセスマイニング、シミュレーション、BIを組み合わせることで改善成果を積み重ねています。

Data-Driven Process Optimization部署では、プロセス改善の一連の手順を「プロセス風洞（Process Wind Tunnel）」と呼んでいます。自動車や航空機、建築物などの設計においては、風洞に模型を置いて風の流れ等を測定する「風洞実験」を行います。同様に、プロセスの改善にあたって、シミュレーションによる改善成果の予測を行った上で改善施策に展開するという手順を踏んでいるのです。

プロセス風洞は以下の４つの段階で構成されます。

１　データ収集（Data Collection)

ITシステムからのイベントログ抽出に加えて、ビジネスルール、およびリソース（担当者などの属性データを統合します。

2　現状分析（Current State Analysis)

BIツール、プロセスマイニングツールを用いて現状プロセスを可視化し、様々な視点で分析を深めます。

3　未来状態設計（Future Sate Design）

現状を再現するシミュレーションモデルを作成し、さらに、リソース配分の変更などプロセスを最適化するようにモデルのパラメターを変更し、改善成果を試算します。

４　実行

前項のシミュレーションを踏まえ、パイロットプロジェクトを走らせたり、システム改修、新ツールの導入などの改善施策を実行し、改善状況をモニタリングします。

今回紹介された取り組み例はサービス業務です。これは、お客様から届く、月間6万件に上る様々な書類を処理する業務です。書類は、USPSの通常便であったり、翌日配達便であったり、FAX、あるいはeメールと様々な形態があります。

紙の場合には開封して中身をチェックし、スキャンするといった手作業があります。こうした手作業については動作調査(motion study）を行って平均処理時間など、シミュレーションに必要なパラメターとなる情報を収集しています。

データ化された後の処理は、BIツールで曜日別の書類到着数などの統計的分析、およびプロセスマイニング分析を行って現行プロセスモデルを可視化し、プロセス上の問題点を抽出するとともに、データ分析結果から得られた数値はシミュレーションのパラメターとして用いています。

サービス業務の場合、シミュレーションの結果、50％ものスループット（総所要時間）の改善が見込めることがわかり、実際に改善施策を講じたところ、シミュレーションの予測に等しい結果が得られたとのことでした。

Lufthansa Technik – 部品補修プロセスの改善に活用

Lufthansa Technikは、航空機の整備、補修、オーバホールのサービスを提供しています。同社にとって最も重要な課題は、クライアント（航空会社）から預かった航空機の整備や補修を可能な限り速やかに行うことです。というのも、整備、補修に係る時間がみじかいほど、航空機の運航時間が増え、クライアントの収益向上につながるからです。したがって、Lufthansa Technikにおけるプロセス改善においては、「スピードアップ」が基本戦略です。

さて、プロセスマイニングに取り組む同社が今回、事例として取り上げたのは部品補修（Parts Repair)のプロセスです。プロセスマイニング分析によって発見された業務遂行上の問題点の改善には、リーンマネジメントの考え方がベースにありますが、さらにボトルネックに関しては制約理論（Theory of Constraints）を適用した点が特徴的です。

部品補修プロセスはほとんどがERP上で遂行されていることから、クオリティ、信頼性の高い分析対象データを抽出することが可能でした。一部、システム外で行われている業務については、担当者が開始時間、終了時間を手入力で記録することでイベントログデータが作成されています。

プロセスマイニング分析結果から、部品補修プロセスの総所要時間（ターンアラウンドタイム、またはスループットと呼ぶ）を長くしている大きなボトルネックは3カ所ありました。すなわち、「検査（Inspection)」、「提案と承認（Proposal and approval）」、「修繕と認証（Repair and certification)」です。

各工程では、大きなユニットの60－80％が処理待ちとなっており、このため6日～12日ほど想定よりも時間が掛かっていました。どれも解決すべきボトルネックではありましたが、どの工程から着手するか、優先順位をつけるために同社では「制約理論（Theory of Constraints）」を適用しました。制約理論は、プロセス改善を目的としてボトルネックの解消に取り組むためのアプローチです。そして、制約理論に基づき、「提案と承認（Proposal and approval）」からボトルネック解消のための施策を開始したのです。

また、プロセスマイニング分析後の改善の取り組みにおいては、「スピードアップ」の基本戦略を踏まえて、ワークショップを開催、「価値提供プロセスマップ（Value Stream Map）」を作成してプロセス課題を抽出、Wiki、Jira、Backlogなどのツールを用いてプロセス改善プロジェクトを推進しました。

プロセスマイニング分析後の改善の取り組みにおいて、スピードアップの戦略方針を踏まえて、ワークショップを開催、プロセスの流れを見直しつつ課題を抽出、Wiki、Jira、Backlogなどのツールを用いてプロセス改善プロジェクトを推進しました。

Introduction to Process Mining (13)Operational Support

今回は、「運用サポート」について詳しく解説します。

運用サポート　- Operational Support

プロセスマイニングは、プロセス発見、すなわち過去の、完了済みプロセスのイベントログからas-isプロセスを把握することが出発点です。さらに、適合性検査やプロセス強化によって、新たな業務プロセスを定義し、新業務プロセスべーすでの運用を始めたら、その後は、着実に、逸脱なく、新業務プロセスが実行されているかを継続的にモニタリングすべきでしょう。

運用サポートでは、現在走っている「未完了のプロセス」のデータをプロセスマイニングツールにリアルタイムで流し込み、完了までの推定リードタイムを予測したり、逸脱した手順や過度の業務集中、ボトルネックの発生を捕捉し、関係者に通知、即時の是正を図るものです。

下図は、購買プロセスにおいて、未完了の案件、すなわち現在仕掛中のプロセスについて、リアルタイム（現実には1日1回のバッチによるデータ自動流し込みが多い）でイベントログデータをプロセスマイニングツールに流し込みます。

そして、この例では、購買申請から発注決定へと直接の流れが発生していることについて、購買承認、見積もり依頼という正当な手順を端折った案件と認定され、担当者に対し「コンプライアンス違反となる逸脱が発生してますよ」というメッセージをメールやメッセンジャーで送信します。もちろん、このようなアラートメッセージを送信するためには、事前に各種ルールを設定しておく必要があることは言うまでもありません。

また、プロセスマイニングツールによっては、予測分析機能も実装されており、現在仕掛中の案件について、スループットがKPI目標値に収まるかどうかを推測し、目標値より長くなりそうなプロセスを発見することができます。

スループットが目標より長くなるということ、すなわち受注プロセスであれば、納期が予定よりも遅れる可能性があるということであり、放置すれば顧客からのクレームが発生したり、処理コストの上昇を招いたりするため、直ちに何らかの措置を取り、スループット短縮を目指す必要があるわけです。

この予測分析を実行するためには、過去のイベントログデータに基づく「所要時間予測モデル」を開発し、プロセスマイニングツールに組み込まなければなりません。そこで、AI（人工知能）の機能も併せてツールに実装されています。

プロセスマイニング分析は、BPRや業務改革プロジェクトにおいてひと回ししたら終わりではありません。新業務プロセスへと改訂後の効果検証とモニタリングを通じて、継続的なプロセス改善（Continuous Process Improvement）につなげてこそ、その最大の価値を手にすることができます。

Introduction to Process Mining (12)Process Enhancement

今回は、「プロセス強化」について詳しく解説します。

プロセス強化　- Process Enhancement

プロセス強化は、プロセス発見や適合性検査などで特定できた様々な問題（非効率、ボトルネック、逸脱など）に対して、根本原因分析を行って原因をつきとめ、改善施策を展開、より望ましいプロセスへと変革していく取り組みのことです。

プロセスマイニングの効用（下図）から、プロセス強化に関係する改善施策（右端）を見てみましょう。

まず、イベントログから可視化された現状プロセスの複数のバリエーションから、理想プロセスが発見できたら、これの標準化を図り、BPMシステムに実装・展開することで、標準プロセスが確実に実行できるようにします。併せて、マニュアルの開発も有益でしょう。なお、ここで「理想プロセス」とは、効率が高く、ボトルネック発生が少ない、また逸脱のないto「to beプロセス」であり、多くの場合、スループット最短、処理コスト最少となります。

また、プロセスの一部の工程がムダであるなら、ばっさりとその工程をカットしたり、適切な順番に手順を入れ替えたり、直列処理から並行処理に切り替えるなどの「プロセス変革」を行うことが有効である場合も多いでしょう。

こうしたプロセスの改善においては、モデリングツールに現状プロセスを投入して、BPMN形式のフローチャート上でプロセス改善のための再設計を行う必要があります。モデリングツールは、プロセスマイニングツールによっては既に組み込まれているものがあります。モデリング機能がないプロセスマイニングツールの場合は、現状プロセスをBPMN形式でダウンロードし、別途モデリングツールにアップロードして編集を行うことになります。

単純な繰り返し作業や定型手順となっているプロセスについては、RPAによる自動化の有力な候補です。RPA化に当たっては、タスクレベルの詳細な手順を把握する必要があります。このためには、現場担当者へのヒアリングを行うことになりますが、タスクマイニングによってPC操作ログを収集し分析すればファクトベースでのタスクフローの可視化が可能になるだけでなく、そのままRPAのプログラムに展開できる場合もあります。

なお、プロセス変革、RPA化に当たっては、プロセス改善による具体的な成果（リードタイム短縮、コスト削減、ミス低減など）がどの程度期待できるかを事前に検証したいものです。プロセスマイニングツールの中にはシミュレーション機能実装されているものもあり、そうしたツールを活用すれば、プロセス強化の成果を定量的に検証できます。

もちろん、モデリングツールにもシミュレーション機能が備わっていますので、モデリングツール上でのシミュレーションで効果検証を行うことも可能です。

Introduction to Process Mining (11)Conformance Checking

今回は、「適合性検査」のアプローチについて詳しく解説します。

適合性検査　- Conformance Checking

適合性検査は、ひとことで言えば標準プロセスからの逸脱があるかどうかを確認する分析手法です。

ここで、「標準プロセス」とは、あらかじめマニュアルなどに示されている規範となる「正しい手順」、あるいは例外処理がなく、円滑に業務が遂行された場合の一般的な手順のことです。

標準的なプロセスは基本的に無理・無駄がなく、スループットも最短、コストも最小であることから、すべての案件が標準的なプロセスに沿って行われるのが理想です。しかし、現実には、マニュアル通りに業務が行われるとも限りません。また例外処理もやむを得ず発生することでしょう。

そこで、プロセスマイニングでは、標準となるプロセス（to beプロセス）と、イベントログから再現した現状プロセス（as isプロセス）の比較分析を行い、標準プロセスを正とした場合に、現状プロセスがどの程度適合しているかを詳細に検証します。だから「適合性検査」なのです。

以下のイメージ図では、左側にto beプロセス、右側にas isプロセスのフローチャートが表示されています。これは、購買プロセス（PtoP）における適合性検査となります。

さて、to beプロセスは購買申請から納品までなんの問題もなく円滑に業務が行われた場合の手順です。これを基準にas isプロセスを見ると２つの逸脱が存在していることがわかります。

ひとつは、購買承認のアクティビティから、その前の購買申請のアクティビティへと戻る流れが発生しています。購買申請内容になんらか不備があり、購買申請者に戻された（再申請要求）ものと考えられます。

もうひとつの逸脱は、見積もり依頼のアクティビティで繰り返しが発生していることです。サプライヤ（商社）に対してなんどか繰り返し見積依頼が行われたことがうかがわれます。

上記２つの逸脱はもちろん、現実には起こりうる想定内の逸脱ではあります。大事なのは、逸脱をゼロにすることは不可能としても、逸脱をできるだけ減らすことにより、明確に工数が削減でき、スループット短縮、処理コストの低減が目指せることです。

たとえば、購買申請内容に不備があることで購買部からの戻しがあり、購買の再申請を行うケースが多い場合、申請前に内容不備を減らすような工程を増やしたり、システム上のチェック機能を追加するなどの改善施策が考えられます。こうした改善施策によって再申請回数を減らすことが重要なのです。

逸脱の２つのパターン

標準プロセスに対する現状プロセスの逸脱（適合していないこと）には、大きくは2パターンあります。

１　標準プロセスには含まれていない手順・アクテイビティが発生している

やってはいけないこと、やらないほうが望ましいことを実施している、という逸脱です。前項の解説でしめした「戻り」や「繰り返し」は、やらないほうが望ましいけれど実施しているケースがあるというもの。

また、購買プロセスではしばしば、購買承認を得る前に発注が行われるケースがあります。急を要するので購買承認が下りる前に発注せざるを得ない、ということは現実には起こります。この「購買承認前発注」は、英語では「マーベリックバイング」と呼ばれる逸脱です。コンプライアンス上、厳密に言えば「行ってはならないプロセス」でしょうし、行うことがやむを得ないのであればできるだけ減らすべきプロセスでもあります。

２　標準プロセスに含まれている手順・アクティビティを実施していない

やるべきことをやっていない、端折っている、という逸脱です。

これは、製品の検査プロセスにおいては大問題となりかねない逸脱だと言えるでしょう。本来実施すべき検査工程が、なんらかの理由で端折られてしまうといいう状況は様々な現場でしばしば観察されることです。しかし、その結果として、製品が世の中に出たとき、損害賠償につながるような大事故を起こしたり、リコールによる製品回収となった場合の損害は多大なものとなります。

したがって、検査工程がある程度ITシステムで管理されており、イベントログを通じて検査プロセスの見える化が可能であれば、ぜひこのやるべきことをやっていない逸脱の検査を行うべきでしょう。

to beプロセスの設定

適合性検査を行いたいが、そもそもto beプロセス、すなわち標準プロセスを規定していない、マニュアルなども存在しないというケースがあります。むしろ、事前に標準プロセスが確立されているケースよりも、標準プロセスは明文化されていないケースのほうが多いと言えます。

プロセスマイニングツールを用いて適合性検査を行う場合、as isプロセスの元となるイベントログのアップロードとは別に、to beプロセスのデータをアップロードする必要があります。ここでto beプロセスを作成する方法には２つあります。

１　to beプロセスをモデリングツールで作成

対象プロセスを実行しているITシステムのドキュメントやマニュアルに標準的な手順が示されていた場合、これをベースにモデリングツールを用いてBPMN形式でプロセスフローチャートを作成します。この作成したto beプロセスをプロセスマイニングツールにアップロードします。

２　as isプロセスから、to beプロセスを抽出

イベントログから再現したas isプロセスには多くのバリエーションが存在します。プロセス発見の「バリアント分析」によって、どのようなプロセスパターンがあるかを検証、その中で理想的なプロセスがあれば、それをto beプロセスとして抽出、必要に応じて整形を行った後、プロセスマイニングツールに再投入すれば、他のプロセスパターンとの適合性検査が可能となります。

Introduction to Process Mining (10)Process Discovery

今回は、「プロセス発見」のアプローチについて詳しく解説します。

プロセス発見　- Process Discovery

プロセス発見は、プロセスマイニングの土台となる手法です。プロセス発見をベースに適合性検査、プロセス強化、運用サポートが行われます。

プロセス発見とは端的に言えば、イベントログに基づいて「プロセスモデル」、すなわち対象プロセスのアクティビティの流れを表した「フローチャート」を自動的に作成することです。事前に、どのような手順で行われているか、といった情報を与える必要はありません。イベントログの情報（必須情報はケースID、アクティビティ、タイムスタンプ）だけを用いて、固有のアルゴリズムによってフローチャートを自動的に再現します。

従来、プロセスの流れはモデリングツールを用いて、手作業でフローチャートを作成していました。元となるのは、システム関連のドキュメント類、現場担当者へのヒアリングやワークショップによって得られた情報です。

一方、プロセスマイニングでは、ITシステムから業務に関わる操作履歴をイベントログとして抽出し、ツールにアップロードすれば自動的にフローチャートを作成してくれます。このことから、プロセスマイニングは初期のころ、「ABPD（Automated Business Process Discovery）」、すなわち、自動化された業務システム発見」とも呼ばれていたのです。

さて、プロセス発見のアプローチでは、様々な視点での分析が行えますが、基本となるのは「頻度分析（Frequency Analysis）」と「パフォーマンス分析（Performance分析）」です。

頻度分析　- Frequency Analysis

頻度分析では、各アクティビティの処理件数、および複数のアクティビティの間を移動した移行件数に着目します。下図のサンプルフロー図で解説します。

開始アクティビティの処理件数は7542件です。その次のアクティビティXへの移行件数も同じく7542件です。開始アクティビティで処理された案件（ケース）はすべてアクティビティXに移行したことがわかります。

アクティビティXの処理件数は7820件となっています。移行件数7542件よりも多いのは、アクティビティXは同じ案件について繰り返し業務が発生していることが考えられます。なんらかのミスをした場合など、操作をやり直したために繰り返し業務（リワーク）として記録されたということです。

アクティビティXからアクティビティYに移行しているのは7102件と大きく減少しています。これは、アクティビティXの後、手戻りが発生して前工程に戻ったり、全く別のアクティビティへ移行していたり、分析時点ではアクティビティXが最後のアクティビティとして記録されていたりしたためです。（簡略化したサンプルのため他のアクティビティへの移行は示されていません）

頻度分析の場合、処理件数や移行件数が相対的に多くなっているところを中心に分析を深掘りします。件数が多いということは作業負荷が高いということですから、次項のパフォーマンス分析と併せて、生産性の低下やボトルネック発生がないかを確認し、改善すべき問題を特定していきます。

パフォーマンス分析　- Performance Analysis

パフォーマンス分析は「時間」に基づく分析です。下図のサンプルフロー図で解説します。

開始アクティビティから終了アクティビティまでの総所要時間＝スループットは、対象プロセスのパフォーマンス分析において最も重要なKPI（Key Performance Indicator）と言えるでしょう。

プロセス改善の第一の目的は多くの場合、このスループットの短縮にあります。案件処理を開始してから終了までのスループットが短ければ短いほど、生産性は向上し、処理コストも低下するからです。

スループットは、「サイクルタイム」とも呼ばれます。ある定型的な業務、たとえば特定製品の製造工程において次々と新たな製品を生み出すサイクルにおる１件あたり平均処理時間のことです。

一般にまず、全案件の平均スループットを算出します。その上で、平均スループットよりも著しく長くなっている問題プロセス、逆に、平均スループットよりも短いプロセスを把握します。前者に関しては、なぜスループットが長くなってしまっているのかの原因を探ります（例えばミスが多く発生して繰り返しが多い、手戻りが発生しているなど）一方、スループットが平均より短いプロセスは、それが正しい手順で行われているとするなら効率の良いやり方とみなすことも可能です。（こうしたプロセスのバリエーションと併せて分析することは、後述する「バリアント分析」と呼ばれます）

サンプルフロー図に戻りましょう。アクテビティごとの時間は処理時間、また複数のアクティビティの間は待ち時間です。

サンプルフローでは、開始アクティビティの処理時間は5分11秒です。開始アクティビティからアクティビティXをつなぐ線上の時間は54分。これは待ち時間です。開始アクティビティは完了した時間から、アクティビティXの処理が開始される時間までの間の時間だからです。

さて、アクティビティごとの処理時間が、KPIの目標値よりも長い場合、効率性が低いという判断になります。例えばアクティビティYの処理時間は3時間45分17秒です。もし、当アクティビティのKPI目標値が「3時間」とするなら、約45分余計に時間がかかっているわけですから効率が良くない。なんとか処理時間を短縮すべき問題箇所となります。

また、その前のアクティビティXからアクティビティYの間の待ち時間は20時間を超えています。これも、KPI目標値よりも長ければ、業務が滞留している＝ボトルネックの発生ということになり、是正対象ポイントとして原因追求を図る必要があります

バリアント分析　 – Variant Analysis

プロセスマイニングの分析対象とするイベントログデータの件数は一般に数百件から、数百万件になります。ここでの件数は対象プロセスで処理される案件数です。例えば、経理部における請求書の処理プロセスの場合、処理された請求書の件数のことです。これは経理システムで付番した請求書IDの数と一致するでしょう。

さて、開始アクティビティと終了アクティビティが同じ「定型業務プロセス」であったとしても中間処理のプロセスには様々なバリエーションがありえます。請求書処理プロセスであれば、金額などに応じて上長承認が必要なもの、必要でないもので手順が異なります。内容不備の場合の差戻し、再受領というイレギュラーな手順もあるでしょう。

バリアント分析は、こうしたバリエーションが何パターンあり、それぞれのバリエーションで処理された案件数を算出します。もちろん、それぞれのバリエーションについてのプロセスモデル、すなわちフローチャートを作成し、頻度分析やパフォーマンス分析を行うことができます。

下図のバリアント分析のイメージ図では、３つのバリエーションが存在していることを示しています。合計処理案件数433件（260件＋125件＋48件）のうち、バリアントXが最も多く処理されているパターンであることがわかります。バリアントは開始から終了までシンプルな流れであり、余計な分岐や手戻り的なものがありません。こうした処理件数が多いバリアントはしばしば「ハッピープロセス」と呼ばれることがあります。多くの場合、ハッピープロセスは効率的でボトルネックがなく、スループットが最も短いからです。（必ずしもそうでない場合もあります）

一方、バリアントZは、バリアントXと比べて手順が多くなっています。パフォーマンス分析で比較すれば、おそらくバリアントZのスループットはバリアントXよりも長いでしょう。バリアントZが上長の承認が必要であるなど、不可欠な手順を踏んでいるのであれば問題はありません。しかし、担当者の裁量でやらなくてもよいことをやっている、あるいはなんらかのミスによって手順が増えてしまっているとしたら是正すべき問題箇所ということになります。

以上、プロセス発見の基本的な分析視点を解説しました。多くのプロセスマイニングツールでは、リソース（担当者）のデータを付加することにより、担当者間の関係性を可視化する「ソーシャルネットワーク分析」を行うことができます。

また、費用に関わるデータを追加することにより、コスト視点での様々な分析が可能です。

Introduction to Process Mining (8)Four Basic Approaches

今回は、プロセスマイニングをプロセス改善に活用するための４つの基本アプローチについて概要をお伝えします。次回以降で、各アプローチを個別に取り上げて詳しく解説します。

１　プロセス発見　- Process Discovery

プロセス発見は、プロセスマイニングの土台となる手法です。プロセス発見をベースに適合性検査、プロセス強化、運用サポートが行われます。

プロセス発見とは、ITシステムから抽出したイベントログに基づいて、一定のアルゴリズムによって、対象プロセスをプロセスモデル、すなわち業務の流れを表すフローチャートを再現します。このプロセスモデルは、実際のシステム操作履歴を反映したものですので、「現行プロセスモデル（as is プロセスモデル）」と呼ばれます。

再現されたプロセスモデルは、大きくは２つの切り口、すなわち「頻度（処理件数）」、「時間（処理時間）」での分析を行います。

頻度分析を通じて、例えば、対象プロセスのどの箇所で処理件数が多いか＝作業負荷が大きいかを把握することができます。作業負荷が大きい箇所はしばしば処理が追い付かず、ミス多発による繰り返しや業務の滞留＝ボトルネックが生じやすいところです。

また、時間分析では、実際に対象プロセスの個々の工程でどの程度の処理時間を要しているかを把握します。KPI目標値に照らして想定以上の時間が掛かっている場合、それは生産性が低いことになります。また、前の工程から次の工程に移る間の時間は「待ち時間」であり、この待ち時間が想定よりも長い場合、業務が滞留する「ボトルネック」であるということが明確です。

２　適合性検査　- Conformance Checking

適合性検査という呼び方はちょっと固い表現ですが、文字通り、手本となるプロセスと現状のプロセスを比較して、現状がどの程度お手本に適合しているかを分析するアプローチです。

ここで手本となるプロセスは「参照プロセスモデル」や「規範プロセスモデル」とも呼ばれます。要するに、あるべき「理想プロセスモデル（to beプロセスモデル）」です。一方、イベントログに基づくプロセスは「現状プロセスモデル（as isプロセスモデル）」です。

適合性検査は、理想プロセスを「正」として、現状プロセスがどのように乖離、逸脱しているかを明らかにします。具体的には、理想プロセスには含まれていない手順を現状プロセスでは行っている場合（やってはいけない手順実行）や、逆に、理想プロセスに含まれている手順が、現状プロセスでは実行されていない場合（やるべき手順の不実行）などです。

３　プロセス強化　- Process Enhancement

プロセス強化は、前項の「プロセス発見」や、「適合性検査」の分析結果を踏まえて、非効率なプロセス、ボトルネックを特定し、有効な改善施策を検討し、より優れたプロセスを設計・開発するアプローチです。

プロセスマイニングツールでは、不要と思われる手順をカットしたり、業務手順を組み替えたり、ボトルネックを解消するために要因配置を変更したり、またRPAによる自動化を行った場合にどの程度の改善が期待できるかをシミュレーションできる機能が備わっているものがあります。

シミュレーションを行うことにより、プロセス強化のための優れた改善施策はどのようなものになるかを事前に検証したうえで展開できます。

４　運用サポート　- Operational Support

従来、プロセスマイニングの分析対象は、過去の完了したイベントログでした。運用サポートでは、現在仕掛中のプロセス、すなわち未完了の案件に係るイベントログをほぼリアルタイムでプロセスマイニングツールに流し込み分析を行います。

そして、今まさに運用中の処理プロセスにおいて非効率、ボトルネックの箇所や逸脱を発見、あるいは予測し、担当者にメールやチャットなどでアラートを出すことで、問題の芽を早めに摘み取ったり、問題発生を未然に防ぎます。

運用サポートでは、予測分析などの高度な分析が行われるためAI（人工知能）も組み込まれており、現在最も最先端のアプローチと言えるでしょう。

Introduction to Process Mining (8) Process Mining Algorithm Basics

今回は、プロセスマイニングによるプロセスモデル（フローチャート）再現の基本原理であるアルゴリズムについて、わかりやすさを優先し、簡易的に説明します。

詳細な技術的解説は、プロセスマイニングのバイブルである『プロセスマイニング Data Science in Action』（Wil van der Aalst著、インプレス）をお読みください。

プロセス発見 – Process Discovery

プロセスマイニングは当初、「Automated Business Process Discovery」（自動的に業務プロセスを発見する）と説明されていました。ITシステムから抽出したイベントログデータから、対象プロセスの流れ（業務手順）を自動的に再現することが最も基本的な機能だからです。

現在は、単にプロセスを発見するだけでなく、参照プロセス（to beプロセス）との比較分析を行う「適合性検査」や、未完了の案件について予測を行ったり、逸脱発生時にアラートを流すなど、高度な機能が次々と実装されています。

したがって、プロセスマイニング＝プロセス発見とは言えなくなってきたものの、プロセス発見という機能がプロセスマイニングの核となる機能であり、また分析の出発点であることは依然変わりません。

さて、イベントログは下図あるようなフラットなデータです。イベントログからプロセスモデル（フローチャート）を再現するためには、案件ID、アクティビティ、タイムスタンプの3項目があればいいのですが、初めてプロセスマイニングを知った方は、どうやってフローチャートを描くのか不思議に思われるようです。もちろん、裏には、一定の処理ロジック、すなわち「アルゴリズム」が存在します。

このアルゴリズムはプロセスマイニング固有であり、一般的なデータマイニングツールには備わっていません。したがって、プロセスマイニング分析を行い、プロセスを可視化したい場合には、プロセスマイニングツールを利用する必要があります。

プロセスモデル（フローチャート）の再現

では、イベントログからフローチャートをどのように作成するかを簡易的なサンプルデータでご説明しましょう。

下図のデータは、案件ID（1～３）とアクティビティ（A～E）のみ。タイムスタンプは略してありますが、上から下に時間が経過している、つまり上の行にあるアクティビティほど古い時間に行われているということになります。

まず案件１についてアクティビティを拾ってみましょう。色分けしてあるので簡単です。緑色のアクティビティ、すなわちA→B→C→D→Eです。同様に、案件２（オレンジ）、案件３（青）についてそれぞれのアクティビティのフロー図が下図の中央にあります。

言うまでもないことですが、Aを起点として終点のEに至る道筋＝トレースは、案件毎に異なっています。アクティビティの順番が入違ったり、同じアクティビティが繰り返されていたりしていますね。どんなプロセスであれ、その辿る道筋＝トレースは複数のバリエーションがあるのが一般的です。

プロセスマイニングでは、案件ごとの個別の道筋を分析することもありますが、まずはこうした複数のバリエーション全体をうまく説明できる「プロセスモデル」を作成します。（下図右端の濃紺のフローチャート）たとえとしては正確ではありませんが、バリエーションの「最大公約数」を見つけるようなものです。

こうして、イベントログに含まれる複数の業務手順のバリエーションから、全体に当てはまりのよいプロセスモデルを作成するのがプロセスマイニングのアルゴリズムです。なお、プロセスマイニングツールに触れたことのある方はお分かりかと思いますが、このプロセスモデルの抽象度は自由に変更することが可能です。すなわち、全体の流れをざっくり把握できる抽象度の高いモデルから、すべてのバリエーションを再現した、最も抽象度の低い詳細なモデルまで、ツールの機能として「粒度」を変更できる可変スライダーが実装されています。

プロセスモデル作成の流れ（イメージ）

さらに、もう少し詳しくアルゴリズムの原理を説明しましょう。

前項同様、わかりやすいように、タイムスタンプを省いて以下のような4つの案件が含まれたイベントログからのフローチャート作成を考えてみましょう。ここで、アルファベットは各アクテイビティであり、（A,B,C）のログは、Ａ→Ｂ→Ｃという時間的順番で行われたことを意味します。

わかりやすいように、タイムスタンプを省いて、以下のような4つの案件が含まれたイベントログからのフローチャート作成を考えてみましょう。

CASE_1　(A,B,C)
CASE_2　(A,B,D)
CASE_3　(A,E,C)
CASE_4　(A,B,C,B,C)

ここで、アルファベットは各アクテイビティであり、（A,B,C）のログは、Ａ→Ｂ→Ｃという時間的順番で行われたことを意味します。

まず、CASE_1のログからフローチャートを描きます。

シンプルですね。

次に、CASE_1に加えてCASE_２も考慮します。

Ａ→Ｂ→Ｃだけでなく、Ａ→Ｂ→Ｄというパタンも存在したことがわかったので、ＢからＣとＤに分岐するフローチャートが描かれました。

さらに、CASE_1、CASE_2、CASE_3の３つの案件を考慮したフローチャートです。

Aに続くのはＢだけでなく、Ｅが続く手順もあるのでこのようなフローになります。

最後に、CASE_1からCASE_4までのすべてを考慮したプロセスモデルは以下の通りです。

Ｂ→Ｃだけでなく、Ｃ→Ｂと戻る手順も存在していることがわかります。手戻り発生です。

以上の例では４案件だけでしたが、実際の業務プロセス分析では数万件、数十万件の案件のイベントログに基づいて、上記のようなフローチャートを再構成していくわけです。

アルゴリズムの種類

イベントログからプロセスモデル（フローチャート）を再現するアルゴリズムも日々進化しています。

プロセスマイニングは1999年、オランダでの学術研究からスタートしていますが、当初は「アルファアルゴリズム（アルファマイナー）」が用いられました。ただ、アルファアルゴリズムには、現実のプロセスを十分に再現できないというロジック上の制約があるため、研究が進むにつれ、以下のような様々なアルゴリズムが開発されています。（それぞれに、優れている点と劣っている点があり、どれが最も優れたアルゴリズムか、ということは一概に言えません）

・ヒューリスティックマイナー

・インダクティブマイナー

・スプリットマイナー

現在入手可能なプロセスマイニングツールは世界に30ほど存在しますが、それぞれなんらかのアルゴリズムをベースに、精度を高めるためのカスタマイズを施していると思われます。

ユーザーとして留意しておきたいことは、同じイベントログだったとしても、様々なツールによって再現されたプロセスモデル（フローチャート）を比べてみたら、若干の違いがあるだろうということです。（まったく違うということはないにしても）なぜなら、それぞれ異なるアルゴリズムを実装しているからです。

Introduction to Process Mining (７) What is Event Log？

今回は、プロセスマイニングの分析対象となる「イベントログ」がどのようなものかについて解説します。

典型的なイベントログのデータフォーマット

プロセスマイニングツールにアップロード可能なイベントログの典型的なデータフォーマットは下表のようなものです。

ちなみに、ツールにアップロードするためのファイル形式は「CSV」が最も一般的です。CSVだけでなく「エクセル形式」、およびXMLに基づくプロセス定義のための交換フォーマット、「XPDL形式」でのアップロードが可能なツールもあります。

また、IEEEが標準として決めたタグ形式のイベントログは「XES（eXtensible Event Stream)」と呼ばれており、プロセスマイニングツールの中にはXES形式のデータのアップロードもできるものがあります。（業務システムから抽出した生データを前処理する際、最終的にはCSV形式にするのが一般的であり、XESデータを扱うことはほとんどありません）

さて、プロセスマイニング分析のためのイベントログのデータ項目は、大きくは「必須3項目」と、残りの「属性項目」で構成されます。

【必須項目】

必須項目は以下の３つです。

・案件ID（CaseID)

　上表の例は、顧客からの航空券の払い戻しプロセスです。予約していた便がなんらかの理由で利用できなくなったため、代金の返金を求める顧客からの申請を受け付け、審査を行い、返金することを決定したら、返金手続きを行い、顧客の銀行口座に代金を振り込むという流れになっています。

このプロセスにおいて案件IDとは、個別の顧客からの特定の予約についての申請について附番されたIDになります。おそらく、顧客からWebや電話などで申請を受け付け、システムに登録（返金申請受付）された時点で自動的に付番される仕組みになっているでしょう。

この案件IDがあることで、あるひとつの案件について、起点となるアクティビティ（システム操作）から、途中の節目となるアクティビティを経由して完了アクティビティまでを縦串にして、所要時間などを分析することが可能になります。

また、資材などの購買プロセスの場合、各部門の調達担当者が作成する「購買要求」が、システムに記録された時点で付番される「購買番号」を案件IDとして扱うことになります。

・活動（アクティビティ）

活動（アクティビティ）とは、業務システム上でなんらかの業務プロセスを実行する際、節目節目で記録される操作のことです。航空券の払い戻しプロセスの場合、「返金申請受付」、「審査」、「返金決定」、「返金手続き」、「口座振り込み」といったものがアクティビティです。

システム上の操作としては、なんらかの情報入力を行い、「完了」や「保存」などのボタンを押下したタイミングで記録されることが多いでしょう。システムによっては、あるアクティビティの開始と完了の両方が記録される場合もあります。例えば、「返金申請受付開始」、「返金申請受付完了」といったようにです。これは、システム上の操作のイメージとしては、返金申請の情報入力画面を立ち上げたタイミングで「返金申請受付開始」が、また、同入力画面を完了ボタンを押下して終了したタイミングで「返金申請受付完了」が記録されると考えてください。

操作のどのタイミングでアクティビティとして記録されるかはシステムの仕様次第であり様々です。おおむね、開始アクテイビティ、または終了アクティビティのどちらか一方しか記録されないシステムが多くなっています。

なお、一つ一つのアクティビティはシステムにおいては「イベント」として次に述べるタイムスタンプととともに記録されます。すなわち、「イベントログ」とは、システム上の操作イベントをひとまとまりのデータとして集約したもの、と言えます。

・時刻（Timestamp)

時刻（タイムスタンプ）とは、前項の活動（アクテイビティ）が業務システムで行われた時間を記録したものです。どの程度詳細な時刻が記録されているかはシステムの仕様次第です。できれば「年・月・日・時・分・秒」で記録されているのが望ましいのですが、「年・月・日・時・分」だったり、「年・月・日」だけで、時分が含まれていない場合もあります。

タイムスタンプは、案件IDに基づいて縦串した複数のアクテイビティの時間的順序、つまり、どのアクティビティが先に（後に）行われたかを判断するアルゴリズムに用います。したがって、「年・月・日」だけ、つまり時分秒が含まれていない場合、同日に行われた複数のアクテビティの時間的順序の判別が困難となり、プロセスフローチャートの精度が低下することになります。

【属性項目】

属性項目は、分析を深めるために追加する各種データ項目です。

航空券払い戻しプロセスの例では、「リソース」、「処理費用」、「顧客（名）」の３つが属性項目です。リソースは、当該システムを操作する担当者のことであり、しばしば、その担当者の所属部署や役職＝ロールの属性も分析対象とします。

また、購買プロセスの場合には、「サプライヤー名」や「製品名」なども追加されます。

属性項目は、業務プロセス上の問題（非効率性やボトルネックなど）を特定した際、それは、特定のリソースや顧客において起こりやすいかどうか、といった深堀りを行う「根本原因分析」において活用するものです。また、「活動基準原価計算（ABC: Activity Based Costing)」などに基づいて、処理費用の算出が可能であれば、属性項目として処理費用を追加することで、プロセスに係るコスト視点での分析が可能となります。

イベントログデータ作成フロー

プロセスマイニングの対象とする業務プロセスを決定したら、その業務プロセスを遂行しているITシステムから、必要なデータを抽出するわけですが、抽出されたデータ（生データ：トランザクションデータ）をそのままプロセスマイニングツールにアップロードすることはできません。

というのも、プロセスマイニングツールにアップロードするファイルは、ノイズなどが除去され、所定のデータ項目が揃ったクリーンなファイルに一本化する必要があるからです。

一般に、ITシステム内のDBから抽出されたデータは年度単位でファイルが分かれていたり、トランザクションファイルとマスターファイルが分かれていたり、データの抜け漏れ（ブランク）や文字化けがあったりと、要するに汚れたデータ、ダーティデータです。

このような複数（しばしば数十本）のダーティデータをクリーンにし1つのデータファイル＝クリーンなイベントログに加工する作業が「データ前処理」です。例えば、ブランクが存在するデータについては一括削除したり、なんらかの補正値を入力したりします。こうした前処理作業を数十万～数百万件の生データに対して行うため、基本的にはデータ前処理のためのツール「ETL」を用います。

ETLはExtract, Tranform, Loadの頭文字を取ったものです。文字通りデータ抽出からデータ変換（加工）、他のツールへのアップロード、さらには分析機能も持つ多機能なツールですが、プロセスマイニングにおいてはもっぱらデータ変換（加工）に活用します。

私がお勧めしているETLは、「KNIME（ナイム）」というオープンソースのツールです。日本語ローカライズはされていませんが、なんせ無料ですし、直感的な操作を行うことができる非常に優れたツールです。

KNIMEであれば、様々なデータ加工をノンプログラミングで行うことができるため、エンジニアでなくともデータ前処理を実行可能です。もちろん、エンジニアの方がデータ前処理を行うのであれば、SQL、Python、Rなど得意なスクリプトでデータ加工処理を行えば、KNIMEより高速に処理ができるでしょう。

なお、データ前処理の手順をワークフローとして作成すれば、同じプロセスについては差分データの前処理も同じワークフローで可能です。したがって、APIを通じて業務システムから分析対象の生データを抽出して前処理を行いプロセスマイニングにアップロードするまでを自動化することができます。

プロセスマイニングツールによっては、一般的なSaaS型の業務システムについて、APIで直接データを吸い上げる「コネクター」を提供しており、データの前処理作業も行えるものもあります。

Introduction to Process Mining (6) Process Mining and Related Solution

今回は、プロセスマイニングの隣接分野、関連ソリューションとの関係性について解説します。

ビジネスインテリジェンス（BI）の視点から

プロセスマイニングは分析手法のひとつです。ビジネスへの適用を前提とすると下図の通り、一番大きな枠として「ビジネスインテリジェンス」があり、その内側に「プロセスインテリジェンス」、さらにその内側に「プロセスマイニング」があるという入れ子構造になっていると考えることが可能です。

まずビジネスインテリジェンスですが、文字通り、ビジネスに関わるあらゆるデータ・情報を分析対象として収集し、分析するものです。いわゆるBIツールを用いて分析することが多いですが、典型的には、売上や利益などの財務データをベースに、年度別、月別、週別などの推移を見たり、エリア別や製品別にドリルダウンして、売上や利益に貢献しているエリアや製品カテゴリ、逆に足を引っ張っている要因がどこかを掘り下げて分析する。これがビジネスインテリジェンスです。

ビジネスインテリジェンスのうち、特に業務プロセスに関わるデータ・情報に絞って各種分析を行うのが「プロセスインテリジェンス」です。さらに、プロセスインテリジェンスの中で、業務の流れ、すなわち「コントロールフロー」を核とする分析手法が「プロセスマイニング」です。

このようにみると、プロセスマイニングは大きくはビジネスインテリジェンスに含まれるため、ビジネスインテリジェンスで代替できるのではないか、とおっしゃる方もいます。

しかし、プロセスマイニングの基本機能である「（自動的な）プロセス発見」には、特殊なアルゴリズムが必要であり、BIツールには、このアルゴリズムは通常、実装されていません。また、BI機能に基づいて、プロセスマイニング用のアルゴリズムをゼロベースで組むのは現実的には不可能です。（初歩的なものは組めたとしても、それによって、再現されたプロセスモデルの信頼性は低いものでしょう）

したがって、プロセスマイニングを実行したければ、専用のプロセスマイニングツールの採用が必要になり、BIで代替することはできません。

では、プロセスインテリジェンスがカバーする領域はどこになるのでしょうか？

プロセスマイニングツールでは、特殊なアルゴリズムを用いて行うプロセス発見以外に、様々な統計数値を算出し、様々な表・グラフで表現する機能が備わっています。

例えば、分析対象としたプロセスに含まれる案件数、プロセスの開始から終了までのスループット（サイクルタイム）や、各アクティビティごとの処理数、処理時間、あるアクティビティから別のアクティビティまでの移行時間、すなわち待ち時間などです。そして、これらの数値に関して平均、最大・最小、中央値、標準偏差などを併せて確認することが可能です。

こうした統計数値の算出は、シンプルな四則演算ベースで可能であり、特殊なアルゴリズムは言うまでもなく必要ありません。BIでも簡単に実行できますが、これこそ「プロセスインテリジェンス」がカバーしている領域です。

プロセスマイニングによる分析においては、アルゴリズムを通じて発見された「プロセスモデル」（as isプロセスモデル）を起点に、様々なバリエーションを検証する「バリアント分析」や、理想プロセス（to beプロセス）との比較分析、すなわち適合性検査などを行います。

さらに、処理時間がKPIを超えている問題アクティビティや、待ち時間が長くなっているボトルネックを特定していきますが、ここで重要になってくるのが処理件数や処理時間、待ち時間などの基本統計数値です。

すなわち、プロセスマイニングでは、プロセスモデルと併せてプロセスインテリジェンスの数値を様々な視点で掘り下げることを行うわけです。

主要なプロセスマイニングツールでは、プロセスモデルを作成するアルゴリズムは当然として、プロセスインテリジェンス機能、特に、様々な数値をビジュアルに表現するダッシュボード機能が標準で装備されています。この意味では、現在のプロセスマイニングツールは、「プロセスインテリジェンスツール」と言い換えても全く支障がないと言えます。

BPM、データマイニング・AIとの関係

プロセスマイニングと密接な関係がある隣接分野があります。ひとつはデータマイニング・AI、もうひとつはBPM（Business Process Management）です。

まずは「データマイニング・AI」とは何かから説明します。データマイニングは、基本的にビッグデータを対象とした分析手法であり、その主な目的はものごとの因果関係や典型的なパターンのような「法則性」を発見して、様々な意思決定に役立てることです。

例えば、各地の気温、湿度などの天候情報を大量に収集し、データマイニングでそのデータを分析することで、どのような状況において晴天になりやすいのか、それとも雨天になりやすいのかの予測式がつくられ、天気予報に活用されています。

データマイニングでは、数十年前から活用されてきた「多変量解析」の手法、例えば、回帰分析や、クラスター分析、決定木分析に加え、近年は主にニューラルネットワークによるディープラーニングが飛躍的な進歩を遂げ、ものごとを判別したり、予測する精度が大きく向上しています。一般に、これらの分析手法のことは「AI（Artificial Intelligence:人工知能）」と呼ばれますが、AIはデータマイニングにおいて頻繁に利用される手法なので、当記事では「データマイニング・AI」と一括りにしています。

さて、データマイニングはあらゆる分野のあらゆるビッグデータを分析対象としますが、基本的に「プロセス」を対象とはしてきませんでした。ある瞬間、すなわちスナップショット的な静的なデータを抽出して、要約したり、分類したり、因果関係を見出してきたりしたのです。

一方、プロセスマイニングは、文字通り、時系列のひとつながりになった動的なデータから、プロセスの流れを描き出すこと、すなわち「プロセスモデル」を作成することが基本にあります。もちろん、プロセス処理件数や処理時間など、プロセスに関わる静的な各種統計量も併せて算出する点は、データマイニングと共通しています。

こう考えると、データマイニングとプロセスマイニングは、分析手法としては兄弟分のようなものです。（どちらにも「マイニング」という言葉が含まれていますし）

ただ、プロセスマイニングを主体に考えると、プロセスに関わる様々な分析を深めていくうえで、データマイニング、AIの手法が応用されています。例えば、現在処理中の案件（ランニングケース）の終了までのリードタイムを推測するためには、データマイニングにおける「予測分析」が採用されています。

それ以外にも、必要に応じて、クラスター分析や決定木分析などが活用可能であり、今後も、プロセスマイニングツールとしての分析の幅や精度を高めるためにデータマイニングの手法がプロセスマイニングに取り入れられていくと考えられます。

では次に、BPM（BPM）について考えてみましょう。BPMはシンプルにいえば、プロセスを改善することを目的として、プロセスの現状を分析し、問題点を解消するto beプロセスを設計し、現場に展開・監視を行う一連の活動です。

このBPMの活動のうち、とりわけ「現状分析」において、プロセスマイニングの基本アプローチのひとつ、「プロセス発見」は役立ちますし、その後の設計、展開、監視においても、プロセスマイニングが提供できる「適合性検査」、「プロセス強化」のアプローチはBPMにとって強力な武器となりえます。

このように、プロセスマイニングとデータマイニング・AI、BPMはお互いに補完しあえる関係にあると言えます。プロセスマイニングのゴッドファーザー、Wil van der Aalst教授は、「プロセスマイニングは、データマイニングとBPMをつなぐ橋である」と述べられていますが、まさに、BPMの取り組みにおいて、プロセスに特化したデータマイニングとしての「プロセスマイニング」は大きな役割を果たしていくと思われます。

プロセスマイニングの前工程と後工程

業務プロセス改善の取り組みにおいて、プロセスマイニング活用を中心に置くと、プロセスマイニング分析を行う前工程としての「データ前処理」に関わるソリューションと、プロセスマイニング分析後の実際の改善施策としての様々なソリューションが存在します。

データ前処理は、ERPなどの業務システムから分析対象となるデータを抽出し、プロセスマイニングツール（およびタスクマイニング）で分析できるデータ形式へと整形する作業です。

業務システムから抽出した生のデータをそのままプロセスマイニングツールにアップロードできることは基本的にありません。抽出されたデータは複数のファイルで構成され、実際の取引履歴であるトランザクションデータ以外に、参照するためのマスターファイルが含まれています。また、データには抜け漏れ、文字化けなど、そのままでは分析できない箇所が存在するため、適宜削除、補正するなどの作業が必要です。これを「データ前処理」と呼びます。

データ前処理は、SQLやPythonなどで処理プログラムを記述することで高速に行えますが、こうした言語を知らなくても、データ前処理を簡単に行えるETLツールの利用を私はお勧めしています。ETLツールもいろいろとありますが、オープンソースで操作も簡単な「KNIME（ナイム）」が一押しです。

さて、プロセスマイニング分析後に発見した問題を解決するための施策としてのソリューションには、まずRPA(Robotic Process Automation）によるタスク自動化が挙げられます。また、プロセス単位で一定の業務手順を自動化するためにはビジネスプロセスマネジメントシステム（BPMS）の採用が有効でしょう。また、業務を遂行するためのリソース最適化のために、アウトソーシングサービス（BPO)の活用も検討に値するでしょう。

なお、プロセスマイニングを軸とする継続的プロセス改善のためには、分析対象となる各種データを長期に亘って蓄積し、柔軟に抽出できる仕組みが有効です。したがって、データウェアハウス（DWH）やデータレイクと呼ばれる分析系システムを構築して、実運用によって不断に生み出されるデータを収集・蓄積しておくことが望ましいです。

Introduction to Process Mining (5) Application areas of Process Mining

今回は、プロセスマイニングによる分析が可能な適用対象について、いくつかの視点で解説します。

システム・テクノロジー視点

まず、システムやテクノロジーの視点でプロセスマイニングの分析が可能なものについて概説します。

プロセスマイニングは1999年に研究がスタートしました。もともと、ビジネスプロセスマネジメント、ワークフローといった業務プロセスの可視化を目的として始まった分析手法ですので、分析対象となったのは企業の基幹システムである「ERP」です。こうしたシステムは取引履歴がDBに詳細に記録・保持されています（「大福帳型DB」とも言います）。

取引履歴、すなわちトランザクションデータには、業務システムの操作の節目となるアクティビティ、タイムスタンプ、そして案件IDが基本的に含まれており、プロセスマイニング分析が容易に行えるデータだと言えます。

また、ERPと並んで、CRM（SFA含む）システムから抽出される業務システム操作ログは営業管理、顧客管理に関わるデータであり、プロセスマイニングの分析対象として有効です。

もちろん、個々の企業が独自開発したレガシーシステムについても、それがどんなコンピュータ言語で開発されていようとも、「業務システム操作ログ」が記録・保持されていればプロセスマイニングでの分析が可能となります。（多くの場合、レガシーシステムでも業務システム操作ログ、あるいはトランザクションデータはなんらかの形で記録されています。）

また、コールセンターでの顧客からの問い合わせの対応履歴を管理するCTI(Computer Telephony Integration)や、ITヘルプデスクのためのシステムからは、問い合わせ対応や、チケット対応履歴データが抽出できます。この、いわゆる「コミュニケーションログ」も、プロセスマイニングではしばしば分析されます。迅速な解決のための対応プロセスの改善により、顧客満足の向上を目指すことが主な目的です。

Webサイトの訪問履歴、すなわち「Webアクセスログ」も、訪問者のセッションID（Cookieも可）、訪問したページ（＝アクティビティ）、タイムスタンプの3つの必須データ項目が含まれており、Web上での顧客の振る舞いを分析するためにプロセスマイニングが採用されます。顧客の行動をプロセスマイニング分析することは「カスタマージャーニーマイニング」と呼ばれています。

さて、意外な分析対象なのが、「機器操作ログ」です。「マシンログ」とも言いますが、これまでしばしば分析されているのが医療機器、具体的にはCTやMRIといったものです。分析目的は、稼働率の向上や適切に利用されているか、といったものです。

また、近年、IOT（Internet Of Things)が注目され、あらゆる場所にセンサーが設置されることで、センサーが捕捉したログが大量に発生しています。センサー捕捉ログはデータ量が大きく、ノイズが大量に存在しますが、適切にデータ前処理を行うことでプロセスマイニングを実行できます。

最後は、エクセルやブラウザーの詳細な操作履歴を収集したPC操作ログです。PC操作ログは、業務システム内に保存されているイベントログと異なり、分析対象PCに操作内容を収集するエージェントをインストールして能動的に蓄積する必要があります。PC操作ログは、タスクレベルの業務内容の見える化が可能であることから、「タスクマイニング」と呼ばれます。このPC操作ログはIOT同様、データ量が膨大でノイズが多く含まれますが、データ前処理を行うことでプロセスマイニングツールでの分析が可能です。

バリューチェーン視点

下図は、企業活動を価値を生み出し、顧客に提供する仕組みとして構造化してもので「バリューチェーン」と呼ばれています。ここでは、バリューチェーンの視点でプロセスマイニングの分析対象を考えてみましょう。

様々な企業活動において、収益を得て事業を継続する「価値創出プロセス」は、

購買物流→製造→出荷物流→販売・マーケティング→アフターサービス

の流れです。この価値創出プロセスの多くは現在、ERPや、CRM(SFA)などの業務システム、またSaaS型の各種アプリケーションで遂行されるようになってきており、どの段階においても、プロセスマイニング分析による継続的改善が行われるようになってきました。

また、この価値創出を支えるさまざまな機能、すなわち調達活動、技術開発、人事労務管理、全般管理についても、システム化が進行している管理についてはプロセスマイニングが採用されるケースが増えてきています。

例えば、人事労務管理の領域になりますが、新規採用人材の受け入れプロセスである「オンボーディング」を効果的、効率的に行うための改善を目的としてプロセスマイニングが採用されています。

分析対象となることの多い業務プロセス

最後に、これまでプロセスマイニングの分析対象となることの多かった業務プロセスをご紹介します。

まず、「受注（O2C)プロセス」、「購買（P2P)プロセス」は非常に多く分析されています。バリューチェーンの枠組みでは、まさに価値創出プロセスの根幹にある最も重要な業務だからでしょう。欧米では特に、ERP上で実行されることの多い業務プロセスであり、データの抽出、前処理の手順がある程度標準化できることも、分析対象とされることの多い理由です。

また、受注プロセスに含まれますが、倉庫などで、顧客からの発注を受けて在庫を割り当て、出荷を行うまでのプロセスが分析されることも多くなっています。

さらに、バリューチェーンの価値創出プロセスでは最下流にあたる「問い合わせ対応」やヘルプデスクも、手順がある程度定型化され、イベントログとしてシステムから抽出が容易なためプロセスマイニングが行われています。

経理部門に限定されるプロセスとして、「買掛金管理」、「売掛金管理」も、ERP上でほぼ完結し、分析が容易であることから、しばしば分析対象となります。

Introduction to Process Mining (４) What Process Mining can deliver

今回は、プロセスマイニングの活用がもたらす主な効用（ベネフィット）について解説します。

経営的インパクト

まずは、経営的な視点で考えてみましょう。すなわち、プロセスマイニングの活用が、経営上のゴールともいえる売上や利益の向上にどのように貢献できるか、ということについてです。

第一に、「コスト削減」の成果が期待できます。プロセスマイニングによって業務プロセスが可視化されることにより、ムダな業務を洗い出すことが可能です。ムダな業務とは、たとえば、そもそもやらなくても支障のない業務や、ミス多発により手戻りが発生しやすい業務などです。こうしたムダな業務を除去したり、ミスを減らせるような手立てを講ずることで、業務プロセスの遂行コストの削減が可能となります。

第二に、「顧客満足度向上」が期待できます。例えば、受注から納品までの「受注プロセス」の場合、プロセスマイニングによる問題点の把握と改善を行うことによって、納期の短縮が図れます。顧客にとって、注文したものが以前よりも早く届くようになれば満足度は高まります。また、業務プロセスが最適化されれば、納期短縮だけでなく、発注したものとは違うものが届くといったミスも減ることも期待できます。すなわち、プロセスのスピード、および質の向上によって顧客満足度の向上が可能となり、結果的に受注金額の増大やリピート率改善につながることになります。

第三に、「従業員満足度の向上」も期待できます。プロセスマイニングによってあぶりだされたムダな作業や業務の滞留、すなわちボトルネックが解消されれば、業務プロセス完了に費やされる労働時間が減り、不必要な残業がなくなって総労働時間の短縮が可能となります。徒労に感じられるような業務に時間を取られることなく、効率的に業務を遂行できるようになり士気も高まることでしょう。

プロセス改善の手がかり

前項では、最終的な売上・利益にどのようにプロセスマイニングが貢献できるかを解説しました。ここでは、プロセスマイニング分析の結果から、どのようなプロセス改善につなげることができるかを説明します。

プロセスマイニングツールにイベントログをアップロードし分析を行うことでまず「現状プロセス」が可視化されます。ここから様々な現状分析を行っていきます。可視化された現状のプロセス（as is プロセス）からは以下のような問題点が発見できるでしょう。

・非効率なプロセス（想定よりも処理時間が長い箇所）

・ボトルネック（仕事が滞留している箇所）

・スタッフスキルのばらつき（個々人の生産性の違い）

・手戻り（繰り返し）プロセス

これらの問題が発見できたら、「なぜこのような問題が発生してしまうのか」を掘り下げます。「根本原因分析」です。結果、原因が特定できたら、その原因を解消するための改善施策を検討し展開します。改善施策としては以下のような打ち手が考えられます。

・プロセス変革（ムダ業務の除去、手順の見直しなど）

・要員配置の最適化（シフトの見直し等）

・スキルアップトレーニング（生産性の差を均すため）

・RPA化（定型業務を中心とした自動化）

・BPO化（要因配置計画をより柔軟に行うため）

また、可視化された現状プロセスのバリエーションの中に、優れた手順を発見することができたら、それを「理想プロセス（ハッピープロセスとも言います）」とみなし、標準化を図ります。そして、マニュアルを作成したりBPMシステムのワークフローとして組み込むことで全社に展開することが有効な打ち手でしょう。

一方、すでに標準プロセスが存在していた場合、それをto beプロセスとしてプロセスマイニングツールにアップロードすれば、現状プロセスとの比較分析（「適合性検査」と呼びます）を行うことで、標準から逸脱しているプロセスをあぶりだすことができます。

この逸脱についても根本原因分析を行い、即時是正を行ったり、法令遵守、すなわちコンプライアンス上の問題に発展する可能性がある場合には、対象部署に対するコンプライアンス研修などを行い、逸脱発生を未然に防ぐ施策を打ちます。

このように、プロセス改善、プロセスの標準化に向けての適切な改善施策を検討する前段となる、プロセス上の様々な問題を簡単に発見できることが、プロセスマイニングの直接的な効用だと言えます。

なお、プロセスマイニングツールと業務プロセスを接続可能とし、リアルタイムにイベントログデータをツールに流し込むことで、完了した案件だけでなく、未完了案件のリアルタイム監視も可能です。

リアルタイム監視の場合、現在仕掛り案件についてボトルネックや逸脱の発生を探知できることから、ただちに改善措置を行うことが可能となります。ツールによっては問題の発生を事前に予測することもでき、未然に問題発生を阻止することさえ行えます。こうした機能は「運用サポート」と呼ばれ、近年ユーザーの評価がますます高まっている、プロセスマイニングのベネフィットだと言えます。

業務分析手法としての効用

プロセスマイニングは、業務プロセス改善やシステム改修を主な目的とする現状把握のための業務分析のひとつです。従来の業務分析は現場ヒアリングなどアナログな手法であったのに対し、業務システムから抽出されたイベントログデータを分析するデジタルな手法です。

これまで述べてきた便益に加えて、業務分析手法としてのプロセスマイニングは従来のアナログな手法と比較してのメリットもあります。

従来手法は前述したように、分析対象となる業務プロセスに関わっている関係者に個別ヒアリングを行ったり、一堂に会して議論するワークショップ、またストップウオッチを手にしての観察調査（動作調査）などアナログな方法です。

ヒアリングやワークショップの場合、関係者の発言がベースになることから、ありのままの現実というよりは主観的なものになります。また、記憶に頼ったものになるため、得られる情報は断片的です。

なにより、長大・複雑なプロセスの場合関係者も多数存在し、ヒアリングやワークショップにかかる時間とコストは膨大なものになります。観察調査は主観性はある程度排除できるもののの実施の負荷は大きく、また業務遂行の邪魔になる可能性もあります。

一方、プロセスマイニング分析は、業務システムから抽出したイベントログデータにもとづく定量分析です。システム上の操作履歴を基本的に丸ごと、全数で分析するため、客観的かつ、漏れのないエンド・ツー・エンドのプロセスを再現することが可能です。

プロセスマイニング分析自体は、現場担当者に大きな負担をかけることはありませんし、データクリーニングなどの前処理の手間を含めても、従来手法よりも大幅な期間圧縮、コストダウンが可能です。

ただし、注意点があります。プロセスマイニング分析の分析対象は業務システムで行われた業務のみであり、エクセルなどで行われた中間ファイル作成業務などは捕捉できません。プロセスマイニングは、エンド・ツー・エンドのプロセスを見える化できるとは言え、その粒度は現実の業務よりは粗いものになります。

したがって、プロセスマイニング分析から得られた現状プロセスをベースに、漏れているタスクレベルの業務はやはり現場担当者へのヒアリングやワークショップを補完的に行う必要があります。もちろん、従来手法のようにゼロベースでのヒアリングよりは、はるかに的確で効率的な情報収集が可能となりますので、業務分析にプロセスマイニングを採用することのメリットは総合的には非常に大きいと言えるでしょう。