Docly Child

AUTORO導入後のFAQ

144 views

この記事ではAUTORO導入後、業務自動化を進めるにあたりよくあるご質問をご紹介します。


 導入フェーズのFAQ

RPAの導入を判断する際には、一般的に以下のポイントを検討すると大きく失敗することはないかと思います。

1. 長期的な目標の設定

RPAを導入する目的や順序が重要です。
例)

2. 費用対効果の考慮

費用対効果を重視した大規模な業務からの導入は、初期の段階での失敗リスクが高まることがあるため、小規模かつ簡易なタスクから始めることをおすすめします。
例)

3. 業務の頻度と重要度

高頻度で実施され、重要度が高く、ルールづけが容易な業務はRPA導入の候補として適しています。特にイレギュラーケースが少ないものは優先度が高くなります。
また、自動化にかかる開発工数自体も検討材料となりますので、効率的に進めることが大切です。 スプレッドシート関数の活用、zapierなどの外部ツールとの連携等によって、自動化フローの開発に既存の機能が活用できないかについても検討しておくとハードルが下がるかと思います。

 開発フェーズのFAQ

適切なアクション数という固定的な数値はございません。

運用のしやすさや、他の担当者にもメンテナンスしてもらいやすい観点からは、概ね50程度が適当です。
しかし、重要なのはアクション数そのものよりも、ワークフローの目的や、実際の処理の内容を明確にドキュメント化しておくことです。
ドキュメント化する際のポイントは、下のアコーディオンメニューをご参照ください。

ドキュメントについては、以下を盛り込んでおくとよいかと思います。

1. 成果物の明確化

  • どんな業務成果物を目指すのか。
  • その成果物を誰がどのように使用するのか。

2. 運用の考慮点

  • 入力条件(サイトでの検索条件など)が将来的に変わる可能性はあるか。

3. 例外処理の確認

  • どのような場面でRPAの処理が停止する可能性があるか。
  • 停止した際の対処方法は何か。

アクション数が嵩んでくるとワークフローが開けなくなることもあります。
どうしてもアクション数が多くなってしまう場合は、カスタムアクションのご利用をご検討ください。
アクション数を無理に制限してワークフローを分割して実行していくより、処理の見通しがわかりやすくなる可能性があります。

ワークフロー自体を分割したほうがわかりやすい場合もあります。ワークフローを続けて実行していきたい場合は「AddToQueue」というアクションで、ワークフローから別のワークフローを実行できます。

上の項目でご案内したカスタムアクションについて、以下では技術的なフォローとして、カスタムアクション化の基準のご参考にタスクユニットという考え方をご紹介します。

タスクユニットは、「自分の担当領域以外の知識を持つ必要がないように分割された業務フロー上の各部門」になります。 例えば商品開発における以下のような部門分けを指します。

カスタムアクションを通じてこのような分割を行うと、ワークフローの保守において以下のメリットがあります。

  • 一つのユニットで問題が発生(サイトの仕様変更等)しても、そのユニットの成果物のフォーマットを崩さなければ次のユニットの影響が小さくなります
  • ワークフロー設定画面を見た時に、今何をやっているかが分かりやすくなります
  • エラーが起きた時、原因が追いやすくなります

構築中に以下に気をつけると効果的です。

1. 変数名を分かりやすくする

以下のような変数名を避けて、多少長くても分かりやすい名前をつけるようにします。

  • “aaa” : 何を指しているか分からない
  • “data” : データであることは分かるが、具体的にどういうデータか分からない
  • “cList” : “customerList”の意味でつけているが、”c”が何の略か分からない
  • “replacedText” : 具体的にどう値が変わったか分からない。”spaceRemovedText”など、処理の内容をつける
  • “row[29]” : 何度も登場する場合、配列の29番目を毎回確認するのが手間なので、変数名を別でつける

2. メモ欄を活用する

メモ欄に以下のような情報を明記しておくようにします。

  • Click等…ページのどこを操作しているか、具体的に書いておく
  • StoreValue…この後どこで使う予定か書いておく

また、Textアクションをメモ代わりに設置しておくのも有効です。

 

3. カスタムアクション化する

アコーディオンメニューの「どうしてもアクション数が多くなってしまう場合は?」の項目をご参照ください。

エラーが発生しないようにRPAを作成する際のポイントは以下の通りです。

1. 小さなステップで作成してテスト

RPAを一気に作るのではなく、少しずつアクションを追加し、都度テストを行うことで、問題点を早期に発見しやすくなります。

2. 待機時間の利用

ブラウザやアプリの反応時間の遅延を考慮し、画面が切り替わるきっかけになるアクションの後に一定の待機時間を設定することでエラーを回避します。
アクションに実行前/後待機の設定欄がない場合は、Waitアクションをご使用ください。

