2020年に新型コロナウイルスの影響を受けて私が担当しているクライアントにおいて取引先との請求書や発注書のやり取りがこれまでの紙ベースからシステムの活用とPDFファイルにて運用する形へのシフトが決定しました。
全社で取り扱う案件は大量であり、システムへのデータ登録も1件1件必要となります。
この作業を社員が手で入力するのは大変であることと、システムで全て対応するのはコストと期間がかかりすぎると判断されました。そこでシステムの開発と並行してRPAの活用による社員の作業負荷の軽減と業務効率化の検討をはじめました。
システムの利用をサポートするために開発したRPAの役割と開発、保守フェーズで発生した問題、課題を事例にもとづき業務システムの運用にRPAを活かす方法を解説いたします。

業務システムの運用にRPAを活かす方法

この記事をお読みの方はRPAというツールの特性をご理解いただいている方も多いかもしれません。RPAが普及し始めて数年が経過しています。
提供される機能や求められる役割がより高度になってきてはいますが、初期から備えられている機能が相変わらず重要な役割を果たすことは今も変わらないと考えています。

活用事例として業務システムの運用をフォローする形でRPA導入したケースについて述べていきます。

新型コロナウイルスの流行がきっかけとなって私が担当しているお客様においても取引先との発注書、請求書の受け渡しを紙ベースからシステムを介した電子データ(PDF)のやり取りにする方針が取られました。
初期の構想ではRPAの利用を前提としたものではなくシステムを改修することがメインでしたが、システムへの登録作業を人手で実施するのは件数的にも難しい状況であり、またシステムの改修で登録自体の簡略化を行うのは、早い段階で期間やコスト的に難しいという話になりました。
こちらの会社ではRPA自体は全社へ普及しており、どんなことが出来て何に強いかというのはある程度理解がされていました。そこでRPAを全体の業務フローの中に組み込む検討がされました。
そして我々RPAの担当チームも開発に向けて改修プロジェクトに携わっていく流れとなりました。

システムに必要な機能を搭載して運用をよりスマートに、確実にするのが理想の形になります。開発の期間やコストを考慮すると、今回のように業務の一部をRPAで対応することでこの点を補完することが出来ます。

以降で導入における開発と保守パートについて述べてまいります。

RPA活用事例　1)要件定義から導入まで

私が担当するプロジェクトはRPAの開発をウォーターフォールモデルにて行っており、

• (要件定義前の事前調整)
• 要件定義
• 設計(仕様書作成)
• 実装
• テスト
• 試運用(ユーザー受け入れ)
• 本運用

の順に作業をしております。

RPA開発のノウハウはこれまでの経験からプロジェクト内に蓄積されているため、設計まで終えられれば後は運用に向けて進めます。
(システム開発と同じで、進捗の状況と納期の話は常について回りますが、、)

今回の様に全社規模のプロジェクトでRPAを運用する場合、要件定義に入る前の工程で運用に必要なツールの選定や全体のコスト感など開発費用も含めて全体像をステークホルダーで共有する必要があります。
作るロボットは1体であっても、1日1000件のPDFデータを処理するのに端末1台では処理が間に合いません。何台で並行稼働させる必要があるか、OCR機能が必要かか、必要な場合はファイル内のデータを取得するのに何のツールが適しているかなど、RPAで必要な構想をこの時点で定義しなければいけません。開発側の立場からするとシステム改修(こちらはこちらで結構な規模になり、、)にプラスして、RPAの活用でも結構コストかかってしまうなぁと予算確保いただくのに少し忍びなさを感じます。

要件定義前の調整と並走するような形で要件定義も行わないといません。
RPAの担当部分を明確にするのに人手で作業を行うことをイメージすると、担当者は自身が担当する案件に対して

1. システムの登録に必要な情報を入力、
2. 案件のPDFファイルを添付を行い、
3. データ登録

という作業となりました。
こう書いてしまうと単純な内容には見えますね。
RPAでこれらを自動化する際、案件担当者の作業は出来るだけ簡単な形にしたいため、所定のフォルダにPDFファイルを格納してもらうのみとしました。

今回PDFファイルが自社側で発行しているものであったため、ファイルのフォーマットは共通でありOCRによるファイル内のデータの読み取りが安易であったのは幸いでした。
必要な情報はRPAで全部取得可能であったため、担当者に手間をかけずに済みました。
(各社の請求書や発注書を扱う場合はOCRの利用にはネガティブになり、金額や発注番号、請求番号などをどうやって取得するかに悩むこととなります)

