プロセスマイニング事例:Siemens Healthineers – マシンログ(CTスキャナー)分析

ct scanner

Process Mining Case: Siemens Healthineers – CT Scanner data analysis

Siemens Healthineer(以下、SHS)は従業員数3万人超、医療機器のCTスキャナー(コンピュータ断層撮影)のグローバルマーケットリーダーです。CTスキャナーのグローバル市場シェアは33%以上、年率10%の成長率を続けています。

現在世界で29,000台のCTが稼働しています。CTを動かすためのソフトウェアは3つのプラットフォーム上で開発されており、合計31システム、バリエーションは74あるため、設定条件は最大3000パターンに上っています。

さて、稼働中の29,000台のCTのうち、最大14,000台については日々の稼働データがXMLファイル形式で送信されており、蓄積されるデータ量は50G/日です。このビッグデータはBIの「Qlik」で集計され、様々な文政ダッシュボードが作成されて社内で利用されています。

同社が、CTスキャナーのイベントログデータに対するプロセスマイニングに取り組んだ背景には、BIによって、CTがどう(WHAT)稼働しているかのスナップショットは十分分析できているが、どのように(HOW)稼働しているかを把握したいという動機がありました。

CTスキャナーにおける作業プロセスは大きくは以下の流れです。

1 患者を登録(Register Patient)

2 プロトコールのアップロード(Load Protocol)

3 患者位置確定(Confirm Position)

4 走査位相のアップロードと読み込み(Load Topo)

5 走査開始(Scan)

6 再構成(Reconstruct)

7 終了(Close)

上記のログデータはマシンログとして記録されており、同社ではSQLサーバに蓄積しています。このマシンログを抽出、整備してプロセスマイニング分析を実行しています。

SHSで採用しているプロセスマイニングツールは、「MEHRWERK Process Mining(以下、MPM)」です。同社がMPMを採用した最大の理由は、MPMはQlikのプラグインとして提供されており、既に社内で活用されているQlikと一体的に利用することが可能だったからとのこと。

プロセスマイニングを通じて、CTスキャナーが現場でどのように(HOW)利用されているかが明らかとなり、様々な改善ポイントも見えてきました。

例えば、走査時間が徐々に遅くなってきており、CTスキャナーの一人の患者当たりのスループット(総利用時間)が長くなる傾向がデータから明確になりました。これは、アルゴリズムのパラメターの設定方法の見直しや、ソフトウェアにおけるなんらかの改善が必要なことを示唆します。

また、CTスキャナーの操作手順のバリエーションは、87,000以上に上ることがわかり、手順の標準化を推進すべきであることも判明しました。プロセスマイニングではこうしたバリエーションを詳細に検証可能であり、標準化を行う助けとなります。

また、地域(例えば、中国と米国)間の操作方法の比較分析なども行うことで、同社CT製品の改善に取り組んでいます。

プロセスマイニング事例:Suncorp – 保険金請求処理プロセスの劇的改善

insurance claim form

Process Mining Case: Suncorp – Huge improvement in Claim handling process

サンコープ(Suncorp)はブリスベーンに本社を置く、オーストラリア最大の保険・金融事業グループです。従業員数は16,000人以上、顧客数は900万人に上ります。

サンコープ社がプロセスマイニングに取り組んだ時期も早く、2012年頃からです。当時は商用ツールは普及していません。そこで同社では、オープンソースのプロセスマイニングツール、「ProM」を利用し、クィーンズランド工科大学の研究者の支援を受けて保険業務のプロセスマイニング分析に取り組んだのです。

保険業務のプロセスは、E2E(End-to-End)では、保険商品の開発から販売、サービス、そして保険金請求処理までが含まれ、業務要素は500に上ります。また、保険商品の種類としても、家財保険、自動車保険をはじめ30種類を超えます。結果として、プロセスのバリエーションとしては3000以上と非常に複雑なものです。

こうした複雑なプロセスを運営するサンコープ社では以下のような課題を抱えていました。

・ガバナンス不在:現場担当者のトレーニングが不十分、かつ手順が確立されておらず、責任者が不明確

・トップの支援不足:トップの理解が弱く、現場の改善のために必要な投資や支援が十分に得られない

・計画・ツールの欠如:プロセス最適化のための計画やツールが不足

上記のような課題を解決するため、同社ではプロセスマイニングを通じて現状プロセスを可視化し、問題点について社内の理解を得やすくしたうえで、必要な改善施策を講じることに取り組みました。

とりわけ劇的な改善成果を上げたのが、保険金の請求処理プロセスです。これは、例えば自動車事故を起こした場合に、契約者が行った保険金請求案件について、内容を審査し、事故に関連した費用をカバーする保険金を支払うまでの一連の手順です。

まず、保険金請求処理プロセスのスループット(総所要時間)の分布を分析。横軸に保険金支払額の大きさ、縦軸にスループットを取った2軸に各処理案件をプロットした下図を見ると問題が明らかです。

Source: Understanding Proess Behaviours in a Large Insurance Company in Australia: A Case Study, Conference Paper – June 2013

右上の「Complex Slow」は、支払保険金額が大きく審査に時間がかかることからスループットが長くなっていいる案件です。ある程度時間が長くなるのは許容しなければならないでしょう。

右下は「Complex Quick」です。支払保険金額は大きいもののスループットが短くなっています。安易な審査になっていなければ、支払保険金額が大きくてもすばやく契約者に振り込めるのは顧客満足度を向上させるでしょう。

左下は、「Simple Quick」です。支払保険金額は少なく、スループットも短い。問題なしです。

左上の「Simple Slow」が問題プロセスです。支払保険金額が少ないのにスループットが長くなってしまっている。保険金額の大きさと比較してよけいな手間、コストを要してしまっているという内部的な問題であり、かつ少額の保険金請求なのになかなか保険金が支払われない、という点においては顧客の満足度を低下させてしまうことにつながっています。

この問題の解決の基本方針としては、少額保険金請求案件はできるかぎりスループットを短くする、すなわち、プロット図で見ると、左上にある案件を左下に移動させるということです。

そこで、左上の「Simple Slow」のプロセスと左下の「Simple Quick」のプロセスの流れをフローチャートとして描き比較分析を行いました。

Source: Understanding Proess Behaviours in a Large Insurance Company in Australia: A Case Study, Conference Paper – June 2013

このように2つを並べてみると、例えば、「Simple Slow」(右)の場合、フローチャートの左側にある「Follow Up Requested」において「繰り返し(リワーク)」が大量に発生していることがわかります。

上記以外にも、様々な切り口でプロセスマイニング分析を行い、保険金請求処理プロセスのスループットを長くしているボトルネックを発見し、ボトルネックを解消するための改善施策を計画、実行に移しました。

改善効果は劇的なものでした。従来、保険金請求を受け取ってから保険金支払までのスループットはおよそ30日~60日でしたが、改善後はわずか平均5日へと大幅に短縮。顧客満足度の向上と業務効率化によるコストダウンを実現しています。

プロセスマイニング事例:ABB – 処方的分析の取り組み

supply chain management

Process Mining Case: ABB – Prescriptive Anaytics

ABB(Asea Brown Boveri、アセア・ブラウン・ボベリ)はスイスに本社があり、電力関連、充電、重工業を主事業とするエンジニアリング企業です。従業員数は約11万人、世界100カ国以上に事業展展開しています。