3. 条件分岐の網羅

事前に様々な状況や条件を考慮し、それに応じてワークフローを分岐させることで、エラーを未然に防ぐことができます。

4. 開発を行った人以外のテスト

見落とされているバグや問題点を第三者が指摘することができます。
また、エラーの検知にはTryアクションを使用します。こちらによって予期せぬエラーが発生した際に、適切に通知・対応できるようにしておくことができます。
ただし、エラーは完全には避けられないものであるという考え方をしておく必要があります。 見落としが無いように注意して作ったワークフローも、サイトの変化や取りうるパラメータの変動など、新たな要因によってエラーが発生することが考えられます。
エラーが起きた際にその原因や影響範囲が分かりやすいように設計し、必要に応じてすぐに保守対応ができる体制を整えることが重要です。

 テストフェーズのFAQ

全体を網羅すると抽象的な話となるため、以下には具体的な例を示します。

▼ケース

トリガー「新規取引情報登録」という件名のメール受信
処理Salesforceの取引先に情報を登録する

▼手順

1. 手動実行の確認

Salesforceの取引先登録直前までの動きを手動でテストし、成功することを確認します。

2. 過去データでの確認

複数パターンのメールを用意して、動作を確認します。

  • トリガーは正常に起動するか
  • トリガーは誤って起動しないか
  • Salesforceに正しい情報が記録されるか

3. テスト環境での確認

可能であればテスト環境を用意して、実際に通し実行をしてみます。

4. テスト運用

最低1週間を目安に、業務の頻度に応じてテスト運用の期間を定めます。

テスト仕様書を作成する際は、業務内容を理解しているメンバーに内容のレビューを依頼します。 具体的なサンプルとして、以下のリンクから参照できるテスト仕様書をご確認いただけます。

 要件定義書テンプレート (これはNotionにサンプル貼って全体公開する?)

期待する挙動は、正常系(正しくデータを処理する時)と異常系(誤ったデータを処理する時、誤った動作をした時)に分けて書いておくのが一般的です。

○正常系として確認すべきポイント

1. アウトプットが正しく出力されている
2. 条件分岐の全てで正しく挙動が確認できる。

○異常系として確認すべきポイント

1. 誤ったデータとして取り込みうるものを想定しておき、それに対してワークフローが正しくエラー通知を行う。
2. ワークフローがエラー終了した後、決められた流れで復旧する。
3. 想定外のエラーが発生した時、ワークフローが正しくエラー通知を行って停止する。

※Exitアクション、もしくはKillAttemptアクションでワークフローを任意で終了することができます。KillAttemptは故意にエラーを出すことが可能ですので、不意にエラー終了する状況も再現できます。

 全般についてのFAQ

RPAの運用方法は、会社の規模や業務内容などによって異なります。 以下は、一般的な考え方と他社の事例を元にした解説です。

1. 主要事業や頻繁に実行される業務が自動化の対象である場合、各部署がそれぞれRPAを運用することが一般的です。その部署の特性に合わせた柔軟な運用が可能となります。

2. 自動化したい業務内容が最初から部門横断的である時や、各部署での人員の入れ替わりが激しい場合、RPAの専門部隊を設置して、それらの要求に対応するのが効果的です。
ただし、簡単な自動化タスクがよく出る部署に関しては、部署内でもAUTOROを触れる方を一人置いておくとよいかと思います。

3. RPA担当者が退職すると、その後の保守対応が難しくなるケースが多いです。そのため、少なくとも2名ほどはAUTOROに触れるようにし、ドキュメント化やノウハウの共有の工数も最初から見込んでおく方が安全です。
RPA担当者の変更や、担当者を増やしたい時には、弊社スタッフによるハンズオンや構築サポートMTGの実施も有償にて承りますので、お気軽にご相談ください。

4. 現場経験が豊富なマネージャーや経営層からRPA利用を開始するのも、運用整備のスピードが早く効果的な場合があります。

【具体的な他社事例】
  • 自動化推進の部署が存在し、各部署からの依頼を受けて自動化を実施している。
  • 社長自らがRPAの運用・管理を行っている。

Standard以上のプランをご契約いただいている場合、プロジェクトを複数作成することが可能です。プロジェクトや、その中に格納するフォルダとワークフローの分け方と命名方法を統一しておくと、管理する際に便利です。
以下では、他社事例を基にした例を紹介しています。

プロジェクトの分け方

  • 部署別
  • 特定の事業
  • 顧客
  • 使用ツール(Salesforce、kintoneなど)
  • テスト用、本番用

フォルダの分け方・命名方法

  • 社内担当者
  • カテゴリ
  • テスト用、本番用

ワークフローの分け方・命名方法

  • コード番号
  • 案件名
  • ワークフロー作成者

このページは役に立ちましたか?