BPMSとは？ビジネスプロセスマネジメントをわかりやすく解説

BPMS（ビジネスプロセスマネジメントシステム）は、定義したプロセスをモデル化して実行し、その進捗を監視するソフトウェアです。手順に沿った業務の実行やタスクの割り当て、実行記録の管理を得意とします。一方で、実行・報告できるのはBPMSに任された業務に限られるため、業務全体を把握するには不向きです。

このガイドでは、BPMSの機能、導入することになる5つの構成要素、対応範囲を解説します。さらに、実行ソフトウェアとプロセスインテリジェンスを比較します。プロセスインテリジェンスは、実行をすでに得意とする複数のシステムに任せ、そのデータを人やAIが利用できる1か所につなぎます。

BPMSの意味

BPMSはBusiness Process Management Systemの略です。ベンダーによってはBusiness Process Management Suiteを指す場合もあります。いずれも、プロセスを定義し、業務をその流れに沿って振り分け、実行を監視するソフトウェアを指します。

BPM（ビジネスプロセスマネジメント）は、業務の流れを把握、設計、測定、改善する取り組みです。BPMSは、その取り組みを支援するソフトウェアの1つです。BPMSを購入せずにBPMに取り組むこともできます。また、BPMSを購入しただけで、プロセスを適切に管理できるとは限りません。

BPMSのカテゴリーは時代とともに変化してきました。ワークフローエンジンから始まり、モデリング、フォーム、監視機能を加えたスイートへと広がり、現在はチームがプロセスアプリケーション全体を組み立てるローコードプラットフォームも含まれます。そのため、ベンダーによってBPMSの説明が異なります。ビジネスプロセスマネジメントソフトウェアを評価する際は、名称ではなく、重要な4つの点を確認してください。プロセスのモデル化、実行、関連システムとの連携、実行中の状況確認ができるかどうかです。

BPMSを構成する5つの要素

製品によって機能のまとめ方は異なりますが、ビジネスプロセスマネジメントシステムは通常、次の5つの要素で構成されます。

1. モデラープロセスを定義します。BPMN 2.0がよく使われます。モデルには業務の流れを記述でき、実行可能なシステムでは実行の基礎にもなります。プロセスモデルの設計については、BPMNモデラーをご覧ください。
2. 実行エンジンプロセスの事例を作成し、条件を評価してタスクを割り当て、タイマーを開始し、期限を過ぎた業務をエスカレーションします。
3. フォーム、ルール、ロール入力する情報、表示するタスク、次の手順に適用するルールを定めます。
4. 連携ERPやCRM、データウェアハウス、APIゲートウェイなどのアプリケーションとデータをやり取りします。連携作業が導入プロジェクトの大きな部分を占める場合があります。
5. 監視とリポジトリダッシュボードで実行中の事例の状況を確認できます。リポジトリではプロセスのバージョンを管理し、変更を制御できます。

ワークフローエンジンは、全体を構成する要素の1つです。BPMSはエンジンに加えて、より広いプロセスの定義、支援、監視に必要なツールや管理機能を備えています。

プロセス文書だけではできないBPMSの機能

プロセス文書には、業務をどのように進めるべきかが記されています。BPMSは、設定されたルールに従って業務を振り分け、進捗を追跡できます。たとえば、次のことができます。

• 一定期間待機しているタスクをエスカレーションする。
• 設定したしきい値に達した事例を承認に回す。
• 事例ごとにたどった経路を記録する。
• 周辺の複数のアプリケーションを変更せず、設定を通じてフローを更新する。

こうした機能は、業務の振り分けを統一し、オーナーを明確にして、システムが実行する事例の状況を把握したい場合に役立ちます。ただし、実際のプロセスのすべてがBPMS内で行われるとは限りません。主な目的がプロセスの文書化や現状把握であれば、実行ソフトウェアを最初に導入するのが適切とは限りません。

BPMS、ワークフローエンジン、RPA、プロセスマイニング、プロセスインテリジェンスの違い

