BPM「体制」「しくみ」の重要性:PMBOKの壁?

 今年、BPMを導入ご支援やご提案の経験の中で、BPMを普及させる上での壁を感じました。前回(DXを叫ぶ、しかし導入のための説得が難しいBPM)は予算や費用対効果という点から述べました。今回は「BPMとは」でも書いているように従来の考え方が壁になっているということを具体的に述べていきます。最も大きな障害は「システム開発の壁」だと思います。BPM導入においてBPMSというITツールを使うために従来のITシステム「開発」の管理手法が適応されてしまうということが壁であると気づきました。「業務フローやマニュアルを描くと永続的な改善ができるという思い込み」と共にBPMを導入する上での大切な「体制」「しくみ」について述べたいと思います。
BPMSをVisio、iGrafx、 SignavioなどのBPMN(業務フロー)図を描く記述(ドローイング)ツールだと誤解されている方もいらっしゃるようです。それらを「ソリューション」という言葉で説明しているからのようです。「BPMSとは」を読んでいただければと思います。ちなみにBPMコンソーシアムでは「PoC」と同様に「ソリューション」という誤解が生じるような用語は使用しません。「経営を変革させるソリューションを提供します。」どのような会社にも本当に提供できるのであればノーベル経済学賞がもらえると思います。

目次
1.PMBOKの壁?
2.実務者の壁?
3.まとめ

1. PMBOKの壁?

 まず「BPM導入」と「アジャイル開発」とは、ほぼ無関係と言えます。「BPMS導入」と「アジャイル開発」は関係があるかもしれません。BPMの改善には、下図のように6つのステップがあるとお伝えしています。「アジャイル開発」のような手順・手法はステップ4~6が関係する可能性があるかと思いますが、私はアジャイル開発手法・標準が必要であるとは思いません
お客様の数社で以下のようなお話しがありました。
1.自社のシステム開発標準にアジャイル開発標準がないので、従来型のシステム開発手法を取らざるを得ない。
2.従来のシステム開発標準の手順に則るとBPMS導入には不要な文書を作らなくてはならない。
 1の話を聞いたとき、お客様が何の話をされているのか私にはわかりませんでした。なぜならBPMはシステム開発ではないからです。ウォーターフォールやアジャイルといった手法と直接は関係ないです。別のお客様で2の話を聞いたときに1の意味が理解できました。すなわちBPMはBPMSというITツールを使うために「システム開発」だと勘違いされる特に経営者クラス)ということに気づきました。そのためにシステム開発標準で管理をしようとしている、ということだとわかりました。
 BPMにとってウォーターフォール、アジャイルといった従来のITシステム開発の「用語」「手法」を適応させること自体が壁になっていると気づきました。昨年から今年にかけてのお客様のご支援で、私はお客様がBPMを理解していないのではないかと何度も疑ったことがありましたが、お話しをするとキチンと理解されている。この私の誤解は、ここにあったのだなと思いました。(経営層がBPMSを使っているためにITシステム開発という理解をしているので、担当者はシステム開発としての進捗を報告しなくてはならない。しかし実のところは違うため2重管理が必要。)


BPM改善のステップ

2.実務者の壁?

 BPM入門:基礎知識+実例セミナーやBPMNレベル1セミナーを受講された方の多くが「実務者にBPMN図を勉強してもらって描いてもらうことが困難」「どのようにして実務者にBPMN図を描いてもらうようにするかが課題」と言われます。「忙しいから業務フローを描くための時間が取れない」と言われるのですが、「忙しいからできない」は「業務改善はしない」と言われているのと同じです。業務改善は「実施するためにどうするか」という思考が必要になります。
 下図は内外の環境が変化したときに、システム修正を行う手順の違いを述べています。
上段は従来のように、IT担当者や外部委託者が変化点を聞き取り、業務フローを描き、要件定義をするというような手順です。この方法の場合でも実務者は調査対象として聞き取りの時間を作らなければなりません。聞き取る人の誤解などがあるため修正のためのレビューの回数が増えることで時間が奪われます。または不完全な聞き取りで調査が完成したことになります。後者の場合は、プロトタイピングで実務者からの指摘が発生し「作っては直す」が繰り返されることになります。プロトタイピングが繰り返されるということは実務者もレビューに出席する時間が多く必要になるでしょう。
 下段のようにBPMNが実務者の道具となって維持管理されている場合は実は実務者の負荷が少なく、しかも全体の工数としても少なく変化対応ができるようになるでしょう。
 もちろん、それは一朝一夕にはできません。できるようになるには訓練、経験が必要になるでしょう。しかし、ある程度の経験を積むとBPMN図を描いている時点でBPMSがどのように動くかということが予測することができるになります。そのとき、前回のコラムに書いたように「構築されたシステムに対して『使いにくい』と実務者が文句を言っているような時代は終わる」ということが実現するでしょう。

3.まとめ 

 そもそもITにおける「システム開発」という言葉が時代遅れに感じます。これはITビジネスの主軸が汎用機を売ることであったころの名残だと思います。本当に皆さんは「ITシステムを開発されていますか」「プログラミングをすると開発ですか」と問いたいです。そういった従来の概念に固執し続けていて良いのでしょうか。
 前述のBPM改善のステップにおいて1~5は、一般的なITシステム導入とは無縁と言ってよいでしょう。ステップ4で作成されるTo-Beフロー図とプロセスデータ関連表があれば実現できるからです。ただしステップ6は従来型のITシステム導入に近いものがあります。ここには、従来のシステム導入的な「設計書」が必要になるでしょう。しかし、ここはBPMにおいての「本丸」ではありません。世の中には、このステップ6での「聞こえが良い自動化事例」(BPMSとRPA連携で年間〇千万円コストダウンなど)をBPMとは直接、関係ないと言える事例を見かけます。(単にBPMSに備わっているローコード開発機能を使ったというだけで、これはBPMSで無くてもできますよねっていう指摘を受けるだけで自殺行為とも言えます。)
 逆にステップ3まで(業務フローを描くだけ)で業務改善が永続的に継続できるかのような話も溢れています。「モデルプロセス導入改善とBPM導入方法について」で述べたように業務フローの維持管理が「永遠の課題」と言った先人たちの導入方法が間違っていたのでしょうか。当初は業務フロー図や業務マニュアルを維持管理する部門を作りますが、経営環境が悪くなると、すぐにそのような部署は無くなってしまい維持できなくなります(業態によります。コストよりも業務品質重視の場合は維持されているようです。)
 すなわち、維持できる「体制」「しくみ」が重要だということです。それは従来にない体制・組織(業務フローを維持管理する部門など)を作るということではなく、従来に近い形で無理のない「体制」を作ることが重要ということだと思います。当初は支援部門が必要だと思います。しかしBPMが「しくみ」化され定着すると支援部門は必要では無くなる。というように進めなくてはならないということです。
 「BPM導入支援サービス」の動画で、ある程度のお勧めの体制や進め方は示しているものの、どのような「体制」「しくみ」で進めるかは、組織の経営環境によって異なると思います。それを検討するためにも、ステップ1~5までを実施するモデルプロセス導入を実施してみることが大切です。BPMは実践です。BPMN記述~BPMS実装までを行い、何が実現できるかを実感することが、どのようなセミナー、書籍よりも大きな理解を得られることになるでしょう。

関連コラム・ページ

・BPMとは
BPMSとは
BPMNとは
BPM導入支援サービス
モデルプロセス導入支援サービス