processmining

Two approaches to dig into the root-causes of a process.

新しいITツールが登場すると、多くの人は過大な期待を抱きがちですが、プロセスマイニングに対してもまた、夢のような万能ツールと思い込む方がいらっしゃるようです。

プロセスマイニングは分析手法に過ぎず、また分析を通じて手にするものは、ありのままの現状であり、その現状から見えてくる現象としての問題点のみです。

具体的にお話しすると、分析対象となるプロセスに関わるイベントログを抽出し、プロセスマイニングツールで分析することにより、事実ベースでの現状プロセス（as isプロセス）がフローチャートとして可視化されます。

そして、プロセスの各手順となるアクティビティの処理回数や処理時間、待ち時間などが算出されることから、プロセスのどこの業務量負荷が高くなっているか、どこに時間がかかりすぎているか、どこにボトルネックがあるか、という問題の所在を特定できます。

しかし、なぜそのような問題が発生しているかという原因はデータの中にはありません。さらに分析を進めて、ある担当者の業務においてボトルネックが発生しやすい、といった形で問題の発生源を絞り込んでいくことまではできますが、相変わらず「原因」が明らかになるわけではないのです。

そもそも、何らかの問題が発生しているとき、それはかなり根深いところに原因があったり、また複合的な原因によることも多く、問題と原因が一対一で結び付くとは限らないのです。

したがって、プロセスマイニングによる分析を進めるうえでもっとも重要でかつ難度が高いのが「根本原因分析」です。なぜ最も重要かと言うと、プロセスの改善は対処療法ではなく、根本原因を解消することが最も効果的であるからです。

たとえば、顧客対応プロセスにおいてボトルネックが発生しており、対応の遅れにより顧客満足度が下がっているとして、ボトルネック解消のために、単純にスタッフを増員すればいいでしょうか。スタッフ増員によってボトルネックは一時的に解消できたとしても、コスト増をもたらし、業績的には利益低下につながってしまうのです。

しかし、もし、根本原因を突き止めることができ、スタッフ増員なしでボトルネックが解消できたとしたらどうでしょう。顧客満足度が改善されると同時に、利益を圧迫することもありません。

とういわけで、プロセスマイニングにおいては、「根本原因分析」に一番力を入れるべきなのですが、当記事では数十年前から知られる根本原因分析に役立つ２つの枠組みをご紹介しましょう。業務分析やビジネスコンサルティング手法を学ばれたことがある方にとってはお馴染みだと思います。

１　５Why分析

問題がある場合に、「なぜ、そうなっているの」という問いを5回繰り返していく方法です。これはトヨタ流の問題解決法としてよく知られています。５Whyだからといって、必ず5回繰り返さなければならないというものではなく、3回のなぜで根本原因＝「真因」にたどり着くこともあるでしょうし、逆に7回繰り返さないとたどりつけないほど根深いところ真因がある場合もあるでしょう。「なぜなぜ分析」と呼ぶ方もいらっしゃいます。

２　フィッシュボーン分析

フィッシュボーン分析は原因の構造化を図る手法であり、見た目が魚の骨に似ていることからこのように呼ばれています。「特性要因図」や、日本の品質管理（QC:Quality Control）の父、石川馨氏が考案したことから「石川ダイヤグラム」とも呼ばれます。

フィッシュボーン分析は、QC7つ道具のひとつとしても知られており、特に、製造業の生産現場での品質管理のために利用されてきました。問題を起こしている原因が複数存在する場合に、原因を大きく分類していくことで構造化を図り、問題解決のためにどこからどのように改善施策を打てばいいかを検討するために有効です。

Very basic principle of process mining algorithm

プロセスマイニングを初めて知った方から、

「イベントログから、どうやってプロセスの流れを示すフローチャートが作成できるのですか？」

という質問をいただくことがあります。

イベントログからフローチャート、すなわち「プロセスモデル」を作成する「アルゴリズム」は極めて技術的な内容であるため、最も基本となるポイントのみを解説したいと思います。

より深く、正確に理解したい方は、Aalst先生の著作、『Process Mining: Data Science in Action』、およびｅラーニング講座（Coursera）をご覧ください。

さて、プロセスマイニングツールによってプロセスモデルを作成するために必要なイベントログのデータ項目は、以下の３つです。

• 案件ID
• アクティビティ
• タイムスタンプ

案件IDは、たとえば経理部門での請求書処理プロセスの場合だと、1枚1枚の請求書番号が該当します。所定のプロセスはどの請求書についてののものかを特定するために必要なので案件IDと呼ばれます。

