ＢＰＭ「体制」「しくみ」の重要性:PMBOKの壁？

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

目次
１．PMBOKの壁？
２．実務者の壁？
３．まとめ

１． ＰＭＢＯＫの壁？

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

ＢＰＭ改善のステップ

２．実務者の壁？

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

３．まとめ　

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

関連コラム・ページ

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