これら5つの技術は、プロセス管理の異なる部分に対応します。次の表では、それぞれの機能と、答えを得るのに役立つ問いを示します。

RPAとBPMSでは、プロセス変更への対応が異なります。RPAは既存プロセスのタスクを自動化します。BPMSは定義したプロセスを実行するため、業務の振り分け方が変わる場合があります。タスクを自動化する前に、プロセスを見直してそのタスク自体をなくせないか確認しましょう。詳しくは、プロセスマイニングで自動化の機会を見つけるをご覧ください。

プロセスマイニングとBPMSでは、答えられる問いも異なります。プロセスマイニングはイベントデータを分析し、システムを通じた実際の業務の流れを示します。BPMSは設計したフローを実行し、処理した事例を報告します。モデルが実際の業務と一致しているか確認する際に、この違いが重要になります。

表の最後にあるプロセスインテリジェンスは、ほかの技術をつなぐ役割を担います。実行は最適なシステムに任せ、各システムの記録を読み取り、それらの基準となるプロセスモデルを1つにまとめます。BPMSが報告するのは自らが処理した事例です。一方、プロセスインテリジェンスは、単一のプラットフォームでは実行されない業務も含めて、プロセス全体を把握します。

1つのBPMSですべてのプロセスを実行できない理由

BPMSはプロセス管理の解決策に見えますが、管理対象外のシステムを数えると限界が分かります。実際のプロセスは、ERP、CRM、チケット管理ツール、サプライヤーポータル、スプレッドシート、複数のメール受信トレイをまたいで進みます。プラットフォームが実行するのは、その中でモデル化した部分です。残りの業務は、ほかの場所で続きます。

導入前に知っておきたい影響が3つあります。

標準を再利用せず、独自のワークフローを作ることになるBPMSはツールキットであるため、プロセスごとにプロジェクトが必要になります。独自のバリアントをモデル化し、手順に名前を付け、他の何千もの組織が実行しているものと同じフローを独自に保守します。受注から入金まで、調達から支払いまで、インシデント管理などの業界標準の参照モデルも、再利用されずに各プラットフォームで作り直されます。その結果、同じシステムを使う2つの部門が、同じプロセスの異なるバージョンを持つこともあります。

実行を優先するプラットフォームでは全体像が見えにくくなるBPMSは実行する業務で評価されるため、プラットフォーム内のフローに注意や予算が集まります。チームやシステム、国をまたぐなど、BPMSが実行しないプロセスは、オーナーがいないままになりがちです。実行を速めることと、組織全体の業務を理解することは別です。

**BPMSには必ず限界があり、例外が増えるほど独自の例外処理も増えていきます。**どのプロセスにも例外はあります。緊急の注文、重要顧客への対応、メールでの連絡しか受け付けないサプライヤーなどです。BPMSでは、例外が発生するたびに設定済みの分岐やフォーム、連携、保守が必要なワークフローが増えていきます。業務の標準化を目指して導入したプラットフォームが、やがて担当チームにしか理解できない個別対応で埋まってしまいます。

だからといって、BPMSが役に立たないわけではありません。ただ、プロセスに関する信頼できる唯一の情報源としては適していないということです。

この課題が特に顕著なのが、ITに関わる業務プロセス管理です。1つの業務がチケットのキューや変更カレンダー、複数のアプリケーションにまたがる一方、すべてを把握できる業務プロセスソフトウェアはありません。

ほとんど使っていないBPMSを使い続けるべきでしょうか？

実行エンジンを目的にBPMSを導入したものの、結局使わなかった組織は少なくありません。導入には予定以上の時間がかかり、最初のフローはパートナー企業が設定しました。その間も、現場は従来のシステムで業務を続けていました。残ったのは、図を描くために一部の担当者だけが開くライセンス済みのモデリングツールと、誰も起動しない実行環境の保守費用です。

この段階で、プラットフォームにまとめられていた2つの役割を切り分ける必要があります。ワークフローエンジンは業務を実行するためのもので、モデルリポジトリはプロセスの知識を蓄積するためのものでした。後者しか使っていないのであれば、文書化のために実行プラットフォームの費用を払い続けていることになります。文書化の手段としては、重く、技術的で、費用もかかります。