アクティビティは、プロセスを構成する手順を示します。請求書処理であれば、たとえば、「請求書受領」を起点として、「OCR読み込み」、「OCR変換データ確認」、「会計システムへのデータ登録」、「発注金額との突合せ確認」、「上長への支払い承認依頼」といったそれぞれの手順です。

タイムスタンプは、上記各手順が実行されたタイミングを「年月日時分」などの形式で記録されたデータを会計システムから抽出します。

つまり、これら３つのデータ項目には、ある個別の案件に対して、どのようなアクティビティ（操作）がいつ行われたかという情報が含まれているわけです。

プロセスマイニングツールに投入可能な、整備済のイベントログサンプル

ここからが問題です。この３つの項目が含まれたイベントログから、どうやってプロセスの流れを再現するのでしょうか。単純化して言えば、プロセスの流れとしては、アクテイビティの時間的前後関係しか考慮していません。つまり、アクテビティ「Ａ」と「Ｂ」の２つがあったとして、ＡがＢよりも早い時間に行われていればＡ→Ｂと続く流れになるという、非常に明白なロジックです。

ただし、たくさんの案件を複雑な手順で行っている現実の業務においては、様々な処理のパターンが起こりえます。

わかりやすいように、タイムスタンプを省いて、以下のような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までのすべてを考慮したプロセスモデルは以下の通りです。

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

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

非常に複雑なプロセスの場合、すべての案件のパリエーションを表すと、ごちゃごちゃしたスパゲッティのような図になります。

そこで、発生頻度の少ないバリエーションを非表示化していき、頻度の多いパターンだけに絞り込んでいけば、典型的な業務手順が見えてきます。

最も発生頻度の高いプロセスモデルのことを「ハッピープロセス」と呼ぶ場合があります。ただ、典型的なプロセスではあるものの、だからといって必ずしも優れた、理想的なプロセスとは限らないことを留意しておく必要があります。

以上、イベントログからプロセスモデルを作成する基本的な考え方について単純化して説明してまいりました。Aalst先生の著作やｅラーニング講座によれば、ベントログからフローチャートを作成するアルゴリズムは、非常に難しい課題を抱えていることがわかります。

アルゴリズム自体、アルファ―マイナー、ヒューリスティックマイナー、インダクティブマイナーなど、何種類もあります。そして、用いるアルゴリズムによって、同じイベントログであったとしても描かれるフローチャートの形は異なってくるのです。

商用ツールでは、各社とも最も現実の手順を反映できると考える独自のアルゴリズムをそれぞれ提供していますが、仮に同じイベントログだったとしても、ツールによって提示されるプロセスモデルが異なっている場合があるということを頭に留めておく必要があるでしょう。

Process mining can materialize a digital twin of an organization.
English follows Japanese. Before proofread.

「デジタルツイン」は、純粋なテクノロジーとしてはビジネスに適用範囲が限定されるものではありませんが、プロセスマイニングにおいては、「Digital twin of an organization」の略称です。

「Digital twin of an organization」は直訳すれば、「組織のデジタルな双子（片割れ）」となります。

一方、現実の職場、仕事は「アナログな双子（片割れ）」です。アナログな現場では、多くのスタッフが協働しながら業務を行っています。ただ、業務の多くがITシステムで遂行されるようになったことから業務内容がデジタルな足跡（Digital footprint）として残されています。

デジタルな足跡、すなわち「イベントログ」をプロセスマイニングで分析することにより、今まで見えなかった業務内容を可視化することができるようになりました。業務プロセスの流れはフローチャートとして”発見”できます。

プロセスマイニングによって、案件処理数や、アクティビティ単位の「処理時間（サービスタイム）」や前工程から次工程までの移行時間、すなわち「待ち時間（ウェイティングタイム）」なども算出可能であり、業務負荷の高い箇所、業務が滞留しているボトルネックの特定が容易になりました。

また、誰がどんな業務を担当しているのか、誰と誰が業務を通じて連携し、協働しているのかも明確に把握可能です。

重要な点は、ぼんやりとしかわかっていなかった業務の流れや処理件数、所要時間、協働関係などを事実（fact）に基づいて明確化できることです。プロセスマイニングによって見える化された各種のフローチャートや図表は、まさに、組織の在り方、業務内容をデジタルデータに基づいて再現した「デジタルツイン」だと言えます。

デジタルツインを実現するメリットは、現実をファクトベースで正確に把握できることだけではありません。デジタルツインであれば、一部の工程を削除したり変更したらどうなるか、あるいは一部のプロセスをRPAで自動化したら全体にどのような影響が起こるのか、シミュレーションが行えます。

