BPMの「業務の標準化」を「共通化」と混同してませんか？

　
　今回はプロセスマイニングツールに関しての話を書く予定だったのですが、少し心配な出来事があったため今回のテーマに変更しました。

　過去のお客様と話をしていても「業務の標準化」という言葉の意味が中々、理解していただけませんした。業務の「標準化」と「共通化」を混同されており、話が平行線になりました。このときは、そのお客様の個人の問題かと思っていました。ところが今年、セミナーでも同様の混合をされていて、かつ説明しても納得した顔をされない受講者がいらっしゃいました。さらに後日、その同じセミナーに参加されたいた別の方が「自分の会社でも『業務の標準化』という話が通じない。もしかしたら作業、業務の標準化というのはトヨタ用語なのか。同じメーカーなのに話が通じないことに驚いた。」（この受講者はトヨタ出身で別のメーカーに転職されている）と言われていました。私も食品会社の中でトヨタ生産方式を導入するという仕事を１０年以上行っていたので「標準化」が何を表すかは「当たり前」だと思っていました。日本は、この３０年で世界の製造業に影響を与えたトヨタ生産方式すら知らない、という人を増やしてしまったのでしょうか。
　過去６年間のセミナーの中でも「共通化」と「標準化」を混同して理解していた人がいるのではないかと不安になったため、ここで説明をしたいと思います。

　この混同は従来のITシステムに関わっていた方々に多いのかと思います。前回のコラム（BPM導入が「いつの間にか普通のシステム開発」になる原因）と深い関係があるため、引用しながら説明をしたいと思います。

目次
１．「業務の標準化」と「共通化」
２．作業プロセスの自動化の限界
３．BPMは実務者主導の業務改善
４．まとめ

１．「業務の標準化」と「共通化」

　「標準化」とは、前回のコラム（BPM導入が「いつの間にか普通のシステム開発」になる原因）の図の第二階層で実現する「業務の標準化」になります。ここは同じようなプロセスであったとしても「部門によって異なる」プロセスに変更されます。
　ここでの「部門によって異なる」というのは、支社・支店での営業プロセス、調達部門における調達プロセス、開発部門での開発プロセス、工場での生産管理・品質管理プロセスなど全社で統一したプロセスでは無く「各拠点によって異なる」ということです。
その理由は
・同じようなプロセスであってもタスクを実行する役割（すなわちBPMN図のレーン）が異なる。
・部門によってローカルルールが存在し画面で制御する条件が変わる（すなわちユーザータスクの内容変更）、制御する条件によってゲートウェイの分岐が変わる。
などということが発生するからです。
　
「共通化」とは第三階層の「作業の自動化」（作業プロセス）（コラム「プロセス管理」という言葉に騙されることなかれ。BPMにおけるプロセス管理とは。参照）を、どの部門（拠点）でも使えるようにすることです。
　各部門（拠点）の要求を全て満たすシステムを第三階層で作り出そうとすると、私を含め基幹システムの導入の経験者は「共通化」には限界があると感じたことがあるでしょう。（共通化と標準化を混同しているために、それを「標準化ができない」と言っているＩＴ技術者がいるような気がします。）

「共通化」の限界とは、
・どの部門（拠点）でも使えるように「共通化」するためには、非常に複雑なロジックを組み込むことになる。
・複雑なロジックに対応するために画面も複雑になる。
・その複雑なロジック・画面は内外の環境変化に対応して、素早くメンテナンスをする必要がある。

　この３つを実現することが事実上不可能であるために「共通化」を諦めることになるでしょう。基幹システムで共通化できるのは、下図の例のように、どの部門、どの業務でも節目で使用する機能に限定されることになります。

　

２．作業プロセスの自動化の限界