ABBは、プロセスマイニングの早期採用企業のひとつです。2013年に、Celonisによる初めてのPoC(Proof of Concept)をドイツにあるグループ企業にて実施。2018年には、グローバル規模での全社導入を開始しています。

2019年以降は、サプライチェーン全体をデジタル化(デジタルサプライチェーン)して、E2E(End to End)で可視化、さらに、プロセスに潜む問題点の発見だけでなく、どのように改善すべきかを提示してくれる処方的分析(Prescriptive Analysis)のパイロットプログラムを走らせています。

ABBのデジタルサプライチェーンにおけるE2Eとは、原材料等の購買から製造、顧客への販売、納品までをカバーするものです。したがって、このサプライチェーンに関わるシステムはERPだけでも60以上、その他のアプリケーション(SalesForceやオフィスソフトなども含む)は全世界で6000以上という巨大で複雑なものです。

そこで、ABBでは、プロセスマイニングツールをプロセス分析としてだけでなく、多数のシステム、アプリケーションをイベントログデータとして相互接続するためのツールとして活用しています。

こうしてサプライチェーン全体をデータとして統合し、プロセスマイニング分析を行うことで、Gartnerが説く、DTO(Digital Twin of an Organization)の実現を目指し、以下の3つの領域に取り組んでいます。

1 モニタリング:継続的改善

2 モデリング:as isとの適合性、プロセス最適化

3 エグゼキューション:プロセス自動化、リアルタイムアラート(問題指摘、改善提案)


デジタルサプライチェーンに含まれる主なプロセスは以下の通りです。

  • マスターデータ管理
  • 販売プロセス
  • エンジニアリング
  • プロジェクト実行管理
  • サプライチェーン(購買プロセス)
  • 製造
  • 物流
  • 設置・試運転
  • 経理・財務処理

ABBでは上記のプロセスで採用されている様々なシステム(SAP, SFDC, SNOW, MES, PLM等)から抽出したイベントログデータをデータレイク化し、各種IDで接続することでE2Eプロセスのプロセスマイニングに取り組んでおり、主なKPIとしては以下のようなものを設定してダッシュボードを作成しています。

  • スループット
  • リードタイム
  • 在庫回転率
  • コスト
  • 品質

さらに、ABBでは、担当部署ごとの主要目標を設定し、プロセスの問題とその根本原因の発見を踏まえた具体的な改善アクション自動的に作成して、担当者にアラートを送信する手順を確立するパイロットプログラムを走らせています。これが「処方的分析」であり、プロセスマイニングで最も最先端の取り組みだと言えるでしょう。

HFS Top 10 Process Intelligence Products 2020 – プロセスマイニングツールトップ10 (2020)

HFS report on Top 10 Process Intelligence Products

米ITサービス調査会社大手のHFS Researchが、2020年9月、「HFS Top 10 Process Intelligence Products 2020」と題したレポートを発行しました。

HFSでは、40人を超える業界のリーダーたちにインタビューを行い、有望なプロセスインテリジェンス製品として14製品を選出しました。そして、大きくは、「革新(Innovation)」、「実行(Execution)」、「顧客の「声(Voice of the customer)」の3つの切り口で14製品を評価し、ランク付けを行いトップ10を決定しています。

総合評価ランキングは以下の通りです。

1位 Celonis

2位 minit

3位 Fotress IQ

4位 UiPath

5位 KRYON

6位 pafnow

7位 LANA

8位 myInvenio

9位 QPR

10位 ABBYY Timeline

HFSにおける「プロセスインテリジェンス」は、プロセスマイニング、およびタスクマイニングの両方のソリューションを含んでいます。上記トップ10ベンダーのうち、「Fortress IQ」、および「KRYON」は、タスクマイニングソリューションです。

上記プロセスマイニングベンダーのうち、CelonisやmyInvenioは、タスクマイニング機能の拡張を行っています。他のベンダーでも、タスクマイニング機能の拡張を図っているところがあります。

当レポートの詳細はHFSのサイトを参照ください!

→ https://www.hfsresearch.com/research/hfs-top-ten-process-intelligence-products-2020/

ランキング表はこちらから閲覧できます。

5M(ムダ、ムリ、ムラ、モレ、ミス)を特定できるプロセスマイニング

業務改善の視点から

Process Mining can find 5 problems being called, Muda, Muri, Mura, Mo-re, Miss in the target process
English follows Japanese. Before proofread.

TQC(Total Quality Control)に代表される品質管理は、基本的には業務遂行上の様々な課題問題を解決して、改革、改善を目指すものです。特に、工場などの製造現場で積極的に取り組まれてきましたが、物流、サービス、購買、セールスなど、様々な業界、また様々な企業活動への適用も行われています。近年は、TQCや品質管理という言葉はあまり取り上げられなくなりましたが、その考え方や手法は普遍的であり、今でも有効です。

さて、品質管理においては、改善対象となる課題・問題を大きく3つにまとめて、「ダラリ(ムダ、ムラ、ムリ)」、あるいは「3M」と呼びます。さらに、この3つに、「モレ」と「ミス」を追加したものが、「5M(ムダ、ムリ、ムラ、モレ、ミス)」です。

5Mは、イベントログに基づくプロセスマイニング分析にも、もちろん活用可能な枠組みです。むしろ、親しみやすい平易な言葉なので、分析実施が円滑に行える優れた切り口を提供してくれものだと言えます。

そこで、今回は5Mについて概説し、プロセスマイニングの分析方法との関連性をお伝えします。


5Mとは?

まず、5Mのそれぞれについて説明します。

●ムダ

ムダは、英語では「Inefficient(非効率)」と訳せます。

目的達成のための手順が多いため、あるいは複雑であるために処理時間がかかりすぎたり、そもそもやる必要のないことを形式的に続けていたりする業務です。なんらかの価値をあまり、あるいは全く生んでいない活動だと言えます。文字通り「ムダ」なので減らす、省くといった改善が必要となります。


●ムリ

ムリは、英語では「Over-burdened(過剰負荷)」です。

処理しなければならない案件数が非常に多かったり、たとえ案件数がそれほど多くなかったとしても、アサインされているスタッフが少ないために処理待ちの案件がどんどん溢れてしまう。結果として、業務の停滞、滞留が発生します。「ボトルネック」です。案件数と処理能力のバランスがとれておらず、過剰な負荷がかかっている箇所となりますので、流れてくる案件数の平準化や、自動化、スタッフ配置の最適化などの改善施策が実行されなければなりません。

●ムラ

ムラは、英語では「Inconsistent(一貫性欠如)」です。

ムラは、端的には作業手順のバラツキのことです。マニュアルが存在しない、あるいはあっても活用されておらず、個人の裁量に任せている部分が大きいと、手順が人によって違ってきます。結果として、スループット(総所要時間)が長かったり短かったりとバラツキが大きなり、またアウトプットの品質にも差が生じます。

また、基本手順は存在しているものの、現場での事情に応じて例外処理を行った結果、手順が入り組んだ流れになるケースが増えるてしまうと、やはりムラのある業務プロセスということになります。

ムラに対する改善施策としては、基本的には例外処理を減らし、標準化を図ることです。


●モレ

モレは、英語では「Omission(省略)」です。

抜け漏れなどとも言うことがありますが、行うべき手順を意図的に、あるいはうっかり飛ばしてしまったものが「モレ」です。例えば、生産ラインの検査工程において、やるべき検査は4種あるのに、3種だけ行って流してしまうことが慣行となっている場合、モレが発生している問題プロセスです。やるべき検査を一部端折っているわけですから、購入者が利用する際の事故につながったり、リコールを行う事態に発展する可能性があります。

