プロセスマイニング – Process Mining

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で直接データを吸い上げる「コネクター」を提供しており、データの前処理作業も行えるものもあります。