担当者からするとファイルを置いておけば、後はRPAでシステムにデータ登録まで行ってくれるので、後ほど送付される処理結果を待つだけとなります。

担当者全員の意見を聞きながら要件定義を進めるのは難しいため、担当者作業の日々運用や苦労を把握している管理部門のマネージャーと調整を行いながら要件のフィックスまで進めました。

設計では日中の時間帯を連続して稼働させるための方法やエラーハンドリングなど、なるべくエラーによる停止をさせないよう検討をしつつ、その後の実装とテストを経て運用をスタートさせました。

RPA活用事例　2)導入後、保守運用まで

運用が始まった後は保守体制を確保して対応にあたる必要があります。
今回導入したRPAは何らかの原因に止まってしまうと業務への影響が大きいため、問い合わせやエラー時には迅速な対応が求められます。

導入直後はやはりエラーの対応に追われました (開発側の担当がこんな表現使うと怒られますが) 。
大きな問題、課題となったのが「OCRツールA製品のアプリがRPAの動作のエラーを誘発する」でした。

OCRツールA製品ですが、他のロボットでも導入実績もあり初期のフィジビリティスタディでも読み取り問題なさそうであったため、今回も採用することにしました。
開発並びに必要な設定を完了して運用を開始した段階では、問題なく動いていました。しかし、不定期なRPAの処理中に、OCRツールA製品の設定を確認するダイアログが表示されたり、OCRツールA製品が起動しなかったり、と対応に時間を要しました。
実装に問題がある訳ではなかったのでプログラムを改修する出なく、都度端末を確認→再実行で様子見という動きを続けていました。

数ヶ月に1度程度に発生する事象であればまだよかったかもしれませんが、それなりの頻度でエラーを起こしていたため、保守側だけでなく利用者側にも大きなストレスと心配を与える形になりました。
「OCRツールA製品が悪いのでRPAは悪くありません」というのはこちら側の理屈です。よってユーザー側からしてみると「理由は分かったけどどうにかしてよ」という強い主張をするのは当然だと思いました。
保守側もこのRPAの対応にそれなりの工数を割いていたため、どの立場から見ても何らかの改善は必須でした。

結論としてはOCRツールA製品をやめて、RPAツールに内包されているOCR機能を使うことで劇的に改善されました。日々のエラーもほぼ0件となりOCRについて不安はあったものの全く問題なく処理されました。

初期に行ったフィジビリティスタディで内包のOCRツールも検証を行いました。その際に一部文字化けや領域を読み取れないと言ったマイナス要因があったためA製品を採用したのですが、結果として定型のフォーマットの読み取りとで、不具合はほぼ0で運用が出来ています。

このエラーを解決したことで、以降は工数を割いて対応が必要になることはなくなりました。
それでも何か問題が起きた時に優先度を高くして対応にあたらなければいけないという点は変わりません。現在ではRPA全体の保守体制に組み込む形で保守にあたっています。

まとめ

RPAに関連する業務を担当されている場合、RPAの利用を前提に業務効率化を検討し、推進することはスタンダードな考え方です。
今回記述したような全社的な業務フローの変更にRPAを取り入れ、システム間の連携であったり大量のデータ登録をサポートする使い方は初めての対応でした。
RPA単独で開発を行う形でないため、クライアントの情シス部門やシステム担当などステークホルダーが多くなり、調整に苦労しました。
苦労が多い分、RPAによる業務効率化への貢献は大きいと感じています。

本記事の執筆時点で導入から1年以上が経過していますが、全社利用を継続しており次にシステムの大きなアップデートを迎えるまでは稼働が続く予定です。
今回の活用事例を参考に利用部門の拡張や類似案件へのRPA導入といったケースも生まれています。改めてRPAの有用性が示されましたので、皆様の業務フローがアップデートされる際には、このようなRPA活用事例を参考にしていただければ幸いです。

電通総研ではRPAの推進と活用をもう一度はじめたい方に参考になる資料「今こそ言える、RPA成功への近道　~推進と活用の2軸から‘もう一度’はじめましょう！~」をご用意しております。本資料は、RPA導入や再活用に向けて必見の資料です。ぜひダウンロードいただき、ご覧ください。