すなわち、どのように業務プロセスを改善すれば、リードタイム短縮化、コスト削減、ボトルネックは解消できるのかを検証したうえで、アナログツイン、つまり実際の現場、現実のプロセスに展開することが可能です。

さらには、ITシステム上に記録され続けているイベントログをリアルタイムでプロセスマイニングツールに流し込めば、現場の業務遂行状況をデジタルツインにおいて監視し、問題点の即時是正が行えます。

以上でおわかりのように、プロセスマイニングは、デジタルツイン実現のために必要不可欠のツール、ソリューションです。

“Digital twin” is not limited to business as a pure technology, but in process mining, it stands for “Digital twin of an organization”.

The literal translation of “Digital twin of an organization” is “one digital half of twins of an organization “.

On the other hand, the other half is “Analog half of twins of an organization” where employees work together in the analog field. However, since much of the work is now performed by IT systems, the work remains as a digital footprints.

By analyzing digital footprints, or “Event Log” through process mining, it has become possible to visualize previously unseen business operations. The flow of business processes can be “discovered” as a flowchart.

With process mining, we can calculate the number of cases processed, the “Processing time (service time)” per activity, and the transition time from the previous process to the next process, i.e., the “Wait Time (waiting time)”, etc., making it easier to identify areas with high workload and bottlenecks with stagnant business.

In addition, it is possible to clearly understand who is in charge of what kind of work and who is collaborating and collaborating with each other through work.

It is important to be able to clarify, based on the facts, the flow of work, the number of processes, the time required, and the functions involved in collaboration that were only vaguely understood. The flow charts and diagrams visualized by process mining are truly “digital twin” that reproduce the way an organization works and the contents of business operations based on digital data.

The benefits of a digital twin are not just accurate fact-based reality. With a digital twin, you can simulate what happens if you delete or change some of the processes, or if you automate some of the processes with the RPA and see the overall impact.

In other words, after examining how to improve business processes to reduce lead time, reduce costs, and eliminate bottlenecks, it is possible to apply the method to an analog twin, that is, a real process.

In addition, by flowing the event log continuously recorded on the IT system into the process mining tool in real time, the work execution situation in the field can be monitored in the digital twin, and the problem can be corrected immediately.

As you can see, process mining is an essential tool and solution for achieving a digital twin.

Hidden truth of process mining(1)
English follows Japanese Before proofread.

最近、業務改革の切り札としてプロセスマイニングに対する関心がますます高まっています。多くの人は、プロセスマイニングのデモで示される「プロセスモデル」、すなわち、イベントログから自動的に作成された業務フローチャート図を目にして「おおっ、すごい」と感嘆の声をあげます。

業務プロセスを可視化するための従来のアプローチであるヒアリングやワークショップの大変さと比較して、ITシステムから抽出したデータから簡単にすばやく業務フロー図が描けるのはすばらしい、と皆さんお感じになるわけですね。

ただ、何事にも明るい側面（Bright side)と、暗い側面(Shadow side)があるものです。プロセスマイニングツールを操作して、今まで見えなかった業務プロセスの流れや業務と担当者との関係が図表でわかりやすく示されるところは「明るい側面」です。一方、導入の心理的ハードルを上げてしまうために、あまり語られない「暗い側面」があります。

暗い側面は実は２つあります。プロセスマイニングツールを操作して実際の分析を行う段階の前に必要な業務である「データ前処理」、そして実際の分析の後に行う「分析結果の評価・解釈」の２つのフェーズです。

プロセスマイニングツールを操作して、ビジュアルな画面を切り替えるのは簡単で楽しいものです。一方、データ前処理、および分析結果の評価・解釈は多大な労力を要します。しかし、プロセスマイニングを通じて業務改革を成し遂げるためには避けて通るわけにはいかないフェーズ。このことは、プロセスマイニングの不都合な真実と言えるでしょう。

今回は、まず、プロセスマイニング分析の前工程である「データ前処理」について解説します。

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

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

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

このような複数（しばしば数十本）のダーティデータをクリーンにし1つのデータファイル＝クリーンなイベントログに加工する作業が「データ前処理」です。

データ前処理をどのように行うかの説明は別記事で取り上げますが、例えば、ブランクが存在するデータについては一括削除したり、なんらかの補正値を入力したりします。こうした前処理作業を数十万～数百万件の生データに対して行うため、基本的にはデータ前処理のためのツール「ETL」を用います。

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

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

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

データ前処理の基本的な流れ

