BPM導入が「いつの間にか普通のシステム開発」になる原因
BPM（ビジネスプロセス管理）を導入しているつもりが、いつの間にか普通のシステム開発になる原因は、BPMNの使い方が間違っていることから始まります。普通のシステム開発とは「作業の自動化」を中心とするシステム導入です。
BPMNを単に「国際標準の業務フローの描き方」という認識だけで「今まで描いていた業務フローと同じ使い方」をしていることが原因です。しかし、これを成功事例としているITベンダーもいるのでBPMに対する誤解が広がってしまいます。
なぜ「普通の作業の自動化のシステム開発」に陥ってしまうのかは、過去のコラムと関連付けて説明をしてみたいと思います。
目次
１．一般的なシステム開発における業務フローの役割
２．BPMにおけるBPMN図の役割
３．まとめ
１．一般的なシステム開発における業務フローの役割
以下は３階層で描いたBPMNの抽象図です（注：ＢＰＭＮ図は必ず３階層で描くということではありません。）第一階層はEnd to Endプロセスで大きな業務プロセスを網羅的に表現したものです。第二階層はそれを分解した詳細な業務フローになります。一般的な業務フローは赤丸の囲った作業の自動化ができる部分を探すために描かれていると思います。対象となった「作業が自動化」ができる（したい）部分に対してのデータや帳票などのインプットとアウトプットを中心に描くというような目的で描いていると思います。（コラム：「プロセス管理」という言葉に騙されることなかれ。参照）CCC,EEE,GGGのユーザータスクは作業の自動化対象では無く、IT技術者が良く使う言葉「人が運用で行う部分」で開発対象では無いため、そこそこの話を聞くものの詳細には記述しないでしょう。それは、かつて私がシステム会社でERPの導入をしていたときもそうでした。なので第二階層レベルの業務フローなど参考資料程度（コラム：「ＢＰＭの理解を阻害する業務フローとシステムに関する固定概念」参照）のモノでしかないので拘ってキレイに描いている人を内心、バカにしていました。そのフローは「ユーザーの自動化要望が業務の中の、どの部分か」ということを確認する程度でしか使用しないからです。第三階層以下のフローはシステム開発のための設計書として書く内容なので描いたとしてもＢＰＭＮでは無く一般的なフローチャートで書くという認識でした。
このような認識で業務フローを描いている場合「なぜBPMNなの？」という疑問が沸くのは当然のことです。私が開発者側であったときもBPMNで業務フローを描く意味が全くわからなかったです。
BPMN図を実務者が書く場合も同じです。BPMN図がわかりやすく、議論しやすいというメリットがあるとしても「作業の自動化ができるところを探す」という目的で第二階層のBPMNの描くという間違いをするのであれば、誰が描いても同じです。そして、沢山の業務フローを描いての沢山の「作業の自動化」が見つかると（ウォーターフォール型開発でいう要件定義）システム開発の大プロジェクトが始まります。その時には第二階層のBPMN図は、二度と使われない必要の無いものになっているでしょう。コラム（「BPMはウォーターフォールで失敗する」参照）
「作業の自動化」部分が開発されて効率的になりコストが下がったはずだと思っていても、実際はユーザーが想定していたようにシステムを使わないという問題が発生します。上図で言うとFFFを先に実施してBBBを後で行うということもできてしまうということです。これを第三階層だけで規制しようとする、さらに、あらゆる部門が使っても問題が発生しないようにシステムを作るということをするには、非常に複雑なロジックを組み込むことになります（これが組み込まれるとブラックボックス化され、業務知識がプログラムソースに埋没します。）多くの場合は、そのような複雑なロジックを組み込むことを断念し各部門共通の機能のみを実装します。なぜならば内外の環境が変化すると、そのロジックをまた組み直さなくてはならなくなるため、簡単に変化対応ができないからです。
そうするとユーザーが、第二階層の作業順を無視できるユルユルのシステムができあがり、順番を守らないことから不効率、間違いによるやり直しの発生、顧客クレームの発生、不正などが行われるということになります(これを分析するツールがプロセスマイニングツールですが、ＢＰＭが正しく導入されていれば不要です。）システムが構築し終わったら効率的になると思っていたのに実現せず、またクレームや不正が発覚した場合のコストというのは非常に高いものになります。ＢＰＭは効率的な手順でクレームや不正などの問題が発生しない業務の標準化、業務改善をするためのマネジメント手法です。（コラム「一般的な業務フローとＢＰＭＮ図との違い」の銀行の例を参照、２回目の銀行への訪問でも同じように預かり書をタブレットに入力されサインしました。作業が自動化できていてもプロセスを管理していないことで発生するムダです。ここは後述します。）
２．BPMにおけるBPMN図の役割
ＢＰＭは「第二階層の業務フロー通りに人が効率的に作業できることを目的」とした管理をすることです。すなわち第二階層のＢＰＭＮ図をＢＰＭＳに実装して管理をすることです（３階層での説明がわかりやすいためであり、必ずしも３階層で描くわけではありません）。ゆえに人が行っている業務も詳細にＢＰＭＮ図として記述する必要があります。
この第二階層のＢＰＭＮ図がＢＰＭＳに実装されるとシーケンスフロー（→線）通りの順番で業務が行われることになります。CCC、EEE、GGGというユーザータスクで人が何をすべきかということを標準化して「動く業務マニュアル」（画面）を作ります。
ここは同じようなプロセスでも部門によって登場人物が変わる（レーン変更）、ローカルルールがある（ユーザータスク内の変更とゲートウェイ変更追加）などでプロセスは変化します。すなわち部門ごとに変化するのはBBB、DDD、FFFといった「作業の自動化」をする部分（パーツ）では無く、CCC、EEE、GGGというユーザータスクの中の画面の変更（動く業務マニュアル）、レーンの変更、ゲートウェイの追加・変更などです。ここはITエンジニアでなくてもユーザーレベルで変更が可能な部分です（ＢＰＭの改善ステップの５）。
ここも「部門ごとにプロセスを変化させる」という意味を誤解する人がいます。BBB、DDD、FFFといった「作業の自動化」を中心に考えるとそういった誤解が発生します。「作業の自動化」の中に前述のように複雑なロジックを組み込むと考えているからです。複雑なロジックを簡単なフローに置き換えているのが第二階層のＢＰＭＮ図です。これが「ＩＴからビジネスへの権限移譲」（コラム「あなたが描いているのはBPMN図ではありません」の図を参照）です。
また第二階層のＢＰＭＮ図は、人が行う業務以外に自動化された第三階層もコントロールします。
３．まとめ
BPM導入が、いつの間にか変質してしまう原因は、従来のシステム開発の考え方に囚われているからだと思います。それはウォーターフォール型の導入方法を取ってしまう（コラム「BPMはウォーターフォールで失敗する」参照）、第三階層の「作業の自動化がＩＴシステムが担う部分という決めつけ」から「ペーパーレス」「ＲＰＡが使えるところを探す」「システム間連携ツールでシステム間を繋ぐ」などといった発想に陥ることから変質してしまうということです。
これらの失敗は導入するシステム会社や支援する経営コンサル会社の問題として責任を転嫁させてしまいがち（コラム「BPMは手法でありフレームワークではない」参照）ですが、これはユーザー企業・組織の責任です。ユーザー企業・組織が社内の業務改善をシステム会社や経営コンサル会社に「丸投げする」、薄っぺらな「作業の自動化」の成功事例から、よくも調べずに「ＢＰＭを誤解する」ということから発生するからです。
一方「ユーザー企業・組織がＢＰＭの正しい認識をする。」というのはＢＰＭコンソーシアムの使命とも言え、そういった失敗事例が発生するのは、資金力を含めて我々の力不足であるとも言えます。ここは我々は一層の努力をして行かねばなりません。
また多くの誤った発信があることも原因だと思います。特に国や自治体等からの発信は古い情報・誤った認識のものが多いので気をつけていただければと思います。これらの発信はＢＰＭＳの機能を知らない、使った経験がないのにも関わらず、盲目的にＢＰＭＮで業務フローを描いているか、または机上の空論から発生していると思います。（コラム：第１回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（データオブジェクト編）第２回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（シーケンスフロー編）第3回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（メッセージフロー編）)
さらには「コストダウン」の考え方が近視眼的、短絡的になっていることも原因と言えます。前述の銀行の例（コラム「一般的な業務フローとＢＰＭＮ図との違い」の銀行の例を参照）で説明します。ペーパーレス化することで「コストダウン額＝○○円コストダウン額/回×年間の預かり書の発行回数」という数式のコストダウン額は、「顧客への説明に失敗」して顧客に２回来店させることによって、顧客クレーム対応（信用の失墜）、やり直し作業、タブレットでの入力作業が増えるというコストアップを隠し、発行回数が増えていることでコストダウン額が増えているというような間違った認識を発生させます。このように第三階層のコストダウンは第二階層によるコントロールがあるからこそであり、第二階層が管理されていれば、「顧客への説明に失敗」をしていることがＢＰＭＳ上の記録として残ります。
そこでＰＤＣＡサイクルが回り「顧客への説明に失敗」を無くすためにはどうするか、を考えて改善策をＢＰＭＮで描き、ＢＰＭＳで実装することでミスを無くすといったＢＰＭの本来の目的に繋がることになります。
次回は今回に関連して「ＢＰＭが正しく導入されれば、プロセスマイニングツールは不要」というテーマで書きたいと思います。
関連ページ