また、コンプライアンスの観点から、やるべき業務が厳密に規定されている業務においては、モレは明確なコンプライアンス違反となります。

モレは基本的にはあってはならない逸脱プロセスですので、確実に実施するような教育・研修を行ったり、そもそもモレが生じないようなシステム的な縛りを与えたり、継続的なモニタリングを行ってアラートを出すといった改善案が検討されます。


●ミス

ミスは、英語で「mistake」です。そもそも、日本語のミスは、この英単語由来の転用語ですね。「Error(エラー)」の意味も含まれます。

ミスは、ヒューマンエラー、つまり業務を担当するスタッフが犯してしまう様々な間違いです。操作手順を入違える、入力値を間違うなど、そのまま放置することはできず、前工程に戻す、あるいは同じ作業を再度やり直すという形での修正が必要となります。

ミスが多くなると、繰り返しというムダな作業が増えるということであり、また手順が増えることでのムリの高まり、ムラの発生につながります。すなわち、ムダ、ムリ、ムラ問題の原因ともなるものが「ミス」ですので、ミスが起きない仕組みづくり、またRPA自動化が有効な改善施策となります。

5m  muda muri mura more miss

プロセスマイニング分析での5M特定

次に、5M、すなわち、ムダ、ムリ、ムラ、モレ、ミスを発見するためにプロセスマイニング分析の多様な分析機能のうち、どれを主に活用すべきかを簡単に説明します。

●ムダを特定する

ムダとは、観察できる発生事象としては、価値を生まない業務を行っていることでした。これは効率・生産性の低下という課題になります。

プロセスマイニング分析では、イベントログデータからas isのプロセスモデル(フローチャート)を作成した後、プロセスを構成するアクティビティのどこでどのくらいの案件が処理され、次工程に流れているかを確認する「頻度分析」をまず行います。処理量が多いところにはムダな手順が潜んでいる可能性があるためです。

次いで、プロセスのバリエーションを比較できる「バリアント分析」によって、無駄なアクティビティを行っていると思われるプロセスパターンを探していきます。また、繰り返しが発生している箇所を発見する「リワーク分析」によって、ムダが発生していないかを探っていきましょう。

●ムリを特定する

ムリは、作業負荷が高い、不適切な手順が行われることで業務が停滞・滞留するという課題を生み出します。したがって、ムリを特定するということは、プロセスにおけるボトルネックがどにあるかを特定することです。

そこで、まず「頻度分析」で処理件数の多い箇所をチェックします。処理件数が多いところは、非効率であるだけでなく、負荷が高いために停滞、滞留が発生しやすいからです。また、「パフォーマンス(時間)分析」では、主に待ち時間(前工程から次工程までの間の時間)の長い箇所を見ていきます。待ち時間が長い箇所はまさにボトルネックです。なお、併せて、対象プロセスの担当者間の業務の受け渡し関係を「ソーシャルネットワーク分析」で把握し、どの担当者間でのボトルネックが発生しやすいかを深堀りしていきます。

●ムラを特定する

ムラは、作業手順が人によって違うことであり、標準化がされていないことで、プロセス品質のバラツキが課題となります。

これは、まず「バリアント分析」で、処理パターンがどのくらいあるかを確認します。パターンが多ければ多いほど様々な手順が行われていることを示しています。また、標準プロセス(to beプロセス)との比較分析を行う「適合性検査」によって、標準から逸脱しているアクティビティにはどのようなものかを明確にしていきます。

改善施策としては、標準化を目指すことになりますのでマニュアルの整備、多用な手順を許さないようなシステム的手当てが有効でしょう。

●モレを特定する

モレは、所定の手続きを一部省略、つまりスキップしているわけですから、標準からの逸脱であり、コンプライアンス違反の課題がある業務プロセスとみなされます。

そこで、標準プロセス(to beプロセス)とイベントログから再現された現状プロセス(as isプロセス)との比較分析、すなわち「適合性検査」を行って、逸脱箇所を把握していくことになります。

改善施策としては、前述しましたが仕組みとして手順の省略ができないようにする、またコンプライアンス研修を行って担当者の意識を高める、といったことが挙げられます。

●ミスを特定する

ミスは、具体的には手順の間違い、ケアレスミス、その他各種エラーの発生であり、結果として、手戻り、繰り返し(リワーク)につながります。

ミスしているかどうかをプロセスマイニング分析で判定することは困難ですので、「頻度分析」、「パフォーマンス(時間)分析」、「リワーク分析「」などを行い、処理件数の多いアクティビティ、処理時間の長いアクテイビティで繰り返しが大量発生していないかを確認し、最終的には、現場担当者へのヒアリングや、タスクマイニングによるタスクレベルでの詳細プロセス把握を通じて、何らかのミスが起きていないかを検証していくことになります。

ミスをゼロにすることは難しいですが、RPAによる自動化を行えば理論上はミスはゼロになります。また、ユーザーインターフェイスが使いにくい、つまりユーザビリティが低いとミスを起こしやすくなりますので、ユーザビリティ改善のためのシステム修正などが求められるでしょう。

5m to process mining analysis

Process Mining can find 5 problems being called, Muda, Muri, Mura, Mo-re, Miss in the target process.

Quality management as typified by Total Quality Control (TQC) is basically about solving various problems in the execution of business operations and aiming for reform and improvement.

In particular, TQC has been actively used in manufacturing plants, but it has also been applied to a variety of industries and corporate activities, including logistics, service, purchasing and sales. In recent years, the terms TQC and quality control have become less common, but the concepts and methods are universal and still valid today.

In the field of quality control, issues and problems to be improved are grouped into three main categories, which are called “darari” (muda, mura, and muri) or “3Ms”. In addition to these three items, More(mo-re) and Miss -Mistake are added to the 3Ms and called “5Ms”

The 5Ms is, of course, a framework that can be used for process mining analysis based on event logs. In fact, it is a familiar and simple term that provides an excellent starting point for smooth analysis implementation.

So, in this article, we will outline the 5Ms and tell you how they relate to process mining analysis methods.


What is 5M?

First, let’s discuss each of the 5M’s.

Muda

Muda can be translated in English as “Inefficient”.

It is a task that takes too long to complete because there are too many steps to accomplish the objective, or because it is too complex, or because it continues to be a formality that does not need to be done in the first place. It is an activity that does not generate much or no value. As these activities are literally “wasteful,” they need to be reduced or eliminated.


Muri

Muri is “over-burdened” in English.

Even if the number of cases to be processed is very high, or even if the number of cases is not so high, the number of cases waiting to be processed is rapidly overflowing due to the low number of staff assigned to the case. The result is stagnation and backlog of business. A “bottleneck. The number of projects and processing capacity are not in balance, and an excessive load is being placed on them.


Mura

Mura is “inconsistent” in English.

Inconsistency is, simply put, Too many variations in work procedures. If manuals don’t exist, or even if they do exist, they are not being used, leaving a large part of the process to the discretion of the individual, the procedure will vary from person to person. As a result, the throughput varies widely and the quality of the output varies.

In addition, although the basic procedure exists, if there are more cases where the flow of the procedure is complicated due to exceptions to the situation in the field, it is also an inconsistent business process.

Basically, the improvement measures for inconsistency are to reduce exception handling and standardize the process.


More(mo-re)

More is “omission” in English.

