DX？BPMが失敗する理由2
BPMが失敗する理由の第２は「従来のシステム開発手順に縛られる」ことです。「BPMはシステム開発（コーディング、プログラミング）と無縁ではないですがシステム開発ではありません。」 （「BPMSとは」参照）。 よって、従来のシステム開発手法に縛られていると失敗をしてしまいます。発想の転換が必要です。
前回も書いたように、私は「DX」には興味がないですが今後の業務改革・改善とITシステムの関係はBPMの導入のように変わっていくことになると思います。例えばAIツールを導入するとしても、従来のシステム開発のように人月工数を積み上げた見積のビジネスでは無くなると思います。もちろんアーキテクチャの変更などによるバージョンアップなどユーザー企業にとっては、ほとんど改善に寄与しない単なるコストとしてのシステム開発はこれからもあるのでしょう。現状維持のためのシステム開発と業務を変革させていくためのIT利用という大きく２つの目的は、それぞれの導入手法が異なっていくのではないかと思います。特に後者においては IT関連企業の役割も変わっていくことになるでしょう。
目次
１．従来のシステム開発とは
２．BPM導入の主役は、BPMを導入するユーザー組織である
３．IT業界の人材マネジメント
４．まとめ
１． 従来のシステム開発とは
従来のシステム開発とは、RFP（提案依頼書）をユーザー企業がシステム会社に提出し提案・見積から依頼先を決めて発注する。その後、要件定義→基本設計→詳細設計→製造・テスト→納品という流れと言えるでしょう。やや順番が異なる、要件の精度が異なるもののウォーターフォール（順次開発）であろうがアジャイル開発（作りながら考える開発）でも同じだと思います。 「BPMはアジャイル開発だ。」などと言っている時点で、BPMの失敗の始まりと言えるでしょう。
従来の業務システム導入でもパッケージシステムをカスタマイズすることなく、そのまま使うのであれば多くの問題は発生しないでしょう。カスタマイズで発生する多くの問題は、限られた時間の中で実務担当者ではないシステム開発者が実務の細かな要件を詰め、正しく文書化できないことから発生していると言えるでしょう。それは手法の問題というよりも開発者の仕事ではないことを開発者が実施してしまっているという「分担の問題」から発生しているのではないでしょうか。そのことから納期遅れなどが発生させ、IT業界の開発者は過酷な環境での仕事を強いられていくと言ってもいいでしょう。
２． BPM導入の主役は、BPMを導入するユーザー組織である
システム開発者がBPMSの機能や設定を理解していても、BPMを理解していないと失敗をしてしまいます。BPMを理解するということは、システム開発者が「顧客の業務を完全に理解することを諦めること」だと言い換えてもよいでしょう。BPMが対象とする業務プロセスは、担当している実務者しか知らない業務、または同じ業務であっても実務担当者によってやり方が異なる業務です。これをシステム開発者が実務の中に入り込んで理解し調整することができるでしょうか。できたとしても、それだけで大変な工数がかかることになります。そしてシステム開発者側が「結局、何を作ればいいですか？」と言った時点で失敗が見えてきます。そこで「主役はユーザー組織だ」と言うと、過去の「エンドユーザーコンピューティング（EUC)の失敗」といった話と「自社開発を勧めているのか」という極論が出てきます。
「EUCの失敗」に関しては、現在進行形でもあるRPAでも発生していることかもしれません。BPMとEUCの違いは「見えるか、見えないか」です。EUCもRPAも「見えない管理」です。見えない管理は他の誰かが同様のアプリケーションを作っていても、別に新たに作ってしまう。また野良アプリケーションが出来てしまい、作った本人が異動や退職などでいなくなると変更、維持管理ができなくなるという問題が発生します。
BPM導入が「自社開発」という短絡的な解釈も間違っており、たとえ自社開発であってもBPMは誰が何をするのかを切り分けることになります。組織によって異なりますが、細かな業務内容や業務の課題を知っているのは実務担当者です。システムの詳細を知っているのはシステム担当者です。「業務をどのように変革、改善させたいのか」は実務担当者間で議論し考え、その結論を「文書化」する。その文書をシステム開発者に伝え、実務担当者では実現できない技術的な部分を実施してもらう。という役割分担をすることです。そのことがビジネスアジリティ（内外の経営環境にすばやく適合する）を実現するという話は前回も書いた通りです。（ウォーターフォール型の開発であっても、同様でRFP作成において要件定義書、基本設計書並みに曖昧さを排除して記述することが大切です。）
その「文書」というのは、BPMにおいてはBPMN図とプロセスデータ関連表と言えます。（下図、前回と同じです。）これを実務担当者が使いこなすことができれば現状、業務システム開発で発生する様々な問題の多くが解決するでしょう。ERPなどのパッケージシステムをカスタマイズすることによって発生する問題の多くもBPMSを導入することで解決できることになるでしょう。そしてBPMSを使うことで実装プロセスが見え、実行状態も見え、その後の改善課題も見える（「BPMとは」参照）ということになります。
３．IT業界の人材マネジメント
私は、メーカー、経営コンサルティング会社、システム会社などを渡り歩きました。メーカーでは人を育成するという土壌があります。私はメーカーで沢山の教育機会をもらい、多くの業務改善（システム導入を含む）の経験をしました。経営コンサルティング会社は自分が持っている知識・技術を発揮する舞台であるため、踊るための素養や経験、勉強ができる人を集め、常に実践で学ぶという感じでした。システム関連企業は、そのどちらでもなく基本的なプログラミングの知識を教えたら「後は現場で何とかしてこい。」というような、やや乱暴なマネジメントであると感じました。「詳細設計書が存在し、それをプログラミングできればいい。」という人材育成しかできておらず、従業員に業務知識を習得させる、興味を持たせるということには、ほぼ無関心であると言ってもいいでしょう（そうではない会社もあると思います）。その人達に、ユーザー企業が業務改革や改善まで「丸投げ」していることが問題であると言えるでしょう。しかし「作る人は作るだけ」では進展がなく、「業務を改革し改善する」という目的を達成するために、互いに知識を共有し補い合う関係をBPMでは作っていく必要があります。その道具がBPMN、BPMSになると思います。
４．まとめ
BPM導入は従来の方法、考え方を変えなくてはならないです。それは、他のどれとも異なるからです。過去、セミナーを実施していると、メーカーまたはメーカー出身者の受講者にはBPMの考え方が、すんなりと受け入れられます。これは業務改革・改善経験をお持ちであり、その経験とBPMの考え方を置き換えて理解することができるからだと思います。サービス業やシステム関連企業の受講者の場合は、従来の考え方に縛られ「今までの枠」に入らないので理解に時間がかかる傾向にあります。最近は、セミナーがWEB会議システムでの実施が多いため、受講者の顔色がわからないのですが過去にはシステム関連企業の受講者の多くが 「納得できない」という顔をしていました。短絡的な帰結は「自分たちのビジネスではない」と思ってしまうことです。BPMが日本で普及・発展しない理由は
・ユーザー企業がシステム関連企業にシステム構築を通して業務改革や業務改善を丸投げしようとすること。
・システム関連企業が「作って納める」という枠から抜け出せないこと。
であると言ってもよいのではないかと思います。
前者は、他のコラムでもお伝えしているように、誰かに何かを頼むと夢のような世界がやって来るなどということはないです。製造業でいうと製造現場の改善を誰かに頼むと「できました」と「改善」が納品されると言っているようなものです。（この話は次回のコラムに続きます。）
後者は、今後「作って納める」ビジネスは徐々に縮小していくでしょう。そもそもノーコードやローコード開発ツールは、システム関連企業のシステム開発者の生産性を高めるためのツールではないからです。BPMを通して業務を理解し、業務改革・改善の支援ができる人材を育成することだと思います。（ここはユーザー企業の情報システム部門も同じです。）
書いたことは誤解され、なかなか理解されません。
BPMは実践することです。BPMコンソーシアムが「実践」を提唱しているのは、１プロセスでよいので正しく実践すると肌感覚でBPMが理解できるからです。BPMの実践というのは、ただBPMSを使って動かして「ご評価ください」というPoC（proof of concept:概念検証）とは異なり、正しい手順が必要です。正しい手順で実施をしないと単なるツール評価になり「BPMNの必要性・繋がり」や「なぜBPMSなのか」がわからないままになってしまいます。BPMコンソーシアムでは「BPMモデルプロセス導入支援」というサービスを提供しています。安価に正しい方法で、まずやってみることです。 正しい方法でBPMを導入をするとユーザー側もシステム開発側も改革・改善人材が育成されていきます。
