こんにちは。
IQ Botのインスタンスの作り方について、とある方から質問をいただきました。
同じところでつまづく方も多いと思うので、会社が特定されない形でこちらで回答します。
質問：こんなとき、インスタンスをどう作って呼び分ければいい？
A社では、以下の３種類の帳票を扱っています。
- 輸送伝票
- 請求書
- 貨物明細
取引先によって、上記1～3がそれぞれ来ることもあれば、1と2だけが来る（3は2に込み）という場合もあります。
こういう場合、インスタンスはどう作って呼び分けるんですか？
RPAでの前処理や後処理はどうやって組むんですか？
という質問でした。
問題を整理
上記の件、実際に帳票を見たわけではないんですが、聞いた話をもとに整理すると、こういうことですかね。
私ならこうする
上記の条件からすれば、私なら以下のようにインスタンスを分けます。
- 輸送伝票用のインスタンスを１つ作成
- 請求書および貨物明細用のインスタンスを１つ作成
業務上「１部」として扱う一式ごとに１つのPDFファイルとしてスキャンされている前提であれば、RPAでは以下のように処理します。1
具体例を示すために使用するアクションなどを明記していますが、そうしなければいけないというわけではなく、別の方法で実現できるならそれでもOKです。
（IQ Bot UploadとIQ Bot Downloadを使うのではなく、IQ Bot Local Deviceを使うとか）
RPAによる処理の流れ
Bot1 : 前処理～IQ Botに処理を投げるまで
| # | 実施内容 | 詳細・使用するアクション |
|---|---|---|
| ① | 輸送伝票とそれ以外のページを分ける | 輸送伝票のページ数が常に固定の場合は、PDFアクションのみで対応可。 輸送伝票のページ数が変動する場合は、IQ Bot Classifier（別料金）と組み合わせた対応が必要。 輸送伝票とそれ以外のページは、ネーミングルールを決めてそれぞれのフォルダに入れるなどして、対応関係があとでわかるようにしておく。 |
| ② | 輸送伝票を輸送伝票用のIQ Botインスタンスにアップロードする | IQ Bot - Upload document |
| ③ | 輸送伝票以外のページを、輸送伝票以外のページ用のIQ Botインスタンスにアップロードする | IQ Bot - Upload document |
IQ Bot Uploadのコマンドが完了した状態は、あくまでも「クライアントがIQ Botサーバーにリクエストを出し終わったよ」という状態です。
待機を組んでもいいですが、Runnerを有効活用する観点では、ここまででいったんBotを分け、あとの処理は別Botにするのがおすすめです。
Bot2 : 後処理
後処理に関しては完全に業務要件次第なので、聞いた情報だけではなんとも言えないのですが、一般的によくある後処理の例を示します。
| # | 実施内容 | 詳細・使用するアクション |
|---|---|---|
| ① | 輸送伝票の結果CSVをダウンロードする | IQ Bot - Download all documents |
| ② | 輸送伝票以外のページの結果CSVをダウンロードする | IQ Bot - Download all documents |
| ③ | 上記①と②をマッチング・統合する | IQ Botが出力したCSVは、「重複を避けるためのランダム文字列(文字数は固定)＋もとの画像ファイルのファイル名と拡張子.csv」となっているので、前処理時のネーミングルールをもとに①と②をマッチングできる |
| ④ | 画面入力 | ③でできたファイルをもとに、項目を画面入力する |
ちょっと細かい話をすると、ここでは「後処理」としてひとくくりにしてしまいましたが、①～③までと④は別のBotに分けて作るのが一般的だと思います（理由の説明は割愛。希望が多ければ書きます）。
Bot1と2の運用方法
上記に書いたBot1とBot2（の①～③）ですが、以下のようにスケジュール実行するのが個人的におすすめです。
- Bot1を、毎時0分にスケジュール実行
- Bot2を、毎時30分にスケジュール実行
※時間はあくまでも一例で、スケジュールを何時間（何分）おきにするかは業務要件次第です
IQ Botに処理を投げてから結果のCSVが返ってくるまでのタイミングはあくまでもIQ Botサーバーの都合であり、上記のようなフローを組んだとしても、30分後に必ずすべての結果が揃っているとは限りません。
Success以外の出力結果になっている場合もあるしね！
（参考：IQ Bot：出力の流れ）
なのでBot2を作成する際は、マッチングしようとしたファイルの相手先がいないことを考慮に入れておいた方がいいです。
（相手がSuccess以外の出力結果になっている場合はメール添付して担当者に通知、相手がいない場合（＝単純に処理待ちと考えられる）はスルー、のように）
単純な処理待ちでスルーされた場合は、次回のスケジュール時に相手が揃っていればそのとき処理がかかりますが、心配であれば「１日の終わりに相手がいないCSVをチェックして、担当者にメールする」というような別のBotをスケジュールしておくなどの対応も考えられます。
IQ Botに処理を投げるBotを定時スケジュールにした方がいい理由（＝トリガーによる都度処理にしない方がいい理由）についても一家言あるのですが、こちらはまた別の機会に記事を書きたいと思います。
最後に統合するのになぜインスタンスを分けるのか
ここまで読んでいる中で、「ん？ 輸送伝票とそれ以外はインスタンスを分けたのに、結局最後に統合すんの？ なら最初から同じインスタンスで良くないっすか」と思われた方もいるかもしれません。
IQ Botでインスタンスを分けた方がいいと判断した理由は、以下です。
- インスタンスをシンプルにした方がマッピングが楽だから
- 複数種類の帳票が混ざることで、徒に分類が分かれすぎるのを避けるため
IQ Botはページまたぎの帳票も処理できるんですが、そこで想定しているのはどちらかといえば「請求書の明細が１ページになる場合もあれば、何ページにもなる場合もある」というようなケースです。
今回のケースのように、輸送伝票／それ以外 とはっきり種類を分けられる場合は、インスタンスを分けた方が楽です。
はっきり種類が分かれる場合はインスタンスを分けたほうが楽なのに、なぜ請求書と貨物明細は同じインスタンスにするのか
これは、最初に整理した以下の切り分けが理由です。
請求書と貨物明細は、分かれている場合もあれば、貨物明細に記載されるような情報が請求書に含まれる場合もあるということですよね。
そうであれば、「請求書」や「貨物明細」という呼び名で分けてはいるものの、その両者から取得できる一連の情報をひとまとまりに扱っているというようなイメージですよね（たぶん）。
言い換えれば、
- 2と3が分かれているケース
- 貨物明細が請求書の明細行の役割を担っている
- 3と2が分かれているケース
- 請求書の明細行が貨物明細の役割を担っている
つまり、貨物明細と請求書の明細行は役割一緒やん！ というような。
なので、同じインスタンスでいいのではと判断しました。
最後になりましたがめっちゃ大事な補足
今回は実際に帳票の中身を見たわけではなく、「質問」に書いてある情報＆過去にPoCで見た帳票の知識（輸送伝票の項目はだいたいどれも同じとか）をもとに回答しているので、かなりロジカルにバッサリ「こうした方がいいっす」と書いています。
でも実際の帳票は、そこまできれいに項目が整理しきれない場合も往々にしてあります。
もし、読んでくださった方の問題がここに書いてある質問のケースとすごく似ていた場合でも、現物の帳票とにらめっこをしながら、「ここに書いてあることは本当に自分のケースに当てはまるかな？」と検証することを忘れないでください！
以上です。
-
もしも１部ごとにスキャンする運用が現実的でなく、何百部もの書類を一括スキャンする業務フローの場合、「輸送伝票ごとにPDFを分ける」という処理が要ります。部の区切りごとに白紙をはさむという運用ができればRPA(Automation Anywhere)に付属のPDFコマンドだけで処理できますが、それも現実的でない場合は、輸送伝票のパターンを学習させて、それが出現したページごとにPDFを分けるというような、IQ Bot Classifier（別料金）と組み合わせた対応が必要になります。 ↩