It means intentionally or inadvertently skipping a procedure that should be done. For example, in the inspection process of a production line, it is a customary practice to perform only three types of inspections and then skip them even though there are four types of inspections to be performed. Since some of the inspections that should be done are cut back, this may lead to accidents when the purchaser uses the product or to a recall.

In addition, from a compliance perspective, omission of a specific activity is a clear violation of compliance in a business where the work to be done is strictly regulated.

Since a deviated process that should not be allowed, you need to consider improvement plans such as providing training and education to ensure that the process is implemented, giving a systematic framework to prevent omission, and issuing alerts through continuous monitoring.


Miss

The word “miss” is “mistake” in English. To begin with, the Japanese word “mistake” is a diversion from this English word. It also includes the meaning of “error”.

A mistake is a human error, that is, a variety of mistakes made by the staff in charge of a task. Mistakes such as entering the wrong operating procedure or inputting the wrong value cannot be left as-is, but must be corrected by returning to the previous process or redoing the same operation.

The more mistakes are made, the more repetitive and wasteful work is required, and the more steps are required, the more “muri” and “mura” are generated. In other words, the cause of waste, wastefulness and unevenness is “mistakes,” so creating a system that prevents mistakes and RPA automation is an effective improvement measure.


Identification of 5Ms in Process Mining Analysis

Next, we will briefly discuss which of the various analytical functions of process mining analysis should be primarily used to identify the 5Ms, i.e., muda, muri, mura, more and miss.

Identify muda

Muda was an observable occurrence event, which was performing work that did not generate value. This is an issue of reduced efficiency and productivity.

In process mining analysis, after creating an as-is process model (flowchart) from the event log data, we first perform a “frequency analysis” to check how many cases are processed and where in the activities that make up the process and how many cases are flowing to the next process. This is because where there is a high volume of processing, there may be wasted steps lurking.

The next step is to look for process patterns that appear to be performing wasteful activities through “variant analysis,” which allows us to compare process variations. In addition, let’s look for wastage by “rework analysis” that discovers repetitions that are occurring.

Identify muri

Unreasonable workloads and improper procedures can create challenges that cause work to stagnate. Therefore, identifying “muri” means identifying the bottleneck in the process.

Therefore, first of all, we check the areas with a large number of processes with “frequency analysis”. This is because the areas with a large number of processes are not only inefficient, but also tend to be stagnant due to a high load. In addition, the “performance (time) analysis” mainly looks at areas with long waiting times (the time between the previous process and the next process). The part with long waiting time is really a bottleneck. At the same time, “social network analysis” is used to understand the business transfer relationships among the participants in the process in question, and a deep dive is made into which participant in the process is most likely to cause a bottleneck.

Identify mura

The mura is that work procedures vary from person to person, and the lack of standardization makes variation in process quality an issue.

This is the first step in a “variant analysis” to see how many processing patterns there are. The more patterns you have, the more you have, the more various procedures are being performed. We also identify which activities are deviating from the standard by means of “conformance checking”, which is a comparative analysis against the standard process (to be process).

As improvement measures, since standardization is the goal, it is effective to prepare manuals and systematic measures that do not allow multiple procedures.

Identify more

Because More omits or skips some of the required procedures, it is considered to be a deviation from the standard and a business process with issues of non-compliance.

Therefore, we need to conduct a comparative analysis of the standard process (to be process) and the current process (as is process) reproduced from the event log, or in other words, a “conformance checking”, to identify the deviation.

As for improvement measures, as mentioned earlier, the system should be structured so that the procedure cannot be omitted, and compliance training should be provided to raise the awareness of the person in charge.

Identify miss

Miss(Mistakes) are specifically wrong procedures, careless mistakes, and various other errors that result in rework.

Since it is difficult to determine whether a mistake has been made or not through process mining analysis, we can check whether a large number of repetitions have occurred in activities with a large number of processes or in activities with long processing times by conducting “frequency analysis,” “performance (time) analysis,” “rework analysis,” etc., and finally, we can conclude that The process is verified to see if any mistakes have occurred through interviews with the people in charge on site and by understanding the detailed process at the task level through task mining.

It is difficult to reduce the number of mistakes to zero, but with RPA automation, theoretically, the number of mistakes can be reduced to zero. In addition, if the user interface is difficult to use, or in other words, if the usability is low, mistakes are more likely to occur, so the system will need to be modified to improve usability.

process mining based on 5m

プロセス発見技法の基礎

The Basics of Process Discovery Methods from BPM point of view.

今回は、BPM(Business Process Management)の視点から、「プロセス発見技法」について包括的な解説を行います。したがって、当記事における「プロセス発見技法」には、プロセスマイニングによる、イベントログに基づくプロセス発見(ABPD: Automated Business Process Discovery)だけでなく、従来の手法も含まれます。

プロセス発見の定義

プロセス発見は、現在のプロセス、すなわち現在の業務手順とそれを遂行する組織体制についての情報を収集し、それを現状プロセスモデル(as is processs model)として描くことです。

ここで、プロセスモデルとは、現実に起きている業務手順を模したものです。粒度粗く、ざっくりと描いたり、できるだけ詳細に描いたり、目的によって再現度合いは異なります。しかし、あくまでリアルな現状に似せたものであるという点をご理解ください。(例えば、戦艦のプラモデルは、実際の戦艦に可能な限り忠実に製造されていますが、縮尺も違いますし、プラモデルとして再現するため、一部省略されている箇所があったりします。)


プロセス発見の課題

プロセス発見に取り組む上で一般に以下の3つの課題があります。これらは、対象とする業務プロセスに関わる人々の認知(ものごとに対する知識や理解、判断のあり方)の制約がもたらすものです。

1 プロセスに対する断片的な知識しか存在しない

現在の企業・組織の業務プロセスの多くは、複数の部署にまたがる長く、複雑なタスクの集合体です。各タスクにはそれぞれなんらかな専門知識やスキル、経験が要求されますし、部署も異なることから、調達プロセスにしろ、受注プロセスにしろ、数十人から、大企業なら数百人が分担してプロセスを回しているのが現実です。

したがってエンド・ツー・エンド(調達プロセスなら、購買要求申請から発注、納品を経て、請求書への支払いが完了するまで)での一連のプロセスを発見するためには、多数の関係者からそれぞれが持つ断片的な情報を集め、組み立てなおす必要があります。


2 現場の担当者は俯瞰的にプロセスを捉えていない

プロセスを構成する様々なタスクを遂行する各担当者は、与えられた役割、責務のなかで日々、業務をこなすことに注力しています。例えば、購買部の担当者は、各部署から上がってくる購買申請を一件一件、内容に不備がないか確認し、不備がなければ次の工程に回し、不備があれば差し戻す、というように、案件単位で業務を行っています。

したがって、現場担当者は、「どのように業務を行っていますか」という質問には簡単に答えることができますが、多くの場合、自分が行っている業務手順がおおよそ何パターンくらいあり、それがどのような条件で分岐していくのか、といった俯瞰的な見方をしたことがないため、漏れなく業務手順を語ることは苦手です。現場担当者が業務を一番理解しているはず、というのは必ずしも真実ではなく、一般化して説明できるほど包括的に理解しているわけではないのです。


3 現場担当者はプロセスモデリングに長けていない

プロセス発見では、「BPMN(Business Process Modeling and Notation)」などの表記法を用いて、業務手順を示したフローチャートを作成するのがゴールです。このフローチャートを作成することを「プロセスモデリング(プロセスマッピングとも言う場合がある)」と呼びます。

