RPAの導入にはプログラムを一切書く必要がないため、過去のEUC（End User Computing）の時と同じ過ち（Excelレガシー問題と言われています）同様の状況に陥るのではないか、と懸念されています。
これを避ける為には、IT部門や経営企画が当初から統制し、業務フローを整理した上でRPAに任せる単純繰り返し作業を切り出します。こうしてPCで行っている繰返し雑務を自動化し、ホワイトカラーは考える業務に専念できるのです。
この辺りのPAを実際に導入していこうとした場合に考える必要がある、「どこの部門から始めるべきか」「対象業務をどの様に選定するのか」などの進め方についてご紹介しています。
RPAに向いている業務とは
システム化し難い業務
業務を棚卸・整理すると、「固まった仕事」と「やわらかい仕事」に分類できます。言い方を変えると、次のようにも言えるかと思いますが、下記「１．固まった仕事」はシステム化に向いていますので、従来のサーバー型のシステム開発として進めるべきです。
- 過去に起こった事実 ≒ 固まった仕事
- 将来に向けた仕事 ≒ やわらかい仕事
◆ システム化し易い業務
上記１．は過去に実際に起こった事実ですから、今更変えようがありません。これを曲げて記録すると、経理・財務で言えば脱税、粉飾になってしまいますから、正しくERP等に会計転記していくしかないのです。
従って、このような固まった仕事はデータの形（≒テーブル構造）や処理ロジックを定義し易いと言う特徴を持ちますのでシステム化し易いのです。処理の頻度や処理量にもよりますが、この様な固まった仕事は極力サーバー型のシステム開発として要件を取り込むのが良いかと思います。
◆ システム化が難しい業務
上記２．は将来に向けて計画を作成し、いかにその計画通りに事業・業務を円滑に進めるか、が重要となりますので、将来に向けた付加価値の高い仕事として本来ホワイトカラーが行うべき業務なのだと思います。
いわゆる「考える仕事」です。しかし、この様な仕事は概してデータの形や処理ロジックを一意に決める事が難しく、例外処理が多い柔軟な対応を求められる仕事になってきます。
考える部分は当然人がやるしか無いのですが、この様な仕事の中にも小規模ながらPCでの繰り返し処理が多く含まれ、多くのホワイトカラーがこのPC雑務に時間をとられている、と言うのが現実なのです。
- 大規模システム開発には向かない柔らかい仕事
- 大規模なシステム開発をするほどの処理量、繰り返しがない
- 業務の状況変化に応じて柔軟に、小回りを利かせる必要がある
この様な業務が正にRPA化すべき対象業務なのです。
システムの間、業務の間をつなぐ業務
RPAであれば、もっと身近に現在の業務からRPAに任せるPC雑務を切り出し、自動化するのは然程難しい事でもないと思います。プログラムなど一切書けなくても、その気になれば業務部門自身で作成する事が可能です。
これらの将来に向けた仕事はやわらかいだけに、決まった形にすることが難しく、考えながら作業するため、そのままRPAに任せるには無理が有ります。私は、この１業務と業務の間を繋ぐ、もしくはシステムとシステムをつなぐのにもRPAは適していると思っています。
- 基幹システムに需要データや受注伝票、請求書などを投入する
- CRMから抽出した受注伝票をERPに投入する
- インターネットで顧客情報を検索し、マスターとして入力する
- CRMから顧客マスターを抽出し、成型レポートする
など多々考えられるかと思います。
パイロット導入に向いている業務部門
RPA化の対象とする業務のイメージとしては上記の通りですが、それでは社内のどこの部門から始めるべきかと言う問題があります。通常、パイロット導入、または最近はPoC（プルーフ・オブ・コンセプト）と呼ばれる事も多いかと思いますが、その業務（部門）選定の考え方としては２通りあります。
先ずはIT部門で使ってみる
RPA化の対象として先ず考えるのが業務部門ですが、実はIT部門もITに関する事務処理が結構あり、１つの業務部門と見る事もできます。そして、IT部門にはこれらのITツールを使うのに慣れたユーザーがいますので、自分達でRPAシナリオ程度は作成可能と思われます。
IT部門でのRPA導入イメージも含め、部門別のRPA導入事例をこちらでご紹介しています。
それでは、IT部門で先ず使ってみるアプローチのメリットとデメリットとはどの様なものが考えられるかと言うと、
【メリット】
- 自分達でRPAシナリオを作成し、ノウハウを蓄積できる
- 当初からRPA仕様をドキュメント化する準備ができる
- 全社展開のイメージを持ち、計画策定ができる
- RPAシナリオの標準モジュール・部品化のイメージができるため、後々のRPAシナリオ作成の生産性、保守性を向上できる
【デメリット】
- IT部門での業務効率化効果を業務部門の方がイメージ・理解し難い
- 全社展開する場合、対象業務部門を改めて選定する必要がある
- 業務部門の方かあ見ると、「IT部門だからこれ程の効率化が低予算で出来た」と見られる
効果が高い部門でパイロット導入する
こちらのほうが通常の考え方かとは思います。RPAの全社展開を考えると業務効率化の効果を最大限にイメージ・定量化し、全社展開に向けてアピールします。
【メリット】
- 業務効率化の効果を定量化し易い
- 効率化の効果を全社にアピールし、はずみをつける
- 対象業務自体に精通しているため、RPAシナリオ作成がやりやすい
- 業務部門の協力を最初から得ているため、その後の体制を組みやすい
【デメリット】
- パイロット導入の当初はIT部門ほどITツールに慣れていない場合が多い
- 現在の業務をやりながらRPAプロジェクトに時価を割くため、一時的に残業対応や要員調整が必要になる
- 自部門に閉じた自動化になりがちで、周辺業務を含めた自動化に広がり難い
過去のEUCの反省を踏まえ全社展開する
社員個々人が自分の業務の内、PCで行っている単純繰り返し作業をRPAにそのまま置換えることも当然可能ですが、これでは効果も限定的ですし、IT部門としては、過去に流行ったEUC（エンドユーザー・コンピューティング）と同様の課題を抱え込む結果となりかねません。予想されるのは
同じような業務をやっているRPAロボットが社内で増え続け、その数さえ押さえられない。社員が異動・退職したりすると引継ぎも出来ず、ドキュメントも無いためその業務自体がブラックボックス化し、管理管理不能状態に陥る。
誰も何処にどんなノーツDBが有るか解らないため、ユーザーは個々に自分が必要なDBを新たに作成していった結果、同じようなノーツDBが増え続け、どれも各社員の業務範囲に閉じているため、会社全体の正式なDBにするには不足する項目が多く、仕様も判らない状況となって行ったのと同様の流れです。
正にEUCともてはやされたExcelマクロやノーツDBの状況です。同様の状況となる事だけは避けなければいけません。
グループ内のRPAに向いている業務を集約化
業務部門が主導してRPAを導入するにしても、やはりIT部門が当初から統制していく事が必要と思われます。それは、将来AIをその業務に適用していくためのデータ整理・蓄積にもつながる非常に重要な部分となります。
グループ横断で業務プロセスを棚卸する
グループに多数の会社を持ち、そこに経理・財務や人事、総務などの間接部門を持っている会社であれば、殆どの会社で共通化出来る業務プロセスがあります。
なぜなら、これらの間接業務は会社が扱っているサービスや商品、グループ内での位置付けなどに関係なく、殆ど同じだからです。逆に販売、生産、商品開発などの直接部門はグループ横断で同じ業務は殆ど無いと思われますので、会社単位で業務フローを整理されるのが良いかと思います。
なぜなら、業務内容や役割が違うから会社を分けているのであって、そこが重複しているのであれば、会社の形から再整理するのが良いと言うことになってしまいます。
グループ各社の現状の業務プロセスを棚卸してみると、結果的に殆ど同じ単純作業をしている社員が各社にいる事に気付くはずです。
並べてみると意外に同じ作業が多い
それらのグループ各社の同様の仕事を業務の流れとして並べてみて、要素に分解します。そして、今度は横に切ってみるのです。そうすると、同じ業務のみをまとめることが出来ます。
業務を行っている順番やタイミングが違う可能性は十分にあります。または、前後に他の付随作業があったりするかも知れません。そのような場合はそれらをRPAで実行出来る単純繰り返しになるまでまた分解していきます。
同じ単純繰り返し作業を切り出す
これらの単純繰り返し作業のみを集めてRPAに任せれば良いのです。その様な単純作業をどこかの関連会社にまとめて管理するのも良いかと思います。これで、社員の方々の業務は楽になるはずです。
そして、本来ホワイトカラーが行うべき、上記２．の将来に向けた考える仕事に専念出来て、毎日残業しなくても定時に帰宅しても十分なパフォーマンスをあげることが出来るようになるはずです。
RPAには向かない業務もある
ITツールを含め全ての道具には想定した用途があります。RPAの場合はPCを使って人が行っている繰返し単純作業を代わりに行うことです。従って、複雑な判断が入り作業が細分化されるような業務には基本的に向きません。
その辺りをこちらでご紹介しています。
