■サイト内検索:
 

RPA Biz > RPA > 【導入事例】某大手生命保険会社のRPA導入事例

【導入事例】某大手生命保険会社のRPA導入事例

2018.10.10

大手外資コンサルファームに所属していた筆者が、

某大手生命保険会社にRPAを導入した際の導入事例・体験談をまとめます。

 

 

利用ツール

使っていたRPAツールは「Blue Prism」でした。

大手企業であれば、かなり値段は張るものの、機能性に優れる「Blue Prism」の利用は間違いありません。

 

クライアントが大手企業ともなると開発エンジニアがチーム体制を組むことが当然であるため、

「Blue Prism」の中央サーバー管理による開発は非常にやりやすくなります。

 

また、エンジニア目線から言って非常に取っつきやすいUIとなっているため、

習得の容易性が高いと言って差し支えないでしょう。

 

 

人員体制

PM 1名、PMO 2名、開発メンバー 10名程度のチームで1年間ほどで5~10業務程度をRPAロボット化しました。

 

1業務につき、1~3名のメンバーにて2ヶ月程度の期間が平均的であり、

業務量に応じて開発メンバーの多寡は加減されていました。

 

 

RPA化業務

主に顧客から日々送られてくる紙媒体に対する会社側のアクションを自動化したり、

基幹システムへの入力を自動化したりといったところでRPAを活用していました。

 

 

発生した問題や独特の創意工夫の必要性

RPAは情シス部門というよりも業務部門が窓口となることが多いです。

 

情シス部門がからむこともありますが、ほとんどサポートであったり、

アドバイザー的な立場でアサインされることが多いようです。

 

こういった場合に何が問題となるかというと、業務部門はあくまで業務のプロでしかないため、

システム的な理解度が低い可能性が非常に多いということになります。

 

要件定義から開発、テスト、受け入れまでのすべての工程において、

横文字や略語、専門用語を極力使わないといった配慮が常に必要です。

 

加えて、RPAでありがちな失敗かと思われますが、

RPA動作中のPCに対して、人が操作してしまってエラーが発生する、というような問題も発生しました。

 

RPA動作中のPC操作は、RPAでは基本的にNGとなります。

例外的に、人的判断を処理の途中に要する場合に限り、RPAロボとRPAロボの間に「人間の入力」などが入る場合もあります。

 

 

また、エラーで動かない場合のワークアラウンドも事前に手広く構えておく必要があります。

これも、先ほどの業務部門が窓口であることに起因していますが、

システム開発ではどのようなことに対してどれほどの時間や労力がかかるのか、といったことが全く理解いただけないため、

スケジューリングなどがすべてベンダーにかかっているような状態になりがちです。

 

「実はこういった作業をユーザー側にあらかじめてお願いしていなければならなかった」というようなタスクがあるものです。

代表例で言えば、UAT(=User Acceptance Test, ユーザー受け入れテスト)のデータ準備などが挙げられるでしょう。

 

紙媒体を電子化するにあたり、それをパンチングするパンチング業者との連携なども求められることがあります。

 

 

また、インシュアランスについては、インダストリーとしてバンクよりもセキュリティ面で厳しいということはないと思いますが、

やはり金融機関ではあるため一般企業よりは厳しいという印象です。

 

RPAロボット動作中に随時出力されるログに顧客情報を残さないことであったり、

テストなどで受領する保険の証券情報をベンダー側で見られないよう工夫していただく必要があるなど、

ところどころ独特の配慮が必要なことがあります。

 

 

おわりに

いかがでしたでしょうか。

生命保険会社のRPA導入に関する意見を拙劣ながら述べさせていただきました。

ご参考いただければ幸いでございます。

 

 

 

topへ
© RPA.biz