導入プロジェクト体制は存在しても、ＢＰＭはプロジェクトではない。

　プロジェクトとは「開始」があって「終了」があるものと定義されています。BPMはBPMSというシステムを使用するために一般的なシステム導入と誤解されることがあります。プロジェクトという言葉を使うことがありますが、それはBPM導入のための体制が開始され終了するのであって、BPMそのものはプロジェクトではないため終わりがありません。
　それはBPM（ビジネスプロセス・マネジメント）はマネジメントの「しくみ」であるからです。「しくみ」の導入、定着までがプロジェクトとなりますが、BPMはプロジェクトではないということです。

目次
１．導入プロジェクト体制とは
２．プロジェクトでは何をするのか
３．開発ベンダーの役割
４．まとめ

１． 導入プロジェクト体制とは

　下図のような体制です。一般的なシステム導入と異なるのは委託先システム開発ベンダーが点線で囲まれていることです。すなわちBPM導入のプロジェクト体制に委託先開発ベンダーは必須ではない、ということを示しています。コンサルティング支援には３つの要素が含まれています。１つはBPMそのものに関する導入支援、次にBPMNの記述に関する支援、最後にBPMS実装に関する支援です。

２． プロジェクトでは何をするのか

・BPMとは何かを理解してもらう。
　座学での説明も行いますが、まずは「やってみる」ことで理解をします。すなわち1プロセスをBPMN記述からBPMS実装をすることでBPMとは何かを肌感覚で理解してもらうと同時に、改善効果を定量的に測定できるようにします。

・BPMN記述支援
　BPMNの記述講習を受けた後、改善したいプロセスのAs-Is,To-BeのBPMN図を記述し、添削を受けながら正しいBPMN図が描けるようになるまでOJT(On the Job Training)を行います。正しいBPMN図が記述することができると、イメージした通りのプロセスがBPMS上で動かすことができるようになります。BPMS実装に必要な「プロセスデータ関連表」の作成トレーニングも同時に行います。

・BPMS実装支援
　BPMSそのものの技術的な講習を受け、実際に自分で書いたBPMN図とプロセスデータ関連表から実装してみることです。これをOJTで自分達の手でBPMN図が実装できるようにします。（ここはそれぞれの企業によって誰が実装するかは変わると思います。）

主に、この３つをプロジェクトで行うことになります。ある程度の習熟が進むとプロジェクト体制は解散し、コアメンバーが調整・支援を行いユーザーが主体的に動きＰＤＣＡサイクルを回していくことになります。

・そこにシステム開発要素が入る場合、開発ベンダーの支援や情報システム部門の支援が必要になります。

ここまでの内容を丸投げしてしまうプロジェクトがあります。すなわちコンサルタントが聞き取りをしてBPMN図を描いてしまい、次にシステムベンダーがBPMSを使ってシステム開発をしてしまう。ということです。これはBPMではなくBPMSを使った単なるシステム開発です。この場合必ずしもBPMNは必要ありませんしBPMSである必要もありません。ローコード開発ツール専用のフローなどを描いて実装すれば同じことができます。ただしユーザーが中心となってPDCAサイクルが回せなくなる可能性が高いです。過去、多くのBPMの失敗事例は導入方法が間違っているからです。そしてPDCAサイクルを回す維持費用が高くなり永遠に費用対効果が見合わなくなることからBPMSを使うことをやめるという結果になってしまいます。

３． 開発ベンダーの役割

　 プロセスを完成させるのはユーザーであり、開発ベンダーの役割はユーザーができない部分だけを開発することです。ユーザー側は間違ってもプロセス全体を開発ベンダーに任せてはならないです。なぜなら開発ベンダーが詳細な業務を理解する必要があり、そのためには大変な工数を要することになってしまうからです。そうすると小さな改善をするのに高価な開発費用がかかり、費用対効果が見合わないということになってしまいます。これは互いに不幸な結果を生むことになります。

４．まとめ

　 「費用対効果」ということを書きましたが、ＢＰＭを単なるシステム導入と捉えた場合、短期的（プロジェクト体制を組んでいる期間）の費用対効果を望むと見合わないことになります。ＢＰＭは、かつての日本企業の長所とされた（今もそういった企業もあると思いますが・・）「長期の視点での評価」が必要です。従業員一人一人の業務改善能力を発揮してもらう、または業務改善能力を育成することが、ＢＰＭという「しくみ」によって実現できるからです。それは長期の視点で見た場合、大きな組織力となる業務改革につながります。ただし前述（朱書）したように導入方法を間違うと永遠に費用対効果は見合わないことに陥るため注意が必要です。
　ＢＰＭの予算は、本来は単なるＩＴ投資として計上するものではないということになります。経営方針として「ＢＰＭを導入する」という判断が必要であり、そのために経営者のＢＰＭに対する理解も必要になります。ただしＢＰＭはミドルマネジメントのしくみ・ツールであるため、経営者が主体的に導入するのではなく、ボトムアップで導入されることが望ましいです。そのために小さな費用でBPMN～BPMS実装まで「まずやってみる」ことをお勧めしています （BPM モデルプロセス導入支援サービス参照） 。実体験・実践が無くＢＰＭを正しく経営者に説明することは、とても難しいことです。
　座学で「わかったような気分」になることはできますが、経営者が勘違いをしてＢＰＭを理解し主体的に導入すると、これも不幸な結果を生むことになります。まずはマネージャクラスが、まずやってみることでＢＰＭを正しく理解し自分達の道具として使いこなしたいと思うことが先です。
　次回、ビジネスアジリティを実現するＢＰＭと一般的なローコード開発の違いについて書きたいと思います。

関連コラム・ページ

・BPMとIT
・BPMとは
・BPMSとは
・DX？BPMが失敗する理由１
・DX？BPMが失敗する理由２
・DX？BPMが失敗する理由３
・BPM モデルプロセス導入支援サービス