Enterprise Blue Ocean ◮

神谷町RPAブログ

  • Blue Prism の 製品概要 がよくわかるWebページ動画取材記事
  • Blue Prism の Blue Prism 事始め!オンボーディングの記事はこちら
  • Blue Prism を 無料で利用する 方法はこちら
  • Blue Prism で Excelを操作 する記事はこちら
  • Blue Prism の ベストプラクティス 記事はこちら
  • Blue Prism の 逆引きナレッジ wiki こちら。ご活用ください☆

Blue Prismベストプラクティス<設計編⑥> データ入出力の効率性 - RPA Ready?

 

ども。

「ジャナイホー」による「ベストプラクティス」シリーズ、今回は、設計編⑥ データ入出力の効率性 についてです。

 

データ入出力の効率性

「業務オペレーションの自動化」においては、ときとして、人間の操作をそのまま実装すること、は、必ずしも適切(効率的)ではない場合があります。

皆さんよく使うであろう、クリップボード(コピー&ペースト)も制約がありますしね。

この点、ロボットは、人間よりも記憶力があります。(いや、正確なところは分かりませんが)

 

例えば、二つのアプリケーション間でデータをコピー&ペーストする場合があったとします。

人間ですと、二つの画面を横に並べて、ひとつひとつ、左から右へ、コピーしてペーストして、をえっちら、おっちら、繰り返すような操作をします。

 

でもロボットでは、画面上に表示されている全部の項目の値を一気に読み込み、もう一つのアプリケーションへ一気にすべて書き込む、なんてわざもオテノモノです。

 

また、もしかしたら、画面を開いて操作する、ということも、APIを使ったシステム連携ができれば、その方が圧倒的に効率的でしょう。

メインフレームのエミュレータ画面を開いて操作するよりは、もし、メインフレームから構造化されたファイルを出力することができるのであれば、それを開いてデータを読み込む方が効率的である場合もあるでしょう。

 

ロボットですので、不埒な考えは起こしません。信じてやってください。

Blue Prismで内部統制準拠したプロセスを作れば、別に、コピー&ペーストを制限した画面から値を頑張って抽出しなくても、I/Fプログラムを介して重要データのデータソースに直にアクセスしたって良いはずです。

 

データの入出力、設計の時点で、ロボットならでは、を考えてみて下さい。

例えば、、、

  • 「画面操作」 より、「API連携」や「システム連携
  • 「Excelのフィルタを使って絞り込む」 より、「全データをCollectionに読み込んでから、BP上で必要なデータに絞り込む
  • 「PDFからOCRで読み込む」 より、「PDFの元ネタを生成するデータベースにアクセス
  • 「2つのシステムを同時に開いてコピー&ペーストを繰り返す」 より、「一度にすべてを読み込んで、一気に別のシステムへ書き出す

 などなど、です。

 

適材適所 。。。 「RPA Ready?」

RPAが万能なツール、魔法使いの杖、だったら良いのですが、現実はそうではありません。

やはり、RPAに向いている業務、向いていない業務ってのも、正直あります。

これについては、また別の機会にお話しししたいと思いますが、ROI回収、という観点で、ユーザの言いなりにならない、強い心をもって設計・開発をやってもらいたい、、、です。。。

 

業務全部を自動化しようとするのではなく、「構造化データの作成までは、なんとかやってよ」、とか、「画面から画像認識やOCRを使ってデータを抽出する」、のではなく、「CSV出力する外部I/Fプログラムを作る」、とか、です。

RPA Readyな状態まで、データ準備を人間系で行う」というのも、立派なソリューション設計です。

 

実際の皆さんのプロジェクトにおいては、

  • 重複チェックや重複行の排除
  • 複数のMS-WordやPDFの文書の中から、差分を比較して、違いを抽出する
  • 様々なフォーマットの請求書から、必要な情報を抜き出す

とか、色々な要件があると思います。

人間がめんどくさいから、ロボットに任せたい。

(それはそうなんですけど、、、)

OCRの技術も確立している、図表含めた精度の高い差分抽出プログラムがある、重複チェックも機械的にパフォーマンスを気にすることなく実装できる、

であれば、いいですけど、これらも含めて、RPAで実現したい、というのは、ちょっと気を付けたいですね。。。

 

ユーザの夢は広がりますが、でも、待って。

RPA Readyですか?

 

最初は、簡単なところから、RPAの得意な領域からやっていきませんか?

、というか、RPAが得意とする形にまで、先ずは持って行くようにしましょう。

RPAが得意な業務は、

  1. 処理件数が多い
  2. 手順がころころ変わらない、枯れている
  3. 繰り返し行われる
  4. 実行頻度が高い
  5. パターンが少ない

です。

長大な一連の業務のうち、その中でも特に、上記に当てはまるオペレーションを選別して、そこからRPAで実装する、とするのが良いと思います。

そこから、そこだけでも、ROIを先ずは少額でも確実に回収したい。。。

 

まとめ

 

ユーザのオペレーションをそっくりそのまま自動化する、というような、

旧時代のRDAの手続き型のスクリプト形式のレコーディングっぽい、

やり方でロボットを作る、のは、ちょっと待ってください。

もっと効率的で正確なやり方がないかどうか、是非一度、立ち止まって考えてみてほしいと思います。

 

絶対、後から無理がたたってくるんですよね。。。あとで苦労しているRPA開発者のなんと多いことか。

「そもそも上流から○○を少しだけでも変えることができないんでしょうか、、、」

「プロセスをもう少し分割して、整理して、不得意なところは人間に任せませんか、、、」

 

「そんなことわかってるよ。。。言ったけど通用しなかったよ。。。」

という開発者や監視者の嘆きが聞こえてきそうです。

、、、ですよね、、、

地道に、良いロボットを作って、少しずつ、発言権を強めていきましょう。。。