【NEW IT, NEW ITIL】RPAとキャパシティ管理、ITサービス継続性管理：RPAが止まったときを考える
RPA（Robot Process Automation）の言葉は日を追うにつれてますます見かけるようになり、RPAはなんだかすごそうだ、というムードが高まっています。
RPAでコスト削減できる、というムード
「RPAを導入すればあらゆる業務で人の数を減らせる！」と短絡的に考える人はさすがにいませんが、「定型業務に関わる人数が減って確実にコスト削減できる」と思っている人は少なくないでしょう。事実、多くのRPAベンダーがコスト削減を前面に押し出していますし、Webで見かける先進事例もそのことを謳っています。
Volvoでは経理業務でRPAを導入し、請求書突合作業を自動化しました。これによって、同作業に係るヒューマンオペレーション量は75%も削減したとのこと。
他にも、次のような事例が発表されています。
- 日本生命では、1件あたり数分かかっていた作業にRPAを導入し、20秒程度で処理。
- 三菱東京UFJ銀行では、20種類のRPA導入により8,000時間分の事務処理作業を削減。
- オリックスグループでは、4人分の仕事を代行できるロボットが1週間で完成。
- ユニリーバ・ジャパンでは、人力では3人で7日かかる作業をRPAが半日で完了。
EYアドバイザリー・アンド・コンサルティング『ロボティック・プロセス・オートメーション』
https://home.kpmg.com/content/dam/kpmg/cn/pdf/jp/2017/03/Appendix-01_jp-rpa-bpo-20160315.pdf
RPAテクノロジーズ『RPA導入事例』
http://rpa-technologies.com/about/
RPAの効果が出やすい領域は、次の図のとおりです。これにあてはまる業務はヒューマンオペレーションの比率を減らしやすいといえます。
RPAでコストが増えてしまった！？
しかし、「RPAを導入することでコストが増えてしまった」と嘆く組織も実際にはあります。彼らがRPAの導入を決めた業務は、別に上述のルールに反していたわけではありません。ちゃんと定型化された業務を選んで自動化していましたし、例外データが大量であったわけでもありません。むしろ、作業発生回数は多く、1作業あたりの業務量も多かったといえます。
これだけRPAに適した業務で、なぜ想定外のコスト増が生じてしまうのでしょうか。
ITILの観点で分析すると、実は「キャパシティ管理」と「ITサービス業務継続性」の２点が複合的に絡むことで問題になりやすいのです。
自動化で要員数が激減した業務、もし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の方がつらい
一日中エラー無しで動き続けるRPAプロセスは珍しいでしょう。ほとんどのRPAプロセスは何度もエラーを検知し、その処理をヒューマンオペレーションで対応します。この頻度が多い業務ほどリカバリー要員が常時必要になるため、RPAが動かなくなったときの業務継続性は高いです。
しかし、めったにエラーを吐かないRPAは、そうした要員を常時抱える必要はないため、いざというときにリカバリーに入れる要員数が確保できません。こうした業務は、業務継続性を確保するために、従来の人員を別の業務にわりあてるなどして、リカバリー体制を確保する必要があります。複雑なルールをうまくRPA化できた業務は、こうした必要性はさらに強まります。
ITILで代替リソースの確保、復旧時間を順守するための保守体制を考える
ITILによるサービス管理を高度化すると、キャパシティ管理として、システムリソースだけではなく、ヒューマンリソースも管理対象とすることができます。業務単位で発生工数を管理しておくと、その業務がRPA化された際、どれほどのオペレーション工数が削減できそうか予測できるでしょう。
また、ITサービス継続性管理として、RPAが止まってしまった際のリカバリー方法として、手作業によるリカバリーを選択した場合にどれくらいの工数を必要とするか、そのために必要な副担当者をどれくらい確保すべきか検討することができます。
これらは、RPAが正常に動くようになるまでのリードタイムを決める要素にもなりますし、そのリードタイムを短縮するために定常的に抱えるRPA保守メンバー（RPA技術者）の人数をどれだけ増やすか検討する材料にもなります。
RPAを導入した経験のある人はわかると思いますが、ちょっとした変化でRPAはすぐにエラー終了します。
- 画面レイアウトが変わった
- データ構成が変わった
- セキュリティパッチが当たった
- RPAが動くPCの処理スピードが変わった
このような「ちょっとした変化」で止まってしまうのが現在のRPAです。成功例に挙がっている企業は、こうした点を吸収できるプロセス設計や保守体制を確立しているものと推察されます。開発フェーズだけではなく、運用フェーズの取り扱いを熟考する必要があるため、ITILにもとづく運用設計はRPAに必須であるといえるでしょう。