データマイニングプロジェクトでは、しばしば、データ前処理にプロジェクト工数の8割ほどが費やされると言われますが、プロセスマイニングプロジェクトでも同様に、データ前処理がプロジェクト成功の鍵を握っています。きちんとしたデータが準備されてこそ、プロセスマイニング分析、また分析結果の評価・解釈が意味のあるものになるからです。

Recently, there has been increasing interest in process mining as a trump card for business innovation. Many people marvel at the “process model” shown in the process mining demos, or business flow charts automatically created from event logs, saying, “Oh, my God.”.

In contrast to the challenges of traditional approaches to visualizing business processes such as interviews and workshops, you find it great to be able to draw business flow diagrams easily and quickly from data extracted from IT systems.

But everything has a bright side (Bright side) and a dark side (Shadow side). When you operate the process mining tool, the flow of business processes and the relationship between business and the person in charge, which has not been seen until now, are shown clearly in the diagram, is “bright side”. On the other hand, there is a “dark side” that is rarely talked about because it raises the psychological hurdle of introduction.

There are actually two dark sides. There are 2 phases: “data preprocessing” which is the work required before the stage of operating the process mining tool and performing the actual analysis, and “Evaluation and interpretation of analysis results” which is performed after the actual analysis.

It’s easy and fun to navigate through process mining tools and switch between visual screens. On the other hand, data preprocessing and the evaluation and interpretation of analysis results require a great deal of labor. However, this is a phase that cannot be avoided in order to achieve business reform through process mining. This is an inconvenient truth of process mining.

In this article, I will first explain “data preprocessing” which is a pre-process of process mining analysis.

Once a business process to be subjected to process mining is determined, necessary data is extracted from the IT system executing the business process, but the extracted data (raw data: transaction data) cannot be directly uploaded to the process mining tool.

This is because the files to be uploaded to the process mining tool need to be unified into a clean file with all the necessary data items.

In general, the data extracted from the DB in the IT system is dirty data or dirty data, for example, the file is divided by the year, the transaction file and the master file are separated, and there are omissions of data (Blank) and garbled characters.

“data preprocessing” is the process of cleaning such multiple (Often dozens) dirty data and processing them into 1 data file = clean event log.

We’ll discuss how to do this in a separate article, but for example, you might want to delete all data with blanks or enter some correction. To perform these preprocessing operations on 100,000 to 1 million raw data items, a data preprocessing tool “ETL” is basically used.

ETL, which stands for Extract, Tranform, and Load, is a multi-functional tool that literally extracts data, transforms it (Machining), uploads it to other tools, and even provides analysis capabilities, but is used exclusively for data transformation (Machining) in process mining.

The ETL tool I recommend is an open source one called “KNIME”. It’s not localized in Japanese, but it’s free and very intuitive.

KNIME can perform various data processing without programming, so even non-engineers can perform data preprocessing. Of course, if your engineers preprocess data, they can do it faster than KNIME by using SQL, Python, R, or other scripts that you’re good at.

In data mining projects, it is often said that data preprocessing consumes about 80% of the project effort. Process mining analysis and the evaluation and interpretation of analysis results become meaningful only when proper data is prepared.

「プロセスマイニング」は、主に業務プロセスの「見える化」を行う分析手法です。分析対象としては、業務遂行に用いられる様々なシステム、具体的にはERPやCRM、SFA等の操作内容を詳細に記録したデータ、すなわち「イベントログ」を用います。

プロセスマイニングを行う主な目的は、プロセスに関わる様々な問題を発見することです。例えば価値を生まない無駄な手順や、非効率な活動、業務の滞留が発生しているボトルネックなどを特定し、是正することで、プロセスを開始してから完了するまでの所要時間を短縮、あるいは、プロセスに係るコスト削減を狙います。

プロセスマイニングを病気の治療にたとえるなら、改善すべき問題プロセスは、CoE（Center of Excellence）と呼ばれるプロセス改善のための専門病院に入院させます。そして、まずは治療対象プロセスの概要を把握するための問診を行います。

次に、X-ray（レントゲン）は、レントゲン写真や、CT検査としてのプロセスマイニングにより、業務プロセスを「見える化」します。見える化、すなわち業務プロセスを表すフローチャートを見ながら、非効率、ボトルネック、逸脱などの病巣を特定。

さらに詳細に病巣を検査したければ、PC操作ログを収集、分析するタスクマイニングを実行します。タスクマイニングは、内視鏡のようなものです。

病巣が特定され、また根本原因が判明したら、適切な治療方針・処方を行い、手術（改善施策）に着手します。無事、病巣、すなわち問題箇所が解消され、対象プロセスが最適化されたら、予後の経過を見るために定期検診＝継続的モニタリングを行い、再発防止に努めるのです。