RPAをより効果的に活用するための「補完ツール」(第1回)
目次
本コラムでは『 RPAをより効果的に活用する為の「補完ツール」』と題して、RPAが不得意とする作業を補完してくれるツールやサービスについて考えていきたいと思います。
RPAの導入だからといってRPAですべて解決する必要はない
私たちは日々、お客様に対しRPAを主役としたさまざまなソリューションを提供していますが、その中でモットーとしていることがあります。
それは、、
「RPA導入は手段であって目的ではない。目的はお客様のビジネスの成長のサポートにある。」
RPA開発では、技術的な壁に直面することが多々あります。
その際に「この難しい処理をRPAでどのように実装しようか」という考えに執着しがちです。勿論、RPAでスマートに解決できれば越したことはないのですが、RPAの処理に執着した結果、かえって開発コストが膨らんでしまうこともあります。RPAを効果的に活用する為にも「RPAでできないなら、この処理は自前で作ろう」「この処理に特化した〇〇ってツールを使うのはどうだろう」といった頭の切り替えをすることも大切だと考えています。
RPA開発で直面する「データ変換」
RPAの導入では、異なるシステム間でのデータ入力をするケースがよくでてきます。
(例)データベースからWeb画面、Web画面からWindowsアプリケーション等
そこで必ずと言ってよいほど発生するのが「データ変換」。
日付一つとっても和暦であったり西暦であったり、システムで保存する形式は様々です。
大量の項目の変換処理をRPAで実装する場合、少なくとも2点のデメリットが考えられます。
(1)通常開発と比較して開発コストがかかる
RPA製品の多くは、専用のツール(GUI)を使用して処理フローを定義します。
GUIは直観的な開発ができる反面、一つ一つをツール上で設定しないといけない為、大量の処理を定義する場合、通常開発と比較して開発コストがかかります。
(2)変換機能の共有利用ができない
大量の変換処理を開発するということは、そこに大量の業務ロジックを持つことになります。
今後、別のシステム等から変換機能を共有利用したいとなった場合、RPAに組み込まれていると共有利用できません。
<RPAツール上で変換処理を確認・設定する流れ(例)>
大量のデータ変換が発生したプロジェクト事例
私が携わったRPA×OCRのプロジェクトでは、OCRしたデータを別システムに変換して入力する要件がありました。
RPA導入初期の項目数は200程度(※1)であったため、変換処理もRPAで実装していました。その後、主業務にもRPAを導入することになり、その時の項目数は1,000(※1)を超えました。
1,000を超える項目をRPAで実装するとなると開発コストへのインパクトが大きいとの判断から、設計を再検討し変換処理(自前で開発)を切り出すことにしました。
その結果、RPAの処理をシンプルすることができ、トータルの開発コストの軽減に繋がりました。
当時は時間的制約などから変換処理を自前で開発しましたが、今後もこのようなケースが増えていくと思われるので、実施ある変換ツールを調査・検証することはQCD(※2)の観点からも有益であると考えています。
※1 変換を必要としない項目を含む
※2 QCD(Quality Cost Delivery)・・・生産管理において重要な3つの要素
<RPA×OCR導入後の業務フロー(抜粋)>
まとめ
RPAの不得意な作業をシステム開発や外部ツールで補完することで、より効果的にRPAを活用することができます。
次回以降では、市場に出回っているデータ変換に特化した製品(サービス)について紹介していきます。
最新情報をお届けします!
RPAに関する最新コラムやイベント情報をメールで配信中です。
RPA領域でお仕事されている方に役立つナレッジになりますので、ぜび登録してください!
- November 2024 (2)
- October 2024 (3)
- September 2024 (2)
- August 2024 (4)
- July 2024 (1)
- June 2024 (2)
- May 2024 (3)
- April 2024 (1)
- March 2024 (1)
- February 2024 (1)
- January 2024 (1)
- December 2023 (1)