RPAとはRobotic Process Automation(ロボティック・プロセス・オートメーション)の略語で、パソコン上の定常業務を自動化するソフトウェアのロボットです。近年、DX推進や働き方改革、コスト削減などを目的に注目が集まりましたが、なかなか運用に定着しないというケースも多くあります。
RPA導入の成否の分かれ道は何なのでしょうか?
ビジネスの成長に伴い比例して増加する業務量。人口減少時代の今、増員によってこれを賄うことが徐々に困難な状況になってきています。一方、2019年4月より改正労働基準法が施行され、従業員の長時間労働の規制および罰則の強化、さらに年次有給休暇取得の義務化など、ワークライフバランスを重視し、長時間労働による業務量の増加への対応も困難な状況となっている今、業務を自動化することで人の負担を減らすRPA(ロボティック・プロセス・オートメーション)などのテクノロジーが急速に普及しています。
RPAは、人によるコンピューター操作をそのまま自動で実行する技術であることから、従来のプログラミングによってシステム化する場合に必要な専門知識を必要としません。そのため、事務・業務処理を気軽に効率化・自動化できる方法として急減に導入が広がっています。 RPAの導入により、年間で8000時間の事務処理を自動化する(※)など成功事例が好評されています。
その一方で、パイロット的に導入した業務では効果があったものの、それ以上の効果が発揮されなかったり、業務効率化には貢献したがRPA環境そのものの管理にかえって工数が増加したなど、想定されるほどの効果が出ないケースも増加している状況です。
RPA導入の成否の分かれ道になる課題や問題点について2つのポイントを紹介します。
※引用元:総務省「M-ICTナウ vol.21 2018年5月第2号 ICTトピック『RPA(働き方改革:業務自動化による生産性向上)』」(2020年1月28日)
現状のRPAは、どのような業務であっても適用可能・効果を発揮できるようなものではなく、適用して効果が出やすい性質の業務/効果を発揮しづらい業務の傾向が実際には存在します。
これらの特徴を踏まえず、闇雲に適用する業務を決めてしまうと、想定したような効果が表れない恐れがあります。
RPAを適用して効果が表れやすい業務の性質として、一つが比較的単純で、複雑な判断を伴う条件分岐などが存在しない業務であることです。
処理の途中で単純な条件式では表せない、人による判断が必要なものは、途中までの作業は自動化できても、完了するには必ず人の介在が必要になります。業務の流れが条件によって複雑に分岐したりする性質の業務については、傾向としてシナリオの変更頻度が高く、メンテナンスに負荷がかかる恐れがあります。
そして2つ目は、その業務の実行頻度が高く、繰り返し実行されている業務であることです。もちろん実行頻度が低くても、RPAをうまく適用することで一定の効果にはつながりますが、ロボットに自動実行させるためのシナリオ作りには、実行頻度に関係なく、一定の工数がかかります。そのため、頻繁に実行される業務に適用した方が効果は高くなります。
業務の棚卸の結果、比較的単純で実行頻度の高い業務を洗い出してRPA適用対象として決定し、そのままの業務の流れをRPAのシナリオとして適用しても、思ったような効果につながらない場合があります。
その大きな理由が、人が行う際のプロセスが、RPAで実行する際の最適なプロセスとは限らない点です。
例えば適用業務の性格上、どうしても例外処理が必要で例外として判定した場合の対応はRPAの適用が難しいです。人による操作が必要な場合、例外の判定をプロセスの比較的前の段階で行う現状のプロセスのままRPAを適用してしまうと、例外判定後の人による操作が相対的に増加し、RPAによって自動化できる業務の範囲が狭くなってしまいます。
RPAに適用する前にプロセスを見直し、仮に例外判定をプロセス後の工程に変更し、例外判定前に処理できる部分を実行した上で、判定させるようにすることができれば、相対的に自動化できる範囲が大きくなります。
RPA導入でうまくいかないケースの2つ目は、導入した直後には一定の効果を発揮し、各部門へ横展開をした後に起きる問題です。各部門でRPAを展開し、対象業務に適用したものの、いくつかの理由によって当初想定していた業務がうまく処理されず、適用をやめてしまったり、業務上まったく役に立たない処理を実行しているといったケースに陥ることがあります。
RPAに限らず導入したITソリューションが定着せず、利用されなくなってしまう失敗例は他の分野でもありますが、RPAの場合、業務プロセスに大きく依存する性質であることから、その影響が大きいことが特徴です。当初作成したシナリオがうまくいかなくなる理由には、以下のようなケースがあります。
例えば当初作成したシナリオが、発生する業務プロセスのあらゆるケースを想定しておらず、想定からはずれた場合に処理が止まってしまったりする問題が発生。結局続きを人が操作しなければならないばかりか、途中まで処理されていた内容の把握も必要なため、適用を中止し、従来通り人による作業に戻ってしまう。
シナリオ作成時と周辺環境が変わり処理プロセスが変わってしまった。当初は変更になった部分だけを手作業で修正する処理を行っていたが、変更範囲が徐々に広がり、結果として最初から手作業でやっても同じ工数がかかる程度まで増加し、適用を中止。
シナリオの作成や作成済シナリオの変更などの問題に対処していく担当者の配備が各部門で追いつかず、かといって情報システム部門ですべてのシナリオを管理することもできないなど、運用開始後を想定した体制整備が追い付いていないケースが、このような結果を招く場合が多い状況です。
尚、このような状態にならないようにすることも重要ですが、作成したシナリオを実行するロボットをしっかりモニタリングしておかないと、正常な動作を行っていないことすら気づかない、いわゆる「野良ロボット」を放置してしまうことに成りかねないことから、まずは導入後にしっかりとしたモニタリングの仕組みが必要と言えます。
業務効率化の切り札として急速に普及したRPAに顕在する課題に、エンカレッジ・テクノロジが開発・販売するモニタリングツール「ESS REC NEAO」が貢献します。
「ESS REC NEAO」は、コンピューターに対する操作の監視・記録を行うツールですが、その一つの適用場所は、RPA実行環境となります。下図が、RPA実行環境におけるESS REC NEAO適用概要です。
ESS REC NEAOの監視・記録エージェントをRPA実行環境に導入、RPA実行環境を監視・モニタリングすることで、以下のような課題を解決します。