DX？BPMが失敗する理由１
DX（デジタル・トランスフォーメーション）という言葉が何を意味するのか、私はまったく興味がありません。その定義が何か、あれはDXだ、あれはDXじゃないという議論をすることが無意味だからです。BPMに関しても、そのようなことを議論をしている時代がありました。実践を伴わない虚構の世界でした。そのような議論をしている間は、その用語は「バズワード」だと言われるのだと思います。バズワードがバズワードで終わるのか、そうでないかは実践され定着し「良い結果」を出せるかだと思います。BPMは良い結果を出すために様々な障害があり、それを乗り越えなくてはなりません。
「良い結果」とは、「業務の効率性が上がることによるコストダウン金額などの便益＞投資額」であることです。ところがIT業界では「動くこと」が成功だと胸を張る人がいることに驚かされます。すなわち「顧客、現場が無視されている」ということです。業務が効率化されコストダウンが実現することが目的ではなく「システムが動くことが目的」としてシステム導入側の都合で、すり替えられてきたということです。DXという言葉には、その危険性が多分にあると感じます。これに対する警告は、ビジネスアジリティ・マニフェストの「あとがき」にも書かれていることです。（「BPMとIT」参照）
目次
１．BPMが失敗する理由
２．開発者の都合をユーザーは認めてはいけない
３．まとめ
１．BPMが失敗する理由
BPMが失敗する理由は３つあります。経営コンサルタント経験のある私としては、このフレーズにちょっと抵抗がありますが・・・。
第１は「開発者都合による変質」です。第２は「従来のシステム開発手順に縛られる」ことです。最後は「地道な努力無しに、良い結果を得ようとすること」 です。今回は「開発者都合による変質」について、具体例を出して書きたいと思います。
２．開発者の都合をユーザーは認めてはいけない
BPMの話をしているときに、あるIT技術者が「顧客が求めているモノを作って納品すればいい。」と言っていました。従来のITの常識ではそうなのかもしれませんがBPMに関しては違います。BPMSは業務システム開発ツールであるというIT業界にありがちな誤解からの発言だと思います。（「BPMSとは」参照）
BPMNとBPMSを使うことそのものに意味があります（「BPMとは」参照）。「ユーザー（実務担当者）主導で業務の改革・改善のPDCAサイクルが実現できること」ということを理解していないからです（「BPM導入（改善）のステップ」参照）。
BPMを実施しようとしている企業にBPMN準拠のBPMSではなく、別のシステムツールを勧める開発ベンダーがいたとしたら取引をしない方が良いでしょう。これを受け入れてしまったらBPMでは無くなります。それが変質の１例です。
２つめの例は、BPMS導入にも関わらず「プログラムを書いた方が早い。」という常套句で、プロセス図が消えていく、またはサービスタスクだけになるという現象です。BPMN図はクラス図のようなものになってしまうという変質です。いつ、誰にとって早いのか。それは半年後、実務担当者が改善をするときも早いのか。開発者が開発するときだけの「早さ」であり、BPMSを使い続けることでの「ビジネスアジリティ」の早さではないでしょう。
３つめの変質は絵を使って説明する必要があります。BPMN図のユーザータスクはBPMSの画面になります。今までのシステム開発の常識から「１画面＝○○万円」的な発想によって画面は少ない方がいいと思われることが多いです。BPMSの場合、まったく逆の発想が必要です。いろいろな処理を１画面で行おうとすると「１画面＝○○万円」的となり、複数の画面で行うと「１画面＜１万円」となります。言葉では理解が難しい話なのでBPMN図とプロセスデータ関連表で説明をします。
BPMSにプロセス図を実装するときに、プロセスに必要なデータ項目を書き出し、どのタスクでどのデータ項目を入力、表示、非表示にするかということを事前に検討をします。「業務改革、見える化のための業務フローの描き方」のp.160 図5-4のセミナー準備プロセスの例です。 各タスクで何のデータ項目を「入力」「表示」「非表示（－）」とするかを表していいます。
このときに入力・表示データ項目が異なるが、このプロセス図と同じ流れの業務があるとします。例えば「セミナー」ではなく「イベント」だとします。
セミナーと違い「講師」ではなく複数の「登壇者」が必要になりますので「登壇者」というテーブルデータ項目を持つことになったとしましょう。また研修名を文字入力ではなく選択値にしました。
ここで「研修名」の選択は、「パンフレットを作成する」画面で「セミナー」と選択されたときは「講師をアサインする」タスクで「講師名」を入力可、「イベント」が選択されたときは「登壇者」を入力可にするというコントロールをしようと考えます。
ところが、BPMSの標準機能では１つの画面で、そのようなコントロールはできません。JavaScriptを書かなくてはならなくなります。
ここでJavaScriptを使ってしまうと、実務担当者が簡単に画面を変更できなくなってしまいます。
解決策は以下のようにゲートウェイを使って画面を２つに分けてしまうことです。
上のプロセス図に合わせて、以下のようにプロセス関連データ表も修正します。
２つの画面を作るための作業は、もともとあった「講師をアサインする」画面をコピーし
名称を変更して各タスクに紐づけ、「入力」「表示」「非表示（－）」のボタンをポチポチと選択するだけです。
すなわち「開発（コードを書く）」と呼ばれる行為は必要なく「設定」だけ済みます。
簡単化のために１つの項目だけにしましたが、１つの画面で複数のデータ項目に関してJavaScriptで制御してしまうとさらに残念な結果となります。実務担当者が維持管理できないとBPMは成り立たなくなります。
３．まとめ
BPMを理解していないIT技術者は今の結果が同じならば、自分が慣れた方法で開発することが「早い」と主張するという例を示しました。
この主張を受け入れてしまうと
・BPMを導入するつもりが単なる１度きりのシステム開発に終わる。
・BPMSを使っていてもBPMではない。
・維持管理コストがアップしてBPMSを使い続けることが困難になる。
すなわち改善のPDCAサイクルが回らない。という問題が発生します。
BPMSにおいてシステム開発行為はゼロではありません。業務改善のための、特にデータ処理そのものに関してはコードを書く必要があります。
大切なのは「棲み分け」 です。どこまでは実務担当者で管理できるようにするか、どこはIT技術者に依頼するかです。実務担当者が改善検討するツール、その結果、何がしたいのかをIT技術者に正しく伝えるツールがBPMN（「BPMNとは」参照）になります。そのBPMN図が大きく変換されることなく、BPMSに実装されることでビジネスアジリティが実現されることなります。
そのためIT技術者がBPMを正しく理解していることは、BPMの成功において非常に大切なことです。