プロセスモデリングで描かれたフローチャートはBPMN以外にもいろいろとありますが、比較的素人でも理解しやすいとはいえ、複雑なものになると、ある程度の知識や経験がないと読み解くのが難しくなります。当然ながら、プロセスモデリングの能力を持つのは、プロセスアナリストなどの専門職であり、一般のビジネスパーソンはBPMNの言葉さえ知らない人がほとんどでしょう。

さて、対象プロセスについて現場担当者にヒアリングした後、プロセスアナリストがBPMN形式のプロセスモデルを作成したら、そのプロセスモデルが現状を適切に反映しているかを現場担当者に確認する必要があります。ここで、BPMNに慣れていない現場担当者としては、そもそもプロセスモデルを理解するのに苦労するというわけです。


プロセス発見技法

プロセスモデルを作成する対象となる業務プロセスについての情報を集める方法としては大きくは3つあります。

1 根拠に基づく発見 - Evidence-Based Discovery

ー 書類分析:

対象プロセスのマニュアルや要件定義書などの関連書類から、業務の流れに関わる情報を拾います。

ー 観察調査:

現場担当者が実際に業務を行っているところに立ち会って逐次記録したり(シャドウイング)、動画に収めて後日分析を行います。

ー プロセスマイニング(ABPD: Automated Business Process Discovery):

対象プロセスがERP、CRMなど業務システム上で実行されている場合、当該システムからイベントログ(トランザクションデータ)を抽出し、プロセスマイニングツールにより、自動的にプロセスモデルを作成します。


2 ヒアリングに基づく発見 - Interview-Based Discovery

文字通り、現場担当者に時間を作ってもらい、ヒアリング(英語ではInterviewと呼ぶことが一般的)を行って業務の流れについての情報を収集します。

ここで、前項のプロセス発見の3つの課題をできるだけ克服できるよう、ヒアリングを行うプロセスアナリストは、優れたインタビュースキル、コミュニケーションスキルを有していることが求められます。


3 ワークショップに基づく発見 – Workshop-Based Discovery

ワークショップでは、1対1のヒアリングと異なり、対象プロセスに関与する複数の部署から多くの現場担当者が一堂に会し、付箋紙などを用いながら、その場で業務フローを簡易的に描いていきます。

一連のプロセスの前工程、後工程の各担当者が自分の担当タスクを説明しつつ、前後の担当者と議論をしながらプロセスの流れを明らかにしていくことができるワークショップでは、プロセス発見の3つの課題のうち、断片的な知識を補うことができますし、俯瞰的なプロセス理解もある程度深めることが可能です。

また、ワークショップに担当役員や社長が同席する場合もあります。これは、プロセス改善の取り組みが全社的である場合、会社としての本気度を示し、関係者のモチベーションを高めることに意義があります。

ただし、ワークショップは関係者一同を集め、長時間拘束する必要があることから、日程調整に骨が折れるという問題があります。


各手法の違い

前項の3つのプロセス発見技法の特徴の違いについて見てみましょう。

比較する視点としては、「客観性」、「情報の豊富さ」、「所要時間」、「フィードバックの速さ」の4つです。

comparison three process discovery methods
出所:Fundamentals of Business Process Management

客観性の視点では、エビデンスベース、すなわち関連書類や、観察調査、プロセスマイニングが優れています。ヒアリング、ワークショップは、基本的に現場担当者の「記憶」を引き出しているだけ、ということですから、主観的な要素が大きくなります。

情報の豊富さ、という視点では、現場担当者から詳細な情報を引き出せるヒアリングやワークショップが優れています。

所要時間としては、現場担当者にあまり負担をかけることのないエビデンスベースが優れています。ヒアリングやワークショップは、日程調整が大変ですし、現場担当者にそのための時間を割いてもらわなければなりません。

フィードバックの速さというのは、その場で聞き直したり確認が行えることを意味しています。これはヒアリングやワークショップが当然ながら優れています。

プロセスマイニング活用を前提としたプロセス発見の基本手順

最後に、対象となる業務プロセスがERPなどの業務システム上で大半が実行されており、プロセスマイニング活用が有効である場合のプロセス発見の基本手順を解説します。

1.書類分析

まず、分析対象となる業務プロセスに関する書類(マニュアル、要件定義書など)が存在しているかどうかを確認し、できるだけ多く収集します。もし、書類の中に、標準的な業務手順のフロー図があれば、それは「標準プロセス(to beプロセス)」として、適合性検査に役立てることができます。

2.プロセスマイニング

プロセスマイニングを実行するにあたっては、対象プロセスのイベントログをITシステムから抽出すると同時に、対象プロセスの概要を理解するための基本的な情報、すなわち、おおよその処理件数(月当たり、週当たりなど)、おおよその平均処理時間(スループット、サイクルタイム)、担当部署などについて、最低限ヒアリングする必要があります。「プロセスセットアップ」と呼ばれる作業ですが、これはおおむね短時間で済みます。

3.ワークショップ

プロセスマイニングによって自動的に再現されたプロセスフローチャートを検証し、特定された非効率な箇所、ボトルネックなどの原因を探るために、関係者を集めてワークショップを開催することが効果的です。

プロセスマイニング活用を含むプロセス発見においては、ワークショップの場はプロセスを発見するだけでなく、問題の根本原因を追及していく機会にもなります。

4.ヒアリング

ワークショップの開催が難しい場合、対象プロセスに関わる現場担当者のうち、キーパーソンや、また非効率な箇所、ボトルネックに関与している担当者と個別ヒアリングの場を設定することも有効です。

留意していただきたいのは、ここでもプロセスを発見することではなく、特定された問題の根本原因を明らかにすることに重点が置かれること、また個人の責任を問うたり責める場ではないことです。


以上の流れはあくまで標準的なものであり、プロジェクトの期間や予算、体制などを考慮して柔軟な進め方を行いましょう。

なお、プロセス発見の詳細解説は、以下の参考図書をお読みください。

『Fundamentals of Business Process Management』(Marlon DUまs、Marcello La Rosa, Jan Mendling, Hajo A. Reijers, Springer)

モビリティデータによるカスタマージャーニーマイニング時代の到来

Real Customer Journey Mining – Process Mining applied to mobility data.

現在、プロセスマイニングの主な対象は、調達や受注など社内業務のプロセス。ERPなどの業務プロセスから生データを抽出し、業務プロセス(フロー)を見える化することで、ボトルネックや逸脱などの改善ポイントを特定します。


一方、マーケティングに有効と思われる顧客行動のプロセスマイニング=「カスタマージャーニーマイニング」は、Webサイトのアクセスログを分析対象とした「オンライン・カスタマージャーニー」の事例は増えつつありますが、リアル・カスタマージャーニーの分析例はほとんど存在しません。

しかし、人々が常にスマホを存在し、移動時の交通機関などの利用時にアプリを活用するようになったことで、モビリティデータが生成されるようになりました。結果、リアルな顧客行動データに対するプロセスマイニングが可能になりつつあります。


具体的には、東京や、京都における観光客の周遊状況(どんな観光施設をどんな交通手段で巡っているか)など、観光施策に役立つ顧客行動分析がファクトに基づいて行うことができるでしょう。文字通りの「カスタマージャーニーマイニング」です。

業務プロセスの分析と同様、複数のアプリからのデータの抽出、統合が必要であり、セキュリティ、プライバシーの問題もクリアしなければなりませんが、プロセスマイニング分析の対象として今後、非常に魅力的な分野になることでしょう。

