ホーム > mixiニュース > IT・テクノロジー > エンタープライズ > RPA導入でコストが増えた? そんな事態を避けるには

RPA導入でコストが増えた? そんな事態を避けるには

2

2017年08月10日 11:24  ITmediaエンタープライズ

  • チェックする
  • つぶやく
  • 日記を書く

ITmediaエンタープライズ

写真画像:ITmedia
画像:ITmedia

 最近注目されているRPA(Robotic Process Automation:ロボティクスプロセスオートメーション)について、ITIL(Information Technology Infrastructure Library:ITサービスマネジメントのフレームワーク)の視点から考えます。


【拡大画像や他の画像】


 最近、RPAという言葉は、日を追うにつれてますます見かけるようになり、「RPAはなんだかすごそうだ」というムードが高まっています。


●RPAでコスト削減できる、というムード


 「RPAを導入すればあらゆる業務で人の数を減らせる」と短絡的に考える人はさすがにいませんが、「定型業務にかかわる人数が減って確実にコスト削減できる」と思っている人は少なくないでしょう。事実、多くのRPAベンダーがコスト削減を前面に押し出していますし、Webで見かける先進事例もそれをうたっています。


 Volvoでは経理業務でRPAを導入し、請求書の突き合わせ作業を自動化しました。これによって、同作業にかかわるヒューマンオペレーション量は75%も削減したとのことです。


 他にも、次のような事例が発表されています。


・日本生命では、1件あたり数分かかっていた作業にRPAを導入し、20秒程度で処理。


・三菱東京UFJ銀行では、20種類のRPA導入により、8000時間分の事務処理作業を削減。


・オリックスグループでは、4人分の仕事を代行できるロボットが1週間で完成。


・ユニリーバ・ジャパンでは、人力では3人で7日かかる作業をRPAが半日で完了。


 RPAの効果が出やすい領域は、次の図の通りです。これに当てはまる業務は、ヒューマンオペレーションの比率を減らしやすいといえます。


※参考:EYアドバイザリー・アンド・コンサルティング『ロボティック・プロセス・オートメーション』、RPAテクノロジーズ『RPA導入事例』


●RPAでコストが増えてしまった!?


 しかし、「RPAを導入することで、コストが増えてしまった」と嘆く組織も実際にはあります。彼らがRPAの導入を決めた業務は、上述の条件に反していたわけではありません。ちゃんと定型化された業務を選んで自動化していましたし、例外データが大量であったわけでもありません。むしろ、作業発生回数は多く、1作業あたりの業務量も多かったといえます。


 そんなRPAに適するはずの業務で、なぜ想定外のコスト増が生じてしまうのでしょうか。


 ITILの観点で分析すると、実は「キャパシティー管理」と「ITサービス業務継続性」の2点が複合的に絡むことで問題になりやすいのです。


●自動化で要員数が激減した業務、もしRPAが止まったら?


 例えば、ある部署で100人でやっていた業務に対して、RPAを導入して人数を80%削減できたとしましょう。RPA導入後に部署内に残った要員は20人です。人件費を大きく減らすことができました。


 このRPAには、プロセスの途中で「Office 365」の「Outlook」によるメール送信というタスクが含まれています。今までは100人がOutlookを立ち上げて、それぞれがメール送信を行っていたところを、RPAでは数十台のマシンが自動的にOutlookを立ち上げてシステマチックにメール送信をするようになりました。


 ある日、Office 365のサービスアップグレードにより、Outlookの画面に新しいボタンが自動的に表示されるようになりました。すると、ルールベースで動いていたRPAツールは画面の変化を正しく認識できず、エラーを吐いてOutlookでメールが作成できなくなってしまいました。


 RPAが止まっても、業務を止めるわけにはいきませんから、残った人員が手作業でリカバリーするしかありません。となると、かつて100人でやっていた業務を20人でやりきらなければならないということになります。これは物量的に無理です。直ちにリカバリー用の臨時要員を雇わなければなりません。


 テンポラリーで急きょ人を雇うのはコストが高くつきますし、かつての100人よりも作業習熟度は低いですから、人数をさらに増やして対処しなければ間に合いません。RPAの自動化プロセスが正常に動作するようになるまで、非常に高いリカバリーコストを支払うことになります。


●頻繁にエラーを吐くRPAよりも、めったにエラーを吐かないRPAの方がつらい


 1日中エラーなしで動き続けるRPAプロセスは珍しいでしょう。ほとんどのRPAプロセスは、何度もエラーを検知し、その処理にはヒューマンオペレーションで対応します。この頻度が多い業務ほど、リカバリー要員が常時必要になるため、RPAが動かなくなったときの業務継続性は高くなります。


 しかし、めったにエラーを吐かないRPAは、そうした要員を常時抱える必要がないため、いざというときにリカバリーに入れる要員数が確保できません。こうした業務は、業務継続性を確保するために、従来の人員を別の業務に割り当てるなどして、リカバリー体制を確保する必要があります。複雑なルールをうまくRPA化できた業務は、こうした必要性はさらに強まります。


●ITILで代替リソースの確保、復旧時間を順守するための保守体制を考える


 ITILによるサービス管理を高度化すると、キャパシティー管理として、システムリソースだけではなく、ヒューマンリソースも管理対象とすることができます。業務単位で発生工数を管理しておくと、その業務がRPA化された際、どれほどのオペレーション工数が削減できそうかを予測できるでしょう。


 また、ITサービスの継続性管理として、RPAが止まってしまった際のリカバリー方法は、手作業によるリカバリーを選択した場合にどれくらいの工数を必要とするか、そのために必要な副担当者をどれくらい確保すべきかを検討することができます。


 これらは、RPAが正常に動くようになるまでのリードタイムを決める要素にもなりますし、そのリードタイムを短縮するために定常的に抱えるRPA保守メンバー(RPA技術者)の人数をどれだけ増やすかを検討する材料にもなります。


 RPAを導入した経験のある人は分かると思いますが、RPAは、ちょっとした変化ですぐにエラー終了します。


・画面レイアウトが変わった


・データ構成が変わった


・セキュリティパッチが当たった


・RPAが動くPCの処理スピードが変わった


 このような「ちょっとした変化」で止まってしまうのが現在のRPAです。成功例に挙がっている企業は、こうした点を吸収できるプロセス設計や保守体制を確立しているものと推察されます。開発フェーズだけではなく、運用フェーズの取り扱いを熟考する必要があるため、ITILに基づく運用設計は、RPAに必須であるといえるでしょう。


あなたにおすすめ

このニュースに関するつぶやき

  • RPAというのは、要するにゲームで言うところのマクロによる自動化ですね(+_+)☆\バキッ だからちょっとした仕様の変化や、ひどい場合パソコンの処理速度の違いで、停まってしまう。
    • イイネ!5
    • コメント 4件

つぶやき一覧へ(1件)

ニュース設定