RPAとBPRの幸せな関係構築を
RPA（Robotic Process Automation)は様々な誤解と幻想を生みやすいITソリューションだと常々感じています。
経営者の誤解のパターンとしては、Robotという言葉が入っているので、そこから拡大解釈して製造現場や物流現場で動き回るロボットをイメージしてしまう「ロボット間違い」のパターンと、コンピューター上での人の作業を自動化するところは理解しているものの、万能AIが人間の業務を全て自動化してくれるという幻想や、特に銀行でのRPA導入効果をニュースで見て、自社でも大きな成果が得られるものと過剰な期待をするパターンがあるように感じます。
CIOや情報システム部長にあるパターンとしては、極度にRPAを嫌う「BPR絶対主義者」によるRPAディスりが良く目につきます。日経ITイノベーターズでRPAをテーマとしたディスカッションがあったのですが、「RPAの前にBPRが必要」という声が多くのCIOから上がりました。
「RPAの前にBPRが必要」という声そのものに何ら異論はないものの、RPAとBPRを語るときに「BPR絶対主義者」が陥る落とし穴について触れておきたいと思います。
BPRとはBusiness Process Re-engineering（ビジネスプロセス・リエンジニアリング）の略で、日本語にすると「業務改革」になります。BPRとは業務のあり方や手順を根本から見直すことです。末端の業務プロセスがRPAによって固定化されることを避け、業務の要・不要の判断から業務手順の最適化までBPRを徹底的に行うという姿勢には私も大いに賛成します。
一方で、BPRが対象とする業務プロセスとは、「Order-to-Cash」（注文から入金まで）といった部門横断業務です。顧客体験を中心に社内業務プロセスを横断的にデザインし直すような取り組みがBPRの１丁目１番地の取り組みだと思います。ERP導入の際には、まさにこういった広範囲のBPR実践が必要となるわけです。こうしたプロセスは繰り返し発生し、多くの従業員と顧客に関係する「基幹業務」であるため、たとえ1回あたり数分、数秒の業務合理化だとしても、企業全体では非常に大きな成果を生み出すことになるのです。
BPRは本来的に全体最適の取り組みであるため、個別プロセスを極度に嫌う傾向があります。またBPRは企業全体を対象に議論するために、ある部門のある担当者が月に1回だけ行うよう集計業務はBPRの議論からこぼれがちです。私自身ERPプロジェクトのリーダーを行い、企業横断的なBPRを行ってきましたので、ある意味懺悔的な告白になりますが、各部門の小さな業務プロセスは、往々にしてBPRが全社に投げる網の目からこぼれ落ち、「Excelで手作業でやっておいて」という結論に陥りがちです。「BPR絶対主義者」の心意気には賛同するものの、BPR実践の現実において網からこぼれ落ちる小魚のようなプロセスを救う手段としてRPAが補完的に使えることに安堵している自分がいることをここに告白しておきます。
もう一つBPR絶対主義者が陥る落とし穴ですが、これは日本でERPブームが起こった際にも発生した現象なのですが、ERPとのフィットギャップを行う際には、現行プロセス（As-Is）と将来プロセス（To-Be）を合わせてそのギャップを議論します。この時に「Order-to-Cash」といった大きな括りでプロセス最適化を議論すべきなのですが、「自社の受注画面ではAという情報とBという情報がすべて1画面で閲覧できるのに、ERPを導入するとAという画面とBという画面をそれぞれ閲覧しなければならないのは生産性が下がり問題だ！」という議論に陥りがちです。「日本企業あるある」なのですが、BPRが対象とするプロセスが、画面レベルでの操作性議論に終始してしまう傾向があるのです。こういうレベルでBPRを捉えてしまうと、まさにBPRとRPAが同じ次元に存在してしまうので、その結果がRPAディスりに繋がるのです。この様なケースでは、抽象度を上げ、解像度を下げ、より広範囲な領域を対象とするようにBPRが捉えるレベルを上に持ち上げることで、RPAとの交通渋滞を避けることが出来るのではないでしょうか。
BPRは戦略的、RPAは戦術的取り組みです。
BPRは高抽象化・低解像度、RPAは低抽象化・高解像度な議論。
BPRとRPAでは対象とする業務メッシュの粒度に違いがあります。
その一方で、現場でRPAを実践している人にあるパターンとしては、RPAに過度な期待を抱く「RPA万能主義者」の存在も気になるところです。これは、一見その方が特定のRPAツールの信者としてファナティックにモンスター化したように見えるのですが、実態は情報システム部門のサポートが得られない状況下において、現場の業務合理化を必死で進めている中で生み出されたものであり、こういうケースこそ情報システム部門が大いに反省しつつ「RPAの前にBPR」と叫びながら現場に手を差し伸べるべきでしょう。RPAをディスるCIOは往々にしてこのようなケースを問題にしています。そういった意味でのRPA化批判は私も大いに賛同するところですが、批判の矛先はRPAツールではなく、だらしのない自社の情報システム部門に向かうべきでしょう。この場合の批判の対象は「RPA」でなく、「RPA化」ですので。
最初は朝会社に出社した際に実行するエクセルのマクロをRPAで自動化するところから始まり、その元情報生成プロセスをRPAで自動化し、最後には一連のプロセスを時間起動で自動実行するところまで高度化する。その一方で実行処理時間には日によって差が発生するので前処理と後処理がうまく繋がらないところの微調整を始める｡こうしたケースではしっかりとしたバッチ処理をシステム化した方が良いのですが、情報システム部門が目の前に差し出した「御見積書」の金額に腰を抜かしてシステム化を断念する、というのが現場の日常風景ではないかと思います。このようなケースでは、先ずはRPAで実装し、その結果を踏まえてBPRと新しいシステムで巻き取るような発展形態がすでに大企業では生まれつつありますが、私はこれをBPRの敗北ととらえるのではなく、RPAとBPRの一つの幸せな関係としてポジティブにとらえています。
私としてはどっちが先か、どっちが偉いか、という議論は横において、現場にある現実課題を解決するために、RPAとBPRの幸せな関係構築を願うばかりです。
RPAに関してはコミュニティ活動も活発に行われており、私も先日Automation Anywhereを使う人たちの集まるコミュニティイベントに参加しました。是非社外のコミュニティに参加して、RPAには何が出来て、自社としてRPAに何を期待すべきかを考えるきっかけを持ってもらえればと思います。
この記事が気に入ったらサポートをしてみませんか？