mobility data process mining
Source: Mobility as a Service

詳しくはこちらでご確認ください>> https://mobility-as-a-service.blog/

業務プロセス改善サイクルは、プロセスマイニングでどれだけ短縮できるのか?

process improvement cycle comparison

Business process improvement cycle can be shortened by process mining.

今回は、業務プロセス改善サイクルに必要な時間は、従来の手法(現場ヒアリングや観察調査など)と比較して、プロセスマイニングではどの程度短縮できるかについて考察します。

業務プロセス改善は、大きくは以下の3つの段階に分けることができます。

・プロセス可視化のための作業(データ収集からプロセスフロチャート作成まで)

・分析作業(問題抽出)

・改善作業(改善施策の検討から成果検証まで)

下図は従来手法とプロセスマイニングのそれぞれについて、上記各段階の所要時間をイメージとして示したものです。(実際の所要時間はケースバイケースですが、平均的にはおおよそ下図の長さになります。

process improvement cycle comparison

まず留意いただきたい点は、改善作業は、従来手法もプロセスマイニングも所要時間は同じということです。

改善作業においては、リーン、シックスシグマ、制約理論などの手法を用いて、分析により抽出された問題(非効率やボトルネックなど)の根本原因の解明を行い、具体的な改善方法を検討し、改善計画を策定、現場に展開。後日、改善が成果を収めているかを検証するまでが含まれます。この作業について、従来手法、プロセスマイニングのどちらも大きくは変わりません。(ただし、継続的モニタリングはプロセスマイニングでないと現実には行えませんが)

プロセスマイニングによって劇的な時間短縮効果があるのは、プロセス可視化のための作業です。

プロセスマイニングでは、まず、ITシステムからイベントログ抽出を行いますが、これは基本的に短期間で完了する作業です。また、抽出されたデータをクリーニングし、プロセスマイニングで分析できるフォーマットに変換する作業は複雑であり、相応の期間を要するものの1カ月以上っかることは稀です。さらに、プロセスの流れを描いたフローチャートの作成は、プロセスマイニングツールにイベントログデータをアップロードすれば自動で作成されます。

したがって、従来手法では依然、現場でのヒアリングや観察を行ってデータ収集を行っている期間中に、プロセスマイニングでは可視化が完了し、分析作業をスタートすることができます。

一方、従来手法では、データ収集のための現場ヒアリングや観察調査に多大な時間が必要なことに加えて、それをとりまとめるデータ整理も楽ではありません。しかも、フローチャートはモデリングツールを活用して手作業で作成しなければなりません。

従来手法でようやくプロセス可視化のための作業が完了した時には、プロセスマイニングを活用したプロジェクトではとっくにプロセス改善施策の現場展開が始まっているのです。

分析作業段階においても、プロセスマイニングツールのほうが、様々な視点で深堀り分析を行うことができ、スピーディに問題抽出が可能です。

結果として、業務プロセス改善サイクルを一回しする期間は、従来手法と比べてプロセスマイニング活用の場合は約2/3に短縮できます。(プロセス可視化作業の期間だけでは1/2以下)

外部環境が急激に変化する今、業務プロセス改善サイクルはできるだけ短縮化し、すばやく回し続けることが求められています。業務プロセス活動にプロセスマイニングを採用すれば、サイクルタイム時間の大幅短縮を成し遂げることが可能です。

プロセスマイニング入門(17)プロセスマイニングの将来展望

application area by value chain

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などのプロジェクト管理ツールが用いられることが多いため、適切なプロジェクト運営が行われているかという視点でのプロセスマイニングは有効かもしれません。

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

application area by value chain

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

すでに活用実績が積み重なりつつあるのが、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

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

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

evolution of process mining

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

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

プロセスマイニング入門(16)プロセスマイニングツール

Introduction to Process Mining (16)Process Mining Tools

今回は、「プロセスマイニングツール」について詳しく解説します。

プロセスマイニングツール - グローバル

現在、世界にはどんなプロセスマイニングツールがあるのか概観してみましょう。

2019年の時点で、大小合わせて30以上のプロセスマイニングツールが世界には存在していると言われています。 米ITアドバイザリ企業Gartnerが2019年6月に発表した、『Gartner, Market Guide for Process Mining, Marc Kerremans, 17 Jun 2019』においては、代表的なベンダー・ツールが19種類挙げられています。

  • Apromore – Apromore
  • Celonis – Celonis Process Mining
  • Cognitive Technology – myInvenio
  • Everflow – Everflow
  • Fluxicon – Disco
  • INTEGRIS Explora
  • Lana Labs – LANA Process Mining – Magellanic
  • Logpickr – Logpickr Process Explorer 360
  • Mehrwerk AG – MEHERWERK ProcessMining (MPM)
  • Minit – Minit
  • Process Anaytics Factory – PAFnow
  • Process Mining Groups at TUE and RWTH – ProM, ProM Lite, RapidProm M, PM4Py
  • Process Gold – ProcessGold *現在はUiPath Process Mining
  • Puzzle Data – ProDiscovery
  • QPR Software – QPR ProcesAnalyzer
  • Signavio – Signavio Process Intelligence
  • Software AG – ARIS Process Mining
  • StereoLOGIC – StereoLogic Process Analysis
  • TimelinePI – Process Intelligence Platform *現在はABBYY Timeline

プロセスマイニングはまだ新しい市場であるため、ベンダー各社のライセンス販売本数や売上もほとんどが非公開、調査会社による市場シェア等は当てになりません。とはいえ、Celonisが市場リーダーであることは間違いなく、2番手にCognitive Technology、さらにABBYY Timeline、Uipath Process Mining、 Minit、Signavioなどが続いている状況だと推測しています。

ユニークな存在としては、オープンソースのApromoreが挙げられます。同じくオープンソースのProMは主に学術的研究に利用されているのに対し、Apromoreは企業での活用も増えており、大規模ユーザーへの有償版の提供も始まっています。


Process Mining Products PEAK Matrix(R) Asessment 2020

ダラスに本社を置くコンサルティング&調査会社のEverest Groupは、2020年2月26日、主要なプロセスマイニングベンダー13社について、以下の2つの軸での市場ポジショニング(山脈に見立てているので「PEAK Matrix」)を発表しています。

横軸:Vision & Ability – Measures ability to deliver products successfully
製品開発ビジョンを示し、それに沿った製品を成功裡に提供できる能力

縦軸:Market Impact – Measures impact created in the market
市場に与えるインパクトの強さ

PEAK Matrixでは、競合製品をLeaders(リーダー)、Major Contenders(主要な競争相手)、Aspirant(上を狙う野望を持つ製品)の3つにカテゴライズします。Process Mining市場では、それぞれのカテゴリーに含まれる製品は次の通りです。

Leaders

  • Celonis
  • Software AG
  • UiPath(旧ProcessGold)

Major Contenders

  • ABBY Timeline
  • Apromore
  • LANA Labs
  • Logpickr
  • Minit
  • myInvenio
  • PAF now
  • QPR Software

Aspirants

  • Everflow
  • Puzzle Data

市場リーダーのCelonisは既に社員数900人を抱え、大型の資金調達にも成功して「ユニコーン」としても認められる存在。そして、リーダーグループの一角を占めるSoftware AGは、「ARIS」のブランドで知られ、「ARIS Process Mining」の販売にも力を入れてきています。Uipath社は、買収したProcessGoldを「UiPath Process Mining」に名称を変え、UiPathが強みを持つRPAを含むトータルソリューションとして提案力を強化しています。

process mining technology vendor landscape with products PEAK Matrix(R) Assessment 2020
process mining technology vendor landscape with products PEAK Matrix(R) Assessment 2020
Everest Group

プロセスマイニングツール - 日本

2020年8月時点で、日本において活用可能な主要プロセスマイニングツールをご紹介します。

留意していただきたいことがあります。「ツールを活用する」ということだけであれば、日本に拠点や代理店がなかったとしても、直接ベンダーに連絡すればライセンス購入可能です。しかし、プロセスマイニングツールは高度で複雑なツールです。「ちょっとお試し」、だったとしても残念ながら、そう簡単には使いこなせません。

そもそも、業務プロセス改善を目的とする「プロセスマイニングソリューション」の観点からは、ツールの操作方法の最低限のトレーニングに加え、データ前処理、分析結果の解釈など、専門性の高い人材が不可欠です。

多くの企業では、自前の人材だけでプロセスマイニングを導入して成果を出すことは難しいと思いますので、日本企業に対して、ツール操作トレーニング、データ前処理支援などのプロフェッショナルサービスを併せて提供してくれる代理店なりコンサルティング会社の存在がある主要なツールのみをここではご紹介します。


セロニス(Celonis)

大手コンサルティング会社を始め、多くのパートナー企業と共にプロセスマイニング導入・運用の関連サービスを提供。

→ Celonis 日本

マイインベニオ(myInvenio) 

独占販売契約を結んでいるハートコアがライセンス販売に加え、トレーニングをはじめ、各種プロフェショナルサービスを提供。

→ ハートコア株式会社(日本総代理店)

シグナビオ(Signavio)

イントラマート社が、Signavio Process Miningを活用した「DXアプローチメソッド」を提供。

→ 株式会社NTTデータ イントラマート(パートナー契約)

アビー・タイムライン(ABBYY Timeline)

OCR製品で知られるABBYY社が、TimelinePI社を買収して提供開始したプロセスマイニングツール。

→ ABBYY 日本

UiPathプロセスマイニング(Uipath Process Mining)

RPA大手、UiPath社が旧Process Gold社を買収して自社ソリューションラインナップに追加。

→ Uipath 日本

ラナ・プロセスマイニング(LANA Process Mining) 

リグリット・パートナーズが、ラナ・プロセスマイニングを活用した「オペレーションアセスメントサービス」を提供。

→ 株式会社リグリット・パートナーズ(パートナー契約)

プロセスマイニング入門(15)プロセスマイニングプロジェクトの進め方

project team

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

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

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

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


スコーピング

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

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

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


データの理解

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

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

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

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

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


イベントログ作成

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

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


プロセスマイニング(分析)

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

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

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

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

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

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


評価(解釈)

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

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

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

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


運用

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

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

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

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

process mining project lffecycle

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

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

プロセスオーナー

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

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

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

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

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

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

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

IT管理者

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

データサイエンティスト

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

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

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

プロセスアナリスト

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

プロセスコンサルタント

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

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

project team

プロセスマイニング入門(14)活用事例

hspi_case_distribution_2005-2019

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件を大きく超えていると思われます。

hspi_case_distribution_2005-2019
年別プロセスマイニングプロジェクト数(2005-2019) 出所:HSPI

産業別プロジェクト件数

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

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

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

case_compositon_by_industry_2005-2019
産業別プロジェクト構成比2005-2019 (出所)HSPI

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

地域・国別のプロジェクトの構成比については簡潔に触れるに留めます。プロセスマイニング発祥の地、欧州が最も多く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人以上です。


1 ローンの申し込み(Loan Application) – ユーザー

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

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

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

3 書類確認(Loan Validation) – 顧客確認チーム

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

4 ローン審査(Credit Approval)- ローン審査チーム

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

5 ローン契約(Contract)

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


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


1 品質(Quality)

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

2 迅速性(Timeliness)

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

3 受け入れ能力と生産性(Capacity and Productivity)

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

4 費用と利益(Cost and Benefits)

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

5 顧客・従業員満足(Satisfaction)

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


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

そして、具体的な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)」と呼んでいます。自動車や航空機、建築物などの設計においては、風洞に模型を置いて風の流れ等を測定する「風洞実験」を行います。同様に、プロセスの改善にあたって、シミュレーションによる改善成果の予測を行った上で改善施策に展開するという手順を踏んでいるのです。

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

