BPMとは
注：必ず「BPMNとは」「BPM導入支援サービス」の動画を合わせて観てください。（青字をクリック）
YouTubeを見ることができない場合は「ここ」をクリックしてください。
BPMとは、ビジネスプロセス・マネジメント(ビジネスプロセス管理）のことです。
BPMN(ビジネスプロセス モデル＆ノーテーション）という国際標準（ISO19510）の業務フローとBPMS(ビジネスプロセス・マネジメントシステム［またはスイート］）というITツールを使って行うビジネスプロセス改革・改善のPDCA（Plan-Do-Check-Action)サイクルが回る管理のことを指します。業務プロセスの改革・改善を簡単に言うと「人が行っている業務を標準化しリアルタイムで見えるようにすること」「業務が見えることで具体的な対策がすぐに実施できること」「蓄積された業務データから課題を発見し改善し続けること」と言えます。
一般社団法人BPMコンソーシアムにおけるBPMの普及は「研修」や「セミナー」ではなく「実践」がキーワードです。研修・セミナーはキッカケに過ぎません。BPMは実践することでしか真の理解を得ることができないからです。過去、BPMに対して多くの抽象的な説明がなされてきました。そのことによって様々な誤解が生じ、多くの失敗を繰り返えされてきました。「単なる業務システム開発になる」「業務プロセスの改善ではなく作業の自動化で終わる」といった失敗は「正しいBPMの実践」を理解していないことによって引き起こされます。
目次
１．BPMにおける業務改革・業務改善のPDCAサイクル
２．BPMが求められる理由とBPMに関する誤解
３．BPMNとBPMS
４．BPM導入・改善のステップ
５．まとめ
１．BPMにおける業務プロセス改革・業務改善のPDCAサイクル
Plan:国際標準の業務フローであるBPMN（ビジネスプロセス・モデル＆ノーテーション）を使用して現状分析、課題解決、改善後の姿を議論します。
Do:Planで作成した改善後のBPMN図をBPMS（ビジネスプロセスマネジメント・システムまたはスイート）に実装し、実際の業務で使います。
Check:BPMSを使用して業務を行うと、今まで見えなかった人の業務がリアルタイムで可視化されます。そのために業務の課題が見え負荷調整、課題解決などが可能になります。
Action：人が実施している業務が定量的なデータとして蓄積され分析することができるようになります。そこからさらなる課題の発見をして、Planに戻ります。
２．BPMが求められる理由とBPMに関する誤解
近年、「働き方改革」から人の行う業務の可視化改善・可視化管理や自動化の手法、ツールが求められてきました。RPA( ロボティック・プロセス・オートメーション）が流行しましたが有効に使われている企業、組織は少ないと思います。 その名称から「業務プロセス」が自動化できると勘違いされ、残念な結果を生んでしまったと言えます。RPAで実現できることは、従来のプログラミングなどで実現する「作業プロセス」の自動化がノンプログラミングで実施できる、ということであることは周知されたと思います。求められているのは、今までシステムが対象としなかった人の業務プロセスの標準化と管理の実現であり、そのためにBPMが再注目されています。しかしながら、過去のBPM（BPMS）の説明からBPMに対する誤解が多く、BPM（BPMSも含め）正しく理解されていないと感じます。
その原因はBPMSの機能とBPMSに対する説明に問題があるようです。BPMSはビジネスプロセス・マネジメント（業務プロセス管理）を実現するための「しくみ」と業務改善を実現するときに必要となる自動化ツール（ローコード開発ツール）が一体となっているからです。前者はBPMを実現するため各BPMSが有している機能であり大きな差がありません。よって他社製品との差別化しやすい後者の自動化ツールに関して強くアピールしてしまうことでBPMSは業務システム開発ツールであるといった誤解をされてしまうようです。そのことが本来の「BPMとは何が実現できることか」が、取り残されてしまった原因であるでしょう。
この誤解を解くためにも「実践」が必要になります。従来の業務システム開発のように「作業の自動化」が優先されるとPDCAサイクルが回らなくなるという失敗事例が多く発生します。
３．BPMNとBPMS
BPMNは〇のイベント、□のアクティビティ、◇のゲートウェイが主な記号であり、守らなくてはならない記述のためのルールは多数ありますが、読むためには多くの知識が必要ないという特徴があります。またBPMNで書かれた業務フローは「誰が書いても同じ意味として伝わる」ため共通言語的に議論の中心に置くことができます。 BPMNには詳細度によって２つのレベルがあります。
| レベル 1 |
業務フローの統一化、共通言語として業務実務者と改善検討、合意形成、システム構築者に必要な情報を伝える道具として使用します。少ない記号と注釈文によって作成されているため、BPMNの表記法を知らなくても読める分かりやすい表記です。 |
| レベル2 | 業務プロセスをBPMSなどのＩＴで業務改善を実現するための情報を分析するために使用します。業務ルールや例外処理なども記号で表すことで、自動化できる部分と人の判断すべき部分が、より明確になります。 |
BPMSは、BPMを実現する（業務改善のPDCAサイクルを回す）ための、主に４つの機能が備わっています。
Plan:BPMN図を描く機能、誰がどの業務を実施するかを決めるために（組織、人の設定）、人が業務を実行するための画面を作成するための機能。
Do:プロセスを実行管理するための機能。
Check:それぞれのプロセスに流れる案件が、誰が担当し、どのような進捗・状態であるか、誰がどれだけの案件を抱えているか、などをリアルタイムで見ることができます。そのために業務負荷を分散させるための機能持っています。また滞留・遅延をしている理由を知り支援することができます。
Action:BPMS上のプロセスの実行データが蓄積されます。同じプロセスでも案件や実施者によって実施時間などが異なることや、滞留や遅延の原因を分析することができるようになります。
４．BPM導入・改善のステップ
BPMとは業務課題を解決する業務改善ツールだという視点が必要です。BPM導入のステップにおいて最も重要なのは、実務担当者を巻き込んだ改善のPDCAサイクルを回すことです。BPMは、主にミドルマネジメントの道具です。マネージャーが自分の部下がどのような仕事をしていて、それが順調なのか、誰かの負荷だけが増えていたりしないかなどをリアルタイムで管理をすることです。もうひとつは実務担当者とマネージャーが共に業務課題を解決していくための道具と言えます。【「BPM導入のステップ」のリンクを参照してください】そのためのスタートは実務担当者が自分たちの業務をBPMNを使って可視化し客観的に議論をすることです。（BPM導入のステップ１～３）
次にBPMSやITツールを使用する上で曖昧な部分を明確にするためのステップとしてレベル１で書かれたBPMN図をレベル２にするという「ステップ４」があります。このステップを省き「ステップ５」のプロトタイピングに入ると曖昧な例外事項についての対応や、どの機能を自動化するかなどをプロトタイピングしながら行うことになり、何度、作り直してもプロトタイピングが終わらないという事態が発生します。プロトタイピングは業務を改善するための、すべての要求が実現されるまで行うべきではありません。６０～７０％の実施とし、困難で時間がかかる自動化などは後回しにすることです。本当に時間のかかる自動化が必要かどうかは、実際にBPMSを使って実績データを分析し投資対効果があることかを判断してからでよいからです。「便利だから」という理由だけで、困難な自動化に費用と時間をかけてしまうことは避けるべきです。この整理が「ステップ４」でできていないと「終わらないプロトタイピング」となってしまいます。
そしてステップ６で外部システムとの連携を行い実行させます。１つのプロセスを動かすにはステップ１～６までで３か月で行うことを目標とするのが良いでしょう。その期間で実施できない場合は、対象が大きすぎるか、 困難な自動化改善に時間がかかり過ぎているのではないか。という視点で見直す必要があるでしょう。
５．まとめ
BPM(BPMS)導入において 「投資対効果をどのように説明し上司や経営者を説得するか」とよく問われます。ではホワイトカラー・事務業務の業務改善はどうやって実現するのでしょうか、と問い返したいです。「システム導入」という従来の視点からの質問と言えるでしょう。
業務プロセスの管理（BPM）とは何でしょうか。皆さん自身の業務、同僚の業務、上司の業務、部下の業務は「リアルタイム」で見えているでしょうか。ビジネスプロセス改革・改善は、まず見えるようにすることからです。
ここで発生する別の誤解は、可視化は「業務フロー」を描くことだけで行うと思っていることです。業務フローはとても重要なツールですがリアルタイムに業務を可視化することはできません。そのため業務フローだけでは継続的に業務を改善することができないという問題があります。外部環境が変化しても業務フローは書き直されず維持できないことが多いです。BPMは、実務担当者が考えた改善後の姿をBPMN図に描き、それがBPMSに実装されることで「人の業務をリアルタイムで可視化して継続的に改善し続けことができるようになる。」ことです。
とは言うものの、導入のキッカケが必要です。そのためにお勧めしているのは、１つでよいのでモデルプロセスで実際の成功事例を作ることです。
ここはITプロジェクトにおけるPoC（Proof of Concept： 概念実証 ）とも異なります。実際に実業務を実行し改善し効果を出すことです。PoCは本プロジェクト前に「お試し」をする。という考え方ですがBPMはプロジェクトではなく終わりがありません。 ここも従来のシステム導入概念とは異なります。モデルプロセスでBPMを実践してみると、とても理解しやすい概念だということがわかります。従来のシステム導入概念をぶっ壊すためにも「まず、やってみる。」ことが重要なのです。
参考コラム
・BPMと日本型経営システム
・見える化・可視化改善とBPM
・テレワーク、BPOにおけるBPM改善のヒント１
・テレワーク、BPOにおけるBPM改善のヒント２