「プロセス管理」という言葉に騙されることなかれ。BPMにおけるプロセス管理とは。

　前回のコラムの予告通り、今回は「SFAやCRMなどで実施できるというプロセス管理とBPMにおけるプロセス管理の違い」ということを述べてみたいと思います。
　「プロセス管理ができます」という言葉は「自動化ができます」と同じで多くの意味を持っています。BPMにおけるプロセス管理は、SFA（セールス・フォース・オートメーション）やCRM（カスタマー・リレーションシップ・マネジメント）などのシステムで言う「プロセス管理」とは対象が異なるということを今回は示してみたいと思います。

１．BPMN図は階層化して描く

　BPMN図は巻物のように長く、大きな壁に貼り付けないと読めないようなプロセス図を描くことを「BPMN仕様」は禁止していません。
「BPMNメソッド＆スタイル」の著者であるブルース・シルバーは「スタイル・ルール」の中で「各プロセスレベルを１ページ内に納めるようにモデルを階層化する」と定めています。ブルースはプロセス図の管理の容易さから、このルールを作ったようです。
（「プロセス図の管理の容易さ」「１ページの大きさ」に関しては、ここでは主題でないので説明をしません。セミナーで説明をしています。）
　主にBPMが管理するプロセスは、この階層化によって明確になります。そしてSFAやCRM、RPA（ロボティック・プロセス・オートメーション）などでいう「プロセス管理」とは異なる。ということを下図で説明をしたいと思います。以下は３階層で描いたBPMN図の抽象図例です。


　第一階層は、エンド・ツー・エンドプロセスでありプロセスの全体像を網羅的に表し、各サブプロセス間の関係を示しています。BPMがBPMSを使って管理するのは、主に第二階層のBPMN図になります。担当者間、組織間の業務のやりとりをプロセス管理するのがBPMになります。
　SFAやCRM、RPA、ローコード開発ツールなどでのプロセスとは主に第三階層の１担当者が行う作業プロセスのことであり業務プロセスではありません。この２つを区別せず世の中では「プロセス管理」と呼んでいると思います。これを混同していては経営者、上層部にBPMを理解してもらうことは不可能でしょう。
　BPMSで無くても「担当者間、組織間のプロセス管理ができる」と言われるかもしれません。それは「手動でできる」または何等かのシステム開発が必要で「ノンプログラミングで標準ではできない」のではないでしょうか。また、誰がいつ、どれだけの時間で実施したという記録や、やりとりの記録は残るのでしょうか。問題が発生したとき原因分析ができないと課題を解決するPDCAサイクルは回らないでしょう。
※BPMS以外で標準(ノンプログラミング）でできる。というツールがあるのであれば、是非、教えていただければと思います。逆にそのツールをBPMNをうまく使って設計ドキュメントを削減し実務者でも設定できるようにしてみたいと思います。（問い合わせからご連絡ください。）

　尚、第三階層のBPMN図がBPMSに実装されることは稀ですが、BPMSをSFAやCRMのような使い方をするのであれば実装可能です。BPMコンソーシアムではBPMSを使ってSFA的な管理も実際に行っています。

２．「自動化できる」とは

　前述の「プロセス管理ができる」という話と同じでITの世界で「できる」「自動化できる」という言葉は疑う必要があります。
「できる」「自動化できる」とIT担当者やシステム会社のエンジニアから言われたときは、どうやったらできるのか具体的に確認する必要があります。「設定だけで標準機能として簡単にできる」ことと「いろいろな条件を整えてからプログラミングをすれば、なんとか実現できる」ということを区別せずに「できる」と言ってしまうエンジニアがいるためです。プロセス管理に関しても同様で言葉を鵜呑みにするのでは無く、何をもってプロセス管理と言っているのかを確認し比較する必要があります。RPA（ロボティック・プロセス・オートメーション）のプロセスも前述のように第三階層のプロセスを指しますが、当初、名称からの印象で勘違いした多くの方々は第二階層のプロセス管理がRPAで実現できるか試したようです。

３．まとめ　

　DXという言葉が浸透し先進的な事例を見ると、過去、DX事例とされていた単なるシステム開発による自動化改善事例ではなく「実務者が中心となってITツールを使って業務改善をすること」「IT部門などの担当者はファシリテーターになる」というのがDXにおいて大切であるという話を聞きます。過去のように自社の業務改善をシステム会社に「丸投げ」しているのは論外で、今はIT部門が主体になっているのではビジネス・アジリティが向上しないということから実務者が主体になるというのがDXの主流となっているのでしょう。
　リスキリングという言葉が流行っているようですが、研修を受けたからITツールを使いこなし業務改善ができる、ということは無いと思います。この３０年間、多くの会社が業務改善を行っていないので「改善ができる人材」「指導できる人材」「やってみせる人材」が潤沢にいないからだと思います。３０年間ですから、仮に２２歳で入社したとしても５２歳でも業務改善経験をしていない人がほどんどだということになります。指導できる人材は６０歳前後の私たちの世代がボーダーラインだと思います。（「ＢＰＭの理解を阻害する業務フローとシステムに関する固定概念」参照）同世代の人でも業務改善経験を持っていない人も多くいると思います。
　またプログラミングがAIによって行われる世界はすぐそこに来ており、IT技術者やIT部門の人材が実務、業務を理解して実務者を支援する人材になっていくリスキリングも必要になるでしょう。
　ある会社では、DXを推進するために（何のITツールを使われているかはわからないですが）実務者が支援を受けながら業務改善の実践経験をしてもらう。ということを実施されていました。（ここまでに３年を要したようです。一朝一夕にできるものではないのはBPMも同じです。）我々のご支援でいうと「モデルプロセス導入支援」や「BPM導入支援」になります。BPMコンソーシアムが「実践」がキーワードであるように、支援を受けて経験をすることが遠回りのようで実は近道であるのだと思います。
　次回は今回の話に関連して「BPMSでできることと、できないこと（実施すべきでないこと）」とBPMNの関係について書くか・・・お正月に考えてみたいと思います。

関連ページ