1 データ収集(Data Collection)

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

2 現状分析(Current State Analysis)

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

3 未来状態設計(Future Sate Design)

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

4 実行

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

今回紹介された取り組み例はサービス業務です。これは、お客様から届く、月間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などのツールを用いてプロセス改善プロジェクトを推進しました。

プロセスマイニング入門(13)運用サポート

Introduction to Process Mining (13)Operational Support

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

運用サポート - Operational Support

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

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

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

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

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

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

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

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

プロセスマイニング入門(12)プロセス強化

process enhancement

Introduction to Process Mining (12)Process Enhancement

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

プロセス強化 - Process Enhancement

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

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

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

process enhancement

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

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

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

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

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

プロセスマイニング入門(11)適合性検査

Introduction to Process Mining (11)Conformance Checking

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

適合性検査 - Conformance Checking

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

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

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

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

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

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

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

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

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

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

conformance checking

逸脱の2つのパターン

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

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

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

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

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

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

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

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

to beプロセスの設定

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

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

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

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

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

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

プロセスマイニング入門(10)プロセス発見

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が最後のアクティビティとして記録されていたりしたためです。(簡略化したサンプルのため他のアクティビティへの移行は示されていません)

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

process discovery frequency analysis

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

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

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

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

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

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

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

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

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

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

process discovery performance analysis

バリアント分析  – Variant Analysis

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

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

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

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

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

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

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

プロセスマイニング入門(9)4つの基本アプローチ

Introduction to Process Mining (8)Four Basic Approaches

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

1 プロセス発見 - Process Discovery

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

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

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

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

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

2 適合性検査 - Conformance Checking

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

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

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

3 プロセス強化 - Process Enhancement

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

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

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

4 運用サポート - Operational Support

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

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

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

four basic approaches

継続的プロセス改善のための特任組織、「COE(Center of Excellence)」とは?

Position and Role of COE – Center of Excellence for Continuous Process Improvement
English follows Japanese. Before proofread.

今回は、継続的プロセス改善を目的としたDXの推進、デジタルツインの実現を主導する特任組織ともいえる「COE(Center of Excellence)、以降COE」の位置づけや役割について解説します。

COEに対応する日本語の適切な表現はありません。そのまま「COE」と呼ばれています。欧米ではCOEを設立する企業が増えています。日本企業でもCOEが設立されているところがありますが、部署としての役割は同じでも、名称としては「DX推進部」「BPR(Business Process Re-engineering)部」といった名称になっていることが多いようです。

【DX、デジタルツインとは?】

さて、「DX(Digital Transformation)」は、テクノロジーを活用して自社ビジネスモデルを大きく変換することに主眼が置かれています。

単に、今までアナログ的にやっていた業務をデジタルツールに置き換えることではありません。テクノロジーをてこにして、事業構造、組織構造を大きく転換し、デジタルによって大きく変化しつつある社会経済環境への適応を図ろうとするものです。

