所要時間が85%減

cases image

- 具体的に従来業務をどのように改善したのか教えてください。

従来からの改善ポイントは次のとおりです。
改善点1.「申込書の簡易化(記入項目が最大50%減)」

従来は以下のような手順でした。
1.お客様が申込書に手書き記入
 (煩雑、高ストレスな作業)
2.店舗スタッフが住民票、源泉徴収票を見て記入内容が正しいかチェック
 (事務負荷が高くチェック漏れも発生しやすい)
3.「間違い記入」は、お客様が自分で書き直す。訂正印も必要。
 (気の滅入る作業)

この作業では、手順2の「別書類との照合」に注目しました。住所や年収は、お客様の記述に頼らなくても、最初から住民票や源泉徴収票を参照すれば済むのではないかと考えました。こうした視点で、従来の煩雑な申込書に見直しをかけた結果、記入項目を最大で従来の50%減にできました。

cases image

改善点2.「店舗での入力・照合業務の撤廃」

従来の手順では店舗スタッフが膨大な処理(最大で90種類の組合せ)の整合性をチェックした上で、その内容を業務システムにスタッフが手入力していました。この際、転記ミスが発生する可能性は十分あります。

しかし新たなオペレーションでは、店舗側の業務を大幅に簡略化。スタッフの業務は、実質的に「書類を複合機などでPDF化した後、それを業務システムにアップロードするだけ」になりました。これにより「店舗での転記ミスの根絶」「事務作業の本社への集約」が実現しました。

cases image

改善点3.「審査業務の自動化(RPA+OCR化)」

店舗から本社へ移管した業務は、以下のように徹底的にRPA化・OCR化しました。

1. 【書類の自動取得(RPA)】
 店舗が業務システム(salesforce)にアップロードした書類(PDF)を、RPAにより自動取得します。
2. 【PDF書類の自動データ化(OCR)】
 取得した書類PDFはOCRシステムにより、適切なフォーマットでデータ化(テキスト化)します。また住民票は自治体ごとに形式が異なりますので、OCR設定には工夫が必要です。
3. 【単純審査の自動化(RPA)】
 信用事故の有無、年収など「システムによる閾値判断」が可能な項目は、RPAが自動判断します。
4. 【最終チェック支援(RPA)】
 人手による最終チェックが必要な部分は、その手間を最小化できるよう、システムで支援します。

cases image

5.【業務システムへのデータ再登録(RPA)】

審査後の最終データを業務システムに自動登録します。
これらの改善により、業務は大幅に自動化、効率化されました。特に店舗での入力作業時間は、以前は60分だったものが10分に低減され、従来比で約85%減となりました。

システム開発企業の選定基準

cases image

- 今回のRPA+OCRを依頼するシステム開発企業をどう選定したかを教えてください。

今回のプロジェクトを依頼する開発会社には、次の要件を求めました。
要件1. 「業務システム開発の豊富な実績」
今回のプロジェクトは、住宅ローン審査というARUHIの基幹業務の「仕事のやりかた」を根本から変えるものであり、必ず成功させる必要があります。プロジェクトを依頼する開発会社には、企業の現場実務を効率化するための知見、ノウハウ、実績が十分に備わっていることを重視しました。

要件2. 「4ヶ月でカットオーバーできること」
住宅ローン審査は年度末の2月~3月が繁忙期です。プロジェクト開始は2017年10月でしたので、2018年1月には必ず新システムが稼働している必要がありました。

要件3. 「コンサルティングから構築、運用までワンストップで依頼できること」
要件2の「短納期」を実現するためにも、上流設計から構築、運用まで全てをワンストップで依頼できることを求めました。またカットオーバー後も、継続的、長期的にアフターフォローが可能であることを求めました。

要件4. 「顧客に密着した体制であること(常駐が可能なこと)」
開発会社は、住宅ローン審査の業務手順、書類特性など「仕事の流れの全て」を熟知する必要があります。また4ヶ月というタイトなスケジュールを考えても、コミュニケーションが密な方がいい。そしてセキュリティ上の理由により、打ち合わせや作業はなるべくARUHI社内で行うのが望ましい。これら前提を考慮し、開発会社には「ARUHIへの常駐が可能であること」を求めました。

要件5. 「性能要件のクリア(高い精度のOCRなど)」
今回のRPA+OCRには基本性能や可用性について厳しい要件を設けました。その要件の一つに、例えば「OCRの精度出し」が挙げられます。このプロジェクトの成否は、各種書類をいかに高精度でデータ化できるかに依る部分が大きく、精度が低いと、人手による補正・再入力が必要になり、結局は業務効率化につながらないからです。OCRのほかにも、イベント処理時間、エラーハンドリング処理など様々な性能要件をクリアできることを求めました。

以上の要件をもとに検討し、ARUHIの求める要件を最も満たしているBTCを採用しました。