こうした状況が当てはまるなら、実行プラットフォームに、本来想定されていなかった知識管理の役割まで求めていることになります。必要なのは実行環境を増やすことではありません。知識の管理を目的としたツールに移すことです。すべてのプロセスを1か所に集め、各システムのデータとつなぎ、必要とする人やAIアシスタントが読めるようにします。実行環境の運用も必要ありません。

実際に業務を実行しているプロセスには、BPMSを使い続けてください。プロセスの知識は、リリースサイクルに左右されずに更新できる場所に移しましょう。

プロセスインテリジェンスとBPMSの違い

実行機能を備えていないのは、機能の不足ではなく意図的な設計です。実行を担う手段は数多くあり、すでに導入しているプラットフォームが最適とは限りません。RPA、AIエージェント、ワークフロー管理システム、ERP独自のワークフロー、そして人が手作業で進める方法。それぞれに適した場面があります。業務を実行するツールは、その役割に合わせて選ぶべきです。

一方、5つのシステムに分散させてはならないのが、プロセスの知識です。実行を担うシステムごとにプロセスの図が異なれば、プロセスの実態や、顧客が実際にたどった経路、次に自動化すべき手順を誰も把握できません。業務を担う人にも、業務に使われ始めているAIアシスタントにも役立つよう、プロセスの知識を一元化することは、業務を実行する仕組みを持つことより重要です。

ここにデータを一元化する利点があります。BPMSが報告できるのは、その内部で処理した案件だけです。プロセスインテリジェンスプラットフォームなら、すべてのシステムのイベントデータをつなぎ、BPMSでは把握できなかった業務も含めて全体像を示せます。さらに、BPMSやERP、自動化ツールの実績を測る基準となるモデルを1つにまとめられます。

モデルを実態に合わせるために、なぜプロセスマイニングが必要なのでしょうか？

BPMSは、内部で実行された案件について報告できます。しかし、プロセスを完了するために人がたどるすべての経路を把握できるとは限りません。よくある抜け漏れは次の3つです。

• **実行エンジンの外で業務が行われる。**担当者が例外対応をメールで進め、後からシステムを更新することがあります。実際にはモデルの想定より時間がかかっていても、案件の記録上はコンプライアンスを満たしているように見える場合があります。
• **別のシステムを使って同じ結果にたどり着く。**チームがERPやスプレッドシート、サプライヤーポータルを使うことがあります。そうした業務がBPMSに記録されなければ、ダッシュボードにプロセス全体は表示されません。
• **モデルが実態に追いつかなくなる。**公開時点では正確だったプロセスも、チームごとのやり方が定着するにつれて実態とずれていくことがあります。モデルの更新に時間がかかると、こうした違いがそのまま残りかねません。

その結果、適切に管理されていても、実際の業務を反映しなくなったモデルが残ります。プロセスマイニングを使えば、システムがすでに記録しているイベントデータを読み取り、モデル化されていない経路も含めて、実際にたどられた経路を再構成できます。

適合性チェックでは、プロセスモデルとイベントデータを比較し、実行内容と設計の違いを明らかにします。一方、プロセスマイニングでは、記録されたデータからバリアントや遅延、手戻りを把握できます。プロセスモデリングとプロセスマイニングを組み合わせる理由では、意図した業務と実際に起きたことを切り離すべきでない理由を説明します。

なぜ実行機能を開発しないと決めたのでしょうか？

プロセスプラットフォームを検討する際に、当然出てくる質問です。プロセスをモデル化して実行状況も確認できるなら、実行機能も備えるべきではないでしょうか。BPMSが存在するのは、まさにその答えが「はい」だからです。私たちは別の道を選びました。それは機能の見落としではなく、意図的な判断です。

実際には、ProcessMindがワークフローの実行権限を求めることはありません。現在使っているシステムが引き続き業務を実行し、その業務内容に関する知識を一元化して最新の状態に保ちます。後から実行環境を入れ替えても、たとえばRPAボットをAIエージェントに、従来のワークフローを新しいものに置き換えても、モデルや履歴、測定結果はそのまま残ります。ProcessMindを開発した理由では、その背景をさらに説明します。

