どのBPMSがお勧めですか

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

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

1.各BPMSの設定の違い
2.BPMSがどうあって欲しいか
3.まとめ

1.各BPMSの設定の違い

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

1.記述ツールで議論してまとめたTo-BeのBPMN図をベースとして、実行可能なフローを描く機能
2.BPMN図におけるユーザータスクが画面になりますので、その画面を作成する機能
3.画面を構成するために必要なデータ項目を設定するためのデータモデル(データテーブル)作成機能

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

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

対象的に
パターン2:1つのプロセス設定で1~3がそれぞれ独立していて「繋ぎ機能」を使って結びつける。
汎用性(画面流用、データモデル流用)が高いがIT担当がいないと設定が難しい、または習熟にかなりの時間を要する。

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

「BPMSの設定」とは、BPMSの機能が使えるようにすることあり、自動化開発をすることではありません。

誰がBPMSを「設定するのか」「設定したいのか」によって、選択されるBPMSが変わることになると思います。
その点を次に述べたいと思います。

2.BPMSがどうあって欲しいか

 BPMの改善ステップで説明をします。BPMコンソーシアムではステップ5までを実務者側(IT担当者ではない人)が行うことをお勧めしています。(理由は「まとめ」に書きます。) 

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

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

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

3.まとめ 

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

 BPMが担うのは、今までシステムが担ってこなかった人の業務を標準化し改善をし続ける(PDCAサイクルを回す)領域だからです。その領域をすばやく正しく改善できるのは実務者であり、残念ながらIT担当者ではありません。これらのことからステップ5までを実務者が担うことをお勧めしています。

 「そんなことができるはずがない!」と思う人がいるかもしれません。2023年6月15日の第一回BPM情報共有会(ここをクリック)では実際にできていること、実現する方法に関しての事例を聞くことができます。ぜひご参加ください。

関連コラム・ページ

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