　過去には、ホストコンピュータに実務者からの改善要望を受けて多くの年月をかけて、この複雑なロジックを組み込んでいくということが行われていました。１９９０年代には「ダウンサイジング」というIT業界の流行語で、ホストコンピュータで何もかもを処理するのではなく、各拠点ごとに「ミニコン」と呼ばれる小型の汎用コンピュータやWindowsなどオープン化された小型コンピュータで、その拠点に適したシステムを作るということで分散させ負荷・複雑さを解消するという考え方がありました。しかし、どちらにしてもロジック、画面、帳票が、なぜそのように作られているのか（そうする必要があるのか）ということがプログラムソースを読まないとわからないという「ビジネス（業務）知識の埋没」が起きました。そのために拠点ごとに作られたシステムの「維持管理が困難」、または「維持コストが上昇」するという問題が発生しました。
　私が過去、ＥＲＰ導入の仕事をしているとき、スクラッチで作られたシステムの、たった１枚のＡ４帳票をＥＲＰで作るための設計に１か月以上の時間を要したことがありました。帳票の一つ一つの表示項目の意味、その項目にどういったときに何が表示されるのか。表示された項目を、どの部門の人が、どの項目を見て何を判断し作業するのか。などなど・・プログラムソースを読んで、条件式はわかっても「なぜ」がわからず・・それをすべて知っている人は１人しかおらず大変な苦労をしました。

その後、
・ERP（業務統合パッケージシステム）導入を機に、それら長年に渡って作ったシステムを捨てる。
・捨てられず（何を捨てるか、残すかの判断ができずに）にスクラッチで開発したシステムを高額なコストで維持している。
・高額な投資をしてERPを改造して作り直す。
・ERPと何らか開発ツールを連携させて実現させる（BPMSをこのような使い方をすると勘違いしている人が多いです。）
というようなことになっているかと思います。　

　すなわち第三階層の「作業の自動化」（作業プロセスの自動化）では、どのような方法であったとしてもBPMでいう第二階層の業務改善レベルを実現することは困難であるということが過去の事例からわかると思います。（不可能という話ではありません。多数の人員を投入して多額の維持コストをかけ続ければ可能だと思います。）

３．BPMは実務者主導の業務改善

　実務者は、自分の部門での「業務改善の視点」からIT部門に要求します。しかしながら「IT部門が要望通りに動いてくれない」というような不満を良く聞きます。その原因を「現場の業務を知らないからだ。」というようなことから批判を浴びるということがあります。（情報システム部門長だった私の経験からでもそうでした。）
　IT部門が現場要望に答えたくとも、簡単にできないのは前述した通りです。そもそも基幹システムで業務改善を実現するのは困難さを伴います。実務部門から言われた通りに基幹システムの改造をすると、「ビジネス（業務）知識の埋没」や「高額な維持コスト」などという問題を再度、発生させてしまうからです。
　「実務者が自分で第三階層の『作業（プロセス）の自動化』をすれば良いのではないか。」ということで、現在、多くの会社で「リスキリング」と称して実務者に対してローコード、ノーコード開発ツールの研修をしているようです。第三階層を対象としている限り「見えない管理」から「ビジネス（業務）知識の埋没」ということが発生してしまうのではないでしょうか。RPA（Robotic Process Automation）が大流行していたときも「ノラロボ」が問題になったと思います。
　第三階層（作業プロセス）の自動化が「悪」だと言っているのではなく、第二階層から「見える」管理をしコントロールする必要がある。ということを言っています。

３．まとめ

　BPMは実務者が作成した第二階層のBPMN図を実装したBPMSで部門（拠点）の業務が標準化、効率化するように管理することです。第三階層の「作業の自動化」はIT担当者・技術者が管理（誰が作るかという話では無いです）しますが、第二階層のBPMN図、及びBPMSの管理は実務者が行います（BPMの改善ステップ５まで：ＢＰＭの改善ステップ参照）。各部門（拠点）で実務者が中心となって第二階層から管理することで第三階層の複雑なロジックは無くなっていき共通化できます（コラム：BPM導入が「いつの間にか普通のシステム開発」になる原因）。すなわち、これこそが「ITからビジネスへの権限移譲」でありBPMNの重要性（BPMNが必要になる理由）になります（コラム「あなたが描いているのはBPMN図ではありません」の図を参照）。
　
　BPMを正しく理解するためには「実践」が必要です（モデルプロセス導入支援サービス参照）。実践するため従来の考え方が「壁」になります。（コラム：ＢＰＭの理解を阻害する業務フローとシステムに関する固定概念）
　その壁を乗り越えないと時間の経過と共に変化していく業務の中の瞬間の作業の効率化はできたとしても、長期の業務プロセスの効率化改善は実現しないでしょう。

関連ページ