プロセスマイニング – 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プロセスとして抽出、必要に応じて整形を行った後、プロセスマイニングツールに再投入すれば、他のプロセスパターンとの適合性検査が可能となります。