また、デジタルツイン、正確には「DTO(Digital Twin of an Organization)」は、実際の業務をそのままバーチャルなモデル(=デジタルツイン)としてPCディスプレイ上に再現することで、業務プロセス上の様々な問題点を発見しやすくしたり、また日々の業務における問題発生をリアルタイムにモニタリングし、即時の是正を図ろうとするものです。

【COEの位置づけ・役割】

近年、社会経済のあらゆる側面、また企業活動のあらゆる側面においてデジタル化が進む中、旧態依然とした仕事のやり方ではもはや生き残ることはできません。企業全体のDXを推し進め、DTOによる継続的プロセス改善を行う必要があります。

ここで、DXの推進、DTO実現を主導するのが、社内の特任部隊である「COE」です。

COEは、調達、製造、物流、販売、マーケティング、サービス、経理・財務などの現業部門とIT部門の中間に位置づけられ、両者がうまく連携できるように様々な調整を行います。

COEは、最先端のテクノロジー、ツールを現業部門のユーザーが最大限に活用し、成果を出せるように様々な形で支援を行います。一方、IT部門に対しては、現業部門のニーズを吸い上げ、それをシステムの開発、改修のための要求仕様に的確に転換してIT部門を支援します。

【COEのキーメンバー】

テクノロジー活用が前提となるDX推進のためのCOEは、データドリブン、すなわち業務に関わる様々なデータを収集・分析することによって問題点を発見し、是正します。したがって、DXプロジェクトを現業部門と共に立ち上げ、COEに所属する以下のようなエキスパートをプロジェクトメンバーとして任命します。なお、彼らは必要に応じて現業部門の各種DXプロジェクトにも支援メンバーとして参画します。

・ビジネスアナリスト

 ビジネスとITの両方の知識を有し、ITによる業務プロセス改善施策の展開を企画、指揮します。改善施策出しのためのツールとして、BA、BPM、Lean、Six Sigma、PMC(Process Model Canvas)などを使いこなします。

・プロセスアナリスト

 プロセスマイニング、タスクマイニングツールを使い、データ分析に基づく問題点の発見、根本原因分析を行い、改善施策に結び付く示唆(インサイト)を提示します。

・データサイエンティスト

 IT部門のエンジニアと連携しながら、ITシステムからの分析対象データの抽出やデータクリーニングなどのデータ前処理作業を担当します。

center of excellence for process improvement

【DX推進、デジタルツイン実現の主要ツール】

現状を把握し、問題点を特定し、根本原因分析を行って改善施策を打ち出す、あるいは新たな業務プロセスを設計するためには様々な知識体系・ツールを活用しなければなりません。

代表的なものとしては以下が挙げられます。

BA(Business Analysis)

BPM(Business Process Management)

Lean Management

Six Sigma

PMC(Process Model Canvas)

前述したようにこうしたツールはビジネスアナリストが身に付けておくべきものです。

また、改善のためのITツール、テクノロジーとしては以下のようなものがあります。

・AI(人工知能)

・BPMS(Business Process Management System)

・Process Mining

・Task Miining

・RPA

COEのメンバーは、これらのテクノロジーやツールについて知識を深めるともに、技術の進展が早いため、常に最新動向をウオッチしておくことが求められます。


Position and Role of COE – Center of Excellence for Continuous Process Improvement

This article explains the role and position of the Center of Excellence (COE), which can be regarded as a specially designated organization that promotes DX for the purpose of continuous process improvement and leads the realization of digital twin.

In Europe and the United States, an increasing number of companies have established a COE. Some Japanese companies have also established a COE, and although the role of the department is the same, it is often called “DX Promotion Department” or “BPR (Business Process Re-engineering) Department”.

What is DX and Digital Twin?

“Digital Transformation” (DX) is primarily focused on using technology to significantly transform your business model.

It doesn’t mean simply replacing analog operations with digital tools. It is about leveraging technology to transform the business and organizational structures and adapt to the socio-economic environment that is changing dramatically due to digital technology.

The digital twin, or more precisely, the Digital Twin of an Organization (DTO), reproduces actual business operations as a virtual model (i.e., digital twin) on a PC display, making it easier to discover various problems in business processes and also to identify problems in the daily The purpose of the COE is to monitor the occurrence of problems in the company’s operations in real time and attempt to take immediate corrective action.

The role of the COE

In recent years, as every aspect of the socio-economy and every aspect of business activity has become more digital, the old ways of working can no longer survive. We need to push forward with enterprise-wide DX and continuous process improvement through DTO.

The COE, a specially designated unit within the company, leads the way in promoting DX and DTO implementation.

The COE is positioned between the IT department and the business units such as procurement, manufacturing, logistics, sales, marketing, service, and accounting and finance, and coordinates a variety of activities to ensure that the two departments work well together.

The COE helps the incumbent get the most out of the latest technologies and tools so that they can deliver results. On the other hand, the COE supports the IT department by absorbing the needs of the business units and translating them into the required specifications for the development and improvement of the system.

Key Members of the COE

The COE for the promotion of DX, which is based on the use of technology, is data-driven, i.e., it discovers and corrects problems through the collection and analysis of various data related to the business. Therefore, a DX project is launched together with the business units, and the following experts belonging to the COE are appointed as project members. The following experts belonging to the COE are appointed as project members, and they will also participate in various DX projects of the operational divisions as necessary.

Business Analyst

 Knowledge of both business and IT, and plans and directs the deployment of business process improvement measures using IT. Proficient in BA, BPM, Lean, Six Sigma, PMC (Process Model Canvas), etc. as tools for implementing improvement measures.

Process Analyst

 Using process and task mining tools, we discover problems based on data analysis, perform root cause analysis, and present insights that lead to improvement measures.

Data Scientist

 The successful candidate will be responsible for data pre-processing tasks such as data extraction and data cleaning from the IT system in collaboration with the IT department engineers.

center of excellence for process improvement

TOOLBOX

Various knowledge systems and tools must be used to understand the current situation, identify problems, analyze the root cause, and come up with improvement measures or design new business processes.

Typical examples are as follows;

BA(Business Analysis)

BPM (Business Process Management)

Lean Management

Six Sigma

PMC (Process Model Canvas)

As mentioned above, these tools are something business analysts should be equipped with.

In addition, IT tools and technologies for improvement include the following.

Artificial Intelligence (AI)

BPMS (Business Process Management System)

Process Mining

Task Miining

RPA

The members of the COE are expected to deepen their knowledge of these technologies and tools, and also to keep up with the latest developments in the fast-moving technologies.

プロセスマイニング入門(8)プロセスマイニングのアルゴリズム

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項目があればいいのですが、初めてプロセスマイニングを知った方は、どうやってフローチャートを描くのか不思議に思われるようです。もちろん、裏には、一定の処理ロジック、すなわち「アルゴリズム」が存在します。

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

process discovery

プロセスモデル(フローチャート)の再現

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

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

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

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

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

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

出所:Fluxion

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

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

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

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

シンプルですね。

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

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

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

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

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

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

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


アルゴリズムの種類

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

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

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

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

・スプリットマイナー

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

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

プロセスマイニング入門(7)イベントログとは?

event log table sample

Introduction to Process Mining (7) What is Event Log?

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

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

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

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

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

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

eventlog sample table

【必須項目】

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

・案件ID(CaseID)

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

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

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

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

・活動(アクティビティ)

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

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

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

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

・時刻(Timestamp)

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

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

【属性項目】

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

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

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

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


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

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

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

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

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

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

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

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

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

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

deta preparation overview