ProcessMindはBPMSとどのように連携しますか？

ProcessMindはBPMSではなく、業務を実行するものでもありません。BPMSやERP、自動化プラットフォームが引き続きプロセスを実行します。それが本来の役割分担です。プロセスごとに最適な実行環境を使い、すべてのプロセスに関する知識を1か所に集めます。

実際の業務では、プロセスインテリジェンスは次のように役立ちます。

• **構築前：**関係するシステムのイベントデータを分析し、実際の経路やバリアント、例外を確認します。BPMN 2.0で目標とするプロセスをモデル化し、プロセスシミュレーションで変更の影響を検証してから、ワークフローを設定します。
• **構築後：**引き続き分析を行い、実行内容が設計どおりか、現場の回避策がいつの間にか標準のやり方になっていないかを確認します。

BPMSは業務を実行します。プロセスインテリジェンスは、何を実行する価値があるかを判断し、実際に行われている業務と結果が一致しているかを確認します。

BPMS、RPA、プロセスインテリジェンスはどのように選べばよいでしょうか？

適切な選択肢は、現状をどこまで把握しているか、どのような課題を解決したいかによって異なります。

次のような場合は、プロセスインテリジェンスから始めます。

• 現在のプロセスの進め方について、担当者の認識が一致していません。
• プロセスが複数のシステムにまたがり、一部の業務が主要なワークフローの外で行われている可能性があります。
• プロセスに時間がかかっていることは分かっていても、原因が分かりません。
• BPMSを所有しているものの、ワークフローエンジンが使われておらず、プロセスの知識を役立つ場所に保管したいと考えています。

次のような場合は、BPMSを検討します。

• プロセスが十分に理解され、標準化できる程度に安定しています。
• 業務が複数のチームにまたがり、引き継ぎの振り分けや担当を明確にする必要があります。
• 複数のアプリケーションを個別に変更せずに、ルールを適用し、変更を管理する必要があります。

次のような場合は、RPAを検討します。

• プロセスが安定しており、反復的です。
• 自動化に見合う頻度でタスクが発生します。
• アプリケーションを変更できず、画面を通じて手順を自動化できます。

適切な順序で進めるには、2つの点を意識してください。実行ソフトウェアを購入する前にプロセスを測定すること、そして自動化する前に、プロセスの再設計でそのタスク自体をなくせないか確認することです。

BPMSを購入する前に、どのように評価すればよいでしょうか？

まず、名前と担当者が明確なプロセスを1つ選びます。たとえば、受注から入金まで、調達から支払いまで、オンボーディング、インシデント対応などです。対象のプロセスを特定せずに、「業務全般」のような広い範囲で評価するのは避けてください。そのうえで、次の4つの手順を進めます。

1. イベントデータを確認する

   どのシステムにプロセスの記録があるかを確認し、記録にケースID、アクティビティ、タイムスタンプが含まれているかを調べます。業務プロセス管理ツールは意図したフローを示しますが、実際に実行されたことを裏付けるのはイベントログです。

2. 設計と実行結果を比較する

   モデルに表れていない経路や遅延、例外を探します。最有力候補のBPMSを実際のデータで試すほうが、機能一覧を比べるより有益です。プロセスのどの部分を実際に担うことになるかが分かります。

3. データを基に対応を決める

   解決策はBPMSかもしれませんし、プロセスの再設計や手順の変更、あるいは何もしないことかもしれません。ツールを先に決めるのではなく、調査結果を基に選びます。

4. 構築後も測定を続ける

   プラットフォームは、自ら実行するタスクについて報告できます。システム全体のイベントデータを確認すれば、ワークフローの稼働後もプロセスが実際の業務に合っているかを把握できます。

BPMSが接続していないシステムにもプロセスがまたがる場合、最初の測定でその状況が明らかになります。実行機能の導入を判断するうえで、比較すべきなのはそこです。