どのＢＰＭＳがお勧めですか

　セミナー受講者から「どの会社のＢＰＭＳがお勧めですか」とよく聞かれます。優等生的な返答として「導入される組織、体制によって向き不向きがあり、どのＢＰＭＳがお勧めだとは言えません。」と過去には答えていました。この返答は、経営コンサルタントでも言えるレベルです。「もっと詳しく違いを教えてください。」という質問に対して答えられる人は、多くはいないと思います。ここでＩＴベンダーは、自動化開発機能の違いの話をしますが、それは答えになっていません。論点のすり替えです。ＩＴ担当者ではない質問者としてはモヤモヤ感が残ることになるでしょう。
　最近、私は「どのＢＰＭＳも『帯に短し、襷に長し』で正直イライラします。」「どうして、ここはこういう作りなのか」「なぜこう作らないのか」「ここがこうなっていれば、もっとお勧めができるのに」と言ってしまいます。どの会社のＢＰＭＳのどこが良くて、どこが残念なところかということは、中立的な立場であるBPMコンソーシアムとしては、ここで書くことができません。しかし残念な思いがあるのは事実です。そこで「ＢＰＭＳの違いとは何か」「どうあって欲しいか」をここでは述べていきたいと思います。

※以前のコラムでも書きましたが、BPMSをVisio、iGrafx、 SignavioなどのＢＰＭＮ（業務フロー）図を描く記述（ドローイング）ツールだと誤解されている方もいらっしゃるようです。その誤解のまま読むと何が書いてあるのかわからないと思いますので気をつけてください。まず「BPMSとは」をお読みください。

１．各BPMSの設定の違い
２．BPMSがどうあって欲しいか
３．まとめ

１．各ＢＰＭＳの設定の違い

　ＢＰＭＳは自動化を実現するための開発ツールだと理解している人も、これから書くことは全く理解できないと思います。（まず「BPMSとは」をお読みください。）
　ＢＰＭＳ実装には３つの機能があります。

１．記述ツールで議論してまとめたＴｏ－ＢｅのＢＰＭＮ図をベースとして、実行可能なフローを描く機能
２．ＢＰＭＮ図におけるユーザータスクが画面になりますので、その画面を作成する機能
３．画面を構成するために必要なデータ項目を設定するためのデータモデル（データテーブル）作成機能

各ＢＰＭＳによって、この３つの機能がどのように組み合わされているかがポイントです。

パターン１：１～３が１プロセスで一体化されている。
設定は、ＩＴ担当である必要はまったく無く、直感的に設定でき習熟時間も短いです。しかし汎用性、自由度が小さいです。

対象的に
パターン２：１つのプロセス設定で１～３がそれぞれ独立していて「繋ぎ機能」を使って結びつける。
汎用性（画面流用、データモデル流用）が高いがＩＴ担当がいないと設定が難しい、または習熟にかなりの時間を要する。

中間として
パターン３：１は独立、２と３が一体化している。
ＩＴ担当でなくても設定は可能ですが、すこし習熟に時間が必要ですがパターン２ほど困難ではありません。またパターン２ほどではないですが汎用的です。

「ＢＰＭＳの設定」とは、ＢＰＭＳの機能が使えるようにすることあり、自動化開発をすることではありません。
誰がＢＰＭＳを「設定するのか」「設定したいのか」によって、選択されるＢＰＭＳが変わることになると思います。
その点を次に述べたいと思います。

２．BPMSがどうあって欲しいか

　ＢＰＭの改善ステップで説明をします。ＢＰＭコンソーシアムではステップ５までを実務者側（ＩＴ担当者ではない人）が行うことをお勧めしています。（理由は「まとめ」に書きます。）　

ステップ５までを実務者が行うためのＢＰＭＳは、パターン１とパターン３がお勧めです。
　パターン２のＢＰＭＳは、ローコード開発ツールに後付けでＢＰＭＳの機能を付加した、またはＢＰＭＳに開発汎用性を高めようとした結果、そうなってしまった。と思われます。パターン２の製品はステップ５までを実務者が設定できるようにするためには、どのように改造をするべきかを考えて欲しいです。
　パターン１のＢＰＭＳは、余りにも汎用性がないために同じようなプロセスを応用して使うために、工数がとても必要になってしまいます。コードを書かなくても良い代わりに、同じことを何度も繰り返さないとできないために忍耐力が必要です。汎用性、応用性を高めるような修正をして欲しいと思います。
　パターン３に関しては、パターン１ほど実務者が直感的に使えるように、わかりやすくなっていません。パターン１のＢＰＭＳを少し勉強して同じようなことができるようにすれば、もっと短い時間で実務者は習熟できるでしょう。

　ＢＰＭＳが「帯に短し、襷に長し」と言っているのは、「ＢＰＭＳとしての本来の機能の設定が実務者が直感的に設定できるようにはなっておらず、ローコード開発ツールとしても中途半端」その逆で「ローコード開発ツールとしては良いが、ＢＰＭＳの機能が実務者では設定が困難。」というところからです。

「ステップ５まで実務者ができるようにしましょう。」とは、日本のＢＰＭコンソーシアム以外、世界を見渡しても恐らく誰も言っていないと思います。それは日本の経営環境だからこそできることであり、適していると思っているからです。（「ＢＰＭと日本型経営システム」参照）

３．まとめ　

　ＢＰＭを「システム開発（アジャイル開発）」だと理解している人にとっては、ＢＰＭの改善ステップは、ウォーターフォール開発を少し変えているだけ、と読んでしまうようです。「業務フローを描いて要件定義をして設計書を書いて実装している。」というように読み違えます。そう読み違えている人は、これからも間違いなくＢＰＭ（Ｓ）導入を失敗し続けることでしょう。動いていれば成功ではありません。単にＢＰＭＳをローコード開発ツールとして使い、本来ＢＰＭが行う業務改善領域に入ること無く、開発者に「何のためにＢＰＭＮ図があるのかわからない。」と言われることになるでしょう。
「そこは人が運用で行うことなのでＢＰＭＳには実装しません。」という言葉が出てきた時点でＢＰＭではありません。

　ＢＰＭが担うのは、今までシステムが担ってこなかった人の業務を標準化し改善をし続ける（ＰＤＣＡサイクルを回す）領域だからです。その領域をすばやく正しく改善できるのは実務者であり、残念ながらＩＴ担当者ではありません。これらのことからステップ５までを実務者が担うことをお勧めしています。

　「そんなことができるはずがない！」と思う人がいるかもしれません。２０２３年６月１５日の第一回ＢＰＭ情報共有会（ここをクリック）では実際にできていること、実現する方法に関しての事例を聞くことができます。ぜひご参加ください。

関連コラム・ページ

・BPMとは
・BPMSとは
・BPMNとは
・BPM導入支援サービス
・モデルプロセス導入支援サービス
・ＢＰＭは古い？経験から考え方を変えてみる
・第一回ＢＰＭ情報共有会（ここをクリック）