■サイト内検索:


RPA Biz > RPA > 保険会社へのRPA導入事例

保険会社へのRPA導入事例

2018.06.12

普段はRPAコンサルタントとして、保険会社の業務に対してRPA導入を行っております。

そこで今回は、実体験を基にした導入事例、導入において重要な事項、削減効果などを紹介させて頂きます。

 

# はじめに

RPA(Robotic Process Automation = ロボティック プロセス オートメーション)とは、

バックオフィスにおけるホワイトカラー業務など、

これまで人間が手作業で行ってきた業務を、ルールエンジン、機械学習、光学文字認識などの認知技術を取り入れたソフトウェアロボットに代行してもらうことにより、

業務の大部分における自動化や効率化を図る取り組みを指す言葉です。

 

# RPAツール

今回ツール選定から行いましたが、使用したのは「UiPath」になります。

費用や学習コストなどを総合的に見て判断しております。

 

特に、eラーニングが充実しているという点は、

チームにRPAを扱える人間を増やす場合にも手っ取り早く飲み込んでいけるところで大変優れておりました。

 

開発者が「UiPath Studio」でロボットの作成。

運用者が「UiPath Orchestrator」でデプロイ、ログ監視、バージョン管理などを行っております。

 

# 導入業務

 

  •  出社率管理
  •  住所変更の手続き
  •  控除証明書再発行
  •  データ不整合照合
  •  長期ペンディング

など

上記はほんの一部ですが、今後100業務以上にRPAを導入予定となっております。

 

# 導入事例

住所変更の手続き業務を対象とします。

年間変更件数が6~7万件ほど発生していたこともあり、非常にユーザー部門にとっては高負荷な業務の一つでした。

担当者の人数を単純に増やして対応し続けるのは現実的ではなく、

かといって新たな機能を基幹系システムに追加するのはコストと時間が掛かりすぎるといった懸念がありました。

 

また、そうしたコスト的懸念以外にも複数担当者が分担して進めている業務であったため、

従来の業務方法の見直しも行わなければ事務処理の品質維持が厳しくなる可能性もありました。

 

現行業務では、4人程度の分業制となっていました。

まず初めに、住所変更前作業としてコールセンター、インターネットサービス、窓口等の多岐に渡る住所変更の受付内容から住所変更を行う為のデータを作成し、

顧客に合わせたサービスの住所変更受付システムに入力する必要があり、受付票の印刷や請求書の点検などを行います。

 

そして次に、住所コードの検索を固有のマスタから行う必要があります。

その後、顧客が加入している保険会社に応じた契約者情報を管理するシステムの操作画面を立ち上げ、

上記で作成したデータを基に担当者が新たな住所を入力します。

 

それを別の担当者が、システムの登録内容に誤りがないかチェックし、

問題がなければ登録手続きを行っていました。

そして最後に、管理台帳に変更記録を入力していました。

 

1件あたり約7分~10分を要していた作業であり、

人間が行っているので些細な入力間違いやチェック漏れ等も発生していました。

 

1件あたりは数分程度の作業ですが、

月間にして数千件(約500時間)、年間にして数万件分の作業が発生する業務であり、極めて業務負荷が高くなっていました。

 

# 削減効果

RPAを導入したことによって、月間で8割程度の工数削減に繋がりました。

現状はまだ全業務のRPA化には至っていませんが、これだけの効果が出ているのです。

RPA化されていない部分は主に、住所変更の登録内容や台帳記載の最終確認や何らかの原因でロボットが停止した場合の作業で、

こちらは手作業で対応しています。

特に、効果として大きかったのは住所変更を登録する際に発生していた住所の分割後の入力作業であり、

入力フォームの入力間違いなども同時になくなりました。

 

今はまだ念の為最終確認を人間が目視で行っていますが、精度も悪くない為、完全にRPA化するのも難しくはないかもしれません。

 

# 導入において重要な事項

意思決定者、ユーザー部門、RPA導入部門の3者の連携が重要となります。

また、実際にいざ導入が決まりロボットを作るフェーズとなった場合には要件定義時において、

下記3点があれば、より正確な工数見積もりが可能です。

 

  • 現行業務フロー
  • 現行業務マニュアル
  • 業務で使用しているExcel等のフォーマット

 

まだまだ、RPAの工数や具体的な導入期間の見積もり精度は模索中ではありますが、

現行業務がどれだけ可視化されているかによって導入の難易度は大きく変わってきます。

ユーザー部門の業務においては、属人化されている内容が非常に多くあります。

見積もりをした後に追加要件として、RPAシステムの機能を追加していくことによって、プロジェクトが炎上気味になったりすることがよくあります。

 

現行業務のマニュアル等が一切無いとか、マニュアル内容が業務経験者にしかわからないようなレベル感だと、要件定義のフェーズで非常に工数が掛かってしまうことがあります。

それだけ、現行業務の可視化レベルというものはRPA化において重要な項目となっています。

 

理想的な話で言うと、新卒で入ってきた人間が現行業務マニュアルを見ながらであれば実際に業務をこなせるようなレベルになっていれば御の字です。

結局のところ、RPAといった技術に関しても、ソフトウェアロボットに業務を代行させるといった側面があるため、代行させる業務像が掴めていないと始まらないのです。

また、場合によっては現行業務をそのままRPA化しないこともあります。

RPA化に最適化させた形で業務フローを改善したり、業務フローの改善が厳しくても、

使用しているExcelのフォーマットの内容などをRPAツールで扱いやすい形に調整するといった作業は非常に重要で、RPA開発では「あるある」です。

RPAツールによっては、Excel操作できる内容に限界があったりしますが、

それでRPA化を諦めるのではなく、Excelの中身自体を変更するといったアプローチを取ることができるのです。

 

# RPA開発方針

基本的なシステム開発だと、下記のようなウォーターフォール型が一般的かと思われます。

  • 要件定義
  • 基本設計
  • 詳細設計
  • コーディング/単体テスト
  • 結合テスト
  • 総合テスト
  • 受入テスト

 

しかし、RPA導入・開発においてはアジャイル型が向いており、

各RPAツールも扱いやすく出来ているためとにかくスピード重視で行う場合が多いかと思われます。

そのため、上記の重要な事項でも述べましたが、

要件定義フェーズを厚くすることでRPAにおいては「要件定義書 = 基本設計書」となり得るので、

リッチなドキュメント作成の手間はかかりません。

 

要件さえ固まってしまえば早速ロボットの開発に着手し、

いち早くプロトタイプを作ってユーザー部門とロボットの挙動内容のすり合わせを繰り返していくことでより正確なRPA導入に繋げて行くことができる利点があります。

 

# AIやOCR(光学文字認識)の使用について

普段からRPAツールに触れている身として、「AI」や「OCR」といった単語はよく耳にしますが、

特にOCRについては最近手書き文字でも非常に高い精度で読み取れるツールも出てきているため、

今後RPAとの連携も増えてより業務に活かしていけるのではないかと考えています。

 

# さいごに

今後もますます保険会社系や金融系などのバックオフィス業務はRPA導入が間違いなく進んでいくと思われます。

ROIが現代のソリューションの中では圧倒的に高いと思われます。

 

以上、保険会社へのRPA導入事例でした。

 

 

topへ
© RPA.biz