「BPMの誤解」のまとめ

　’25年９月に発売した「ビジネスプロセス・マネジメントのための業務フローの描き方」の「はじめに」に「BPMにはノイズがある」と書きました。ここのでノイズとは簡単に言えば「誤解の発信者」がいることにより「BPMの理解が歪められている」という意味です。書籍には具体的には書きませんでしたが、ここではやや具体的に書いてみたいと思います。
　「BPM入門　基礎知識＋事例セミナー」に参加された方は「BPMとは、こういうことだったのか」という多くのコメントがあります。「ではBPMをどういったものだと思ってましたか」と聞くと、多くの人は「ざっくりとした概念、フレームワークというイメージだった」（「BPMは手法でありフレームワークではない」参照）と言われます。
　それは「概念」にしておくことで自由度があり、BPMという言葉を使ってBPMではないビジネスをする人にとっては都合が良いからでしょう。
　「BPMの誤解の発信」は、以下のように、大きく２つあります。

　・BPMと称してITシステム開発で「作業の自動化」ができるところを探すために業務フロー（BPMN図）を描く
　・「ビジネスプロセスをマネジメントする」という言葉を利用することで具体的な方法論、事例を示さない空論を語る「研修」をする目的

これらを説明することで、BPMが明確なマネジメント手法であることを説明したいと思います。

目次
１．要件定義のためにBPMN図を描くのではない
２．経営者や管理者が監視するためにBPMは存在しているのではない
３．まとめ：業務改善のPDCAサイクルが容易に回ることがBPMである

１．要件定義のためにBPMN図を描くのではない

　セミナーで「BPMN図（業務フロー）を描くと何か業務の課題が発見できるというようなしくみがある、というようなことは無いですよね」と質問をされることがあります。「はい、無いです。ただし、正しく描くことで、その読みやすさから議論が進み、業務の課題が整理できます。」と答えます。そして「課題を整理して課題解決後のBPMN図を描いただけでは『絵に描いた餅』でしかないです。」と付け加えます。
　現状分析は、とても大切ですが現状分析をして課題解決後の姿の業務フローを描くだけでは、実際の業務は改善されない。ということです。そしてIT系企業が（システム開発部門を持つコンサル会社も）主体でBPMを導入すると「業務を改善する」ということを「作業の自動化をする」ことに置き換えられてしまいます。そしてBPMN図は、単に要件定義時に「作業の自動化をするところを探す」ための道具に成り下がり「作業の自動化」の要件が洗い出された後はBPMN図は不要になり２度と使われなくなります。
　このような結果になる場合、業務フローを描くのにBPMN図で無くてもよかった。という評価にもなります。この１０数年の間にITエンジニアに「何のためにBPMN図があるかわからない。」と言われたことが何度もあります。「ユーザータスクを全部無くして全部、自動化しました。」と鼻高々に語るITエンジニアもいました。「それはBPMの対象ではない『作業プロセス』をBPMN図で描いているからそうなるのでしょう。」と言っても彼らには通じません。ITとは「作業の自動化」を実現することだという固定概念に縛られているからです。作業プロセスを対象にしているのであれば、BPMはWPA（ワークプロセス・オートメーション）という名前だったのではないでしょうか。　
　これは、国、特に総務省がスタートとなり誤解の発信があったことも原因と言えるでしょう。「政府(自治体）システム調達のための業務フロー」であるとBPMN図を位置付けてしまったためです。そのために、いろいろな意味で解釈ができる間違ったBPMN図が描かれて公開されてしまっています。
（第１回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（データオブジェクト編）第２回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（シーケンスフロー編）第3回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（メッセージフロー編）参照）
　国や自治体の場合（民間企業でも、いまだにあるようですが）「全部、委託者に丸投げ」をするという体質を自組織で事前に要件定義をする。ということに変えたい、ということを考えられたのだと思います。それは「システム開発」においては大切なこと（これは私が実践し効果のあったことでもありますので：マンガ参照）ではあったのですが、BPMNを使ったことでBPMに対しての誤解の発信になってしまったということです。
　「作業の自動化」「システム開発の現状分析、要件定義」のためにBPMN図が使われたことで、BPMは現状分析、要件定義の道具だという認識が広まってしまいました。恐らく多くの人は、その誤解のままです。
　この誤解は「SAP社のSignavio」というツールや「プロセスマイニングツール」がBPMと密接に関係するという誤解も生みだしました。（「BPMにはプロセスマイニングツールは不要」参照）Signavioに関してはSAPの社員も誤解しており、Signavioのような製品をBPMSだと思っているようでした。「Signavioもプロセスマイニングツールも、現状分析、課題発見のためのツールでしかない。」という話をしたのですが、SAPの社員には逃げられてしまいました。
　現状分析、課題発見の道具としてはBPMN図や過去、いろいろあった業務フローの描き方で十分であり、高価なツールを買って分析に時間をかけるのはムダなことであると思います。昔から言われているように、業務課題は業務を行っている人が知っているからです。それを引き出せるかどうかだけであってツールなどに頼る必要はありません。高価な現状分析ツールは先人が言っていたように「業務フローやマニュアルを書くことは、良いことではあるけれど維持ができない。これは永遠の課題だ。」という域を脱しない。ということです。

２．経営者や管理者が監視するためにBPMがあるのではない

　「可視化ではなく透明化――BPMが実現する実質的な権限移譲」、「BPMはKPI管理の道具ではない～改革人材を育成し変化に強い企業を作る～」（参照）という２つのコラムで述べました。
　システムで監視できるという話は経営者にウケるようです。例えばSFA（セールス・フォース・オートメーション）が営業活動の情報共有のために導入されていると思いますが多くは使われません。その原因は「余計なことをさせられている。」という認識と「中途半端なプロセス管理」しかできないからです。すなわちSFAは使う人にとってメリットがないということです。そこで、いろいろな作業の自動化を組み込むことで無理やりメリットを出そうとして多額の投資をする。これは「術中にハマっている」と言えます。
　BPMを導入（実務者が主体となってBPMN図の記述、BPMSの実装）が実現すると、KPIでの管理、バランストスコアカードでの管理ができるようになります。しかしながら、これが目的ではありません。これを目的として語っている人には、KPI管理の方法を具体的に聞き、具体的な事例を示すようにお願いしてみましょう。そうすると具体的な事例がないので「BIツールを導入しましょう」「プロセスマイニングツールを導入しましょう」などという話になると思います。（「BPMにはプロセスマイニングツールは不要」参照）

３．まとめ：業務改善のPDCAサイクルが容易に回ることがBPMである

　BPMと「BPMもどき」との違いを一言で表すと「業務改善（作業の自動化ではない）のPDCAサイクルが回るしくみが具体的に用意されているかどうか」です。
これが明確に、実例を示して答えられない場合、それは「BPMもどき」です。「そのときは、なんとかツールを」「ある時は、なんとかツールを」などと、いろいろなツールや抽象論に持ち込まれて煙に巻くような話になる場合は、それはBPMでは無くなる可能性が高いです。
　BPMはBPMNとBPMSを車の両輪としてPDCAサイクルが回る業務改善手法です。手法が明確であるからこそ実践しているのであれば、具体的に「描いたBPMN図をBPMSで動かし実例を示せる」はずです。具体的な事例が示せない企業、人は「BPMの誤解の発信者」といえると思います。

関連ページ