RPAの自動化対象案件発掘って難しい！？シナリオ描けてますか？（vol.14）
以下は、RPA導入支援に関してよくあるRFPの一部分です。
- 年間〇〇業務の自動化対象業務について新規のシナリオ作成を支援すること
- 現場が作成した業務シナリオについてRPAの適用の妥当性を判断すること
- 業務フローが適している場合はシナリオの改善を含めた助言を行うこと、適さない場合は自動化する業務シナリオを支援すること。
※シナリオの部分がフローと書かれる場合もあります。
「支援」って言葉は広いなぁ…という話はおいておきますが、いわゆる自動化対象案件の発掘という文脈で、適用の妥当性を判断を導入時によく求められます。せっかく高いお金を払って導入するRPAですから可能な限り有効に使いたいという気持ちはよくわかります。でも、それほど難しいのでしょうか。本記事では導入時に問われる「自動化に適したシナリオ」の考え方や選択方法について解説します。
適している適していないの前に…シナリオを正しく書けてますか？
「シナリオ（フロー）を学ぶのとRPAを学ぶのと、どちらが優先順位が先？」と聞かれる機会があります。それはズバリ「シナリオです！」と答えます。なぜでしょう？皆さんが自動化したい内容をしっかりと全容を把握して整理し、どこを自動化するべきかを把握する第１歩だからです。さらに言えば、その先のRPAのプログラムはそのシナリオに従って作成するものです。ですので、シナリオを書けることがまず優先されるべきこととなります。では、シナリオってどう書けばよいのでしょうか。書き方はいくつかあります。
- JIS（日本工業規格）X0121 情報処理用流れ図
- DFD (データフロー図)
- BPMN ビジネスプロセスモデリング表記法… etc.
でも、どうでしょう？これらを覚えるためにはそれなりの学習が必要です。また最終的な現場の方々が見てわからないと意味がありません。そこでお勧めはフローチャートです。内容は割愛しますが、ぱっと見で誰もがわかるようにするのが非常に重要です。
完全なフローチャート（すべての図形をきっちり覚えて描くことを意味します）を記載する必要はありません。業務が整理できればよいのですから、簡易的なルールと記述の粒度（どの単位で作業を書くか）だけ決めておけばよいと思います。縦書きの場合は横軸にステークホルダー（登場人物）とシステム縦軸が業務の流れる時間（横書きの場合はこの反対）で記載していくとわかりやすくなります。さらに、ポイントポイントを吹き出し等で補足すれば十分理解できるものになるでしょう。同様にあるべき姿が書ければ完璧です。「関係者全員が見てわかる！」これが重要です。
シナリオを書くことができればRPAに適したシナリオがわかる…かもしれない
上記が書けた前提で、自動化対象となる部分を決めると頭の中が整理されてくるので、ここからわかってくることがいくつかあります。（当然事前に予測できることもありますが…）
代表例は以下のとおりです。
- 各処理で必要なインプット、アウトプットとその数
RPAではインプットとアウトプットが非常に重要です。インプットの形が決まっていないとその先のロジックは組めませんし、その数によってどれくらいの作業になるのかという規模感の指標になります。またアウトプットも同様でどのシステムに対してどれくらいの項目を打ち込むのか、どのようなレポートをどれくらい作成するのかを知れば規模感がわかります。 - 作業ボリューム
１回あたりにどれくらいのデータを扱うかは自動化した際の時間を図るために重要な要素です。作業ボリュームによってはロボット１体では対応できないケースもあるので、そのケースは複数で利用やバッチ処理の検討を行うとよいでしょう。 - 関係するシステムの数
関係するシステムが多くなると、それぞれのシステムには特徴があるため、それだけRPAを作成する際に注意しなければならないことが増えます。またこれまでにRPAでの自動化実績がない場合には、自動化が可能かどうか（RPAツールでそのシステムを触れるかどうか）の調査が別途に不可欠ですので、注意をしてください。 - 例外の処理の数
例外の処理が多ければ多いほど多重化します。条件分岐が多いときには条件を全て網羅せずに、頻度が少ない条件を対象外にして人で行うなど、ある程度の割り切りは必要です。 - 人にしかできない処理の有無
作業の中にはどうしても人が判断しなければならないケースがあります。ここではロボットを分けるかどうかの判断をします。分けたらさらに作業が増えてしまった…というケースもありえます。現在AIの有効活用でこの部分も自動化できる範囲が広がりつつありますが、ここでは割愛します。
上記に関しては数が多ければ多いほど複雑さは増していきます。複雑さが増すと当然自動化の難易度が高く（できないという意味ではなく、時間がかかったりエラーを起こす可能性のある箇所が増える）なります。
また以下の点についてもチェックしてみてください。
- シナリオの安定性
シナリオ自体がこの先しばらく続くものであるかどうかです。短期的なものである自動化は自動化のメリットを享受できないケースもあります。また頻繁にシナリオや条件が変わってしまうようなシナリオは、修正によるメンテナンスコストが増大してしまいます。 - シナリオに曖昧な点はないか
RPAを作成が難しいため作業対象外にせざるを得ません。 - インプットについてのデータの正確性
これは非常に重要です。インプットの正確性が担保できないとRPAはあくまでもプログラムなので、エラーの発生頻度が高くなります。データの正確性をインプットの取得時にバリデーション（データの妥当性チェック）も可能ですが、データ項目が多いシナリオには対応にそれなりの手間がかかってしまいます。そのため手早くできるRPAのメリットが失われてしまう可能性があります。可能であればインプットデータ作成時に担保しておきたいものです。 - シナリオの多重度
繰り返しが少なければ人の手で作業したほうが早いなど自動化のメリットが得られないケースがあります。エラーが起きた場合の処理やそのリカバリー方法を考慮すると、別の運用効率の良い方法で再検討が必要なケースもあります。 - 対象となるシステムの安定性
特に外部WEBサイト（さらに言えば海外WEBサービスに多くあるように思いますが）はサイト変更が頻繁に発生するようなケースもあります。見た目は変わっていないのに、HTMLベースで変更か加わっている…なんてことも。
最終的にはこれら（本当はもっとありますが）と評価すべきKPI（創出される時間や心理的負担、緊急度など）と総合的に判断して、自動化の対象の優先順位を決めるのが一般的です。
本当にそのロボットから作りますか？
対象案件の評価ができたら、さぁどれから始めようか！となります。
RPAを導入する際に「効果」ってやはり気になるものです。導入で最初に大きな効果が得られれば「ほら！こんなに効果上がったんだからRPAによる自動化をどんどん進めましょうよ！」って鼻高々に言うことができます。でも…実際に対象案件を並べていくとわかりますが、効果が高いものは得てして複雑度が高い（＝難易度が高い）ものが多いです。とわかっていながら、「開発会社に任せているから当然できるでしょ！」って思って、効果「大」難易度「高」なんて案件を選びがちです。
それ、間違いです。
確かに開発会社は全力で取り組みを行い、できる限りエラーを起こさないようなさまざまな取り組みを行って、お客様へ品質の高いロボットを提供するように努めます。しかし、複雑度が高いものは前述したとおり、関係システムが多かったり例外処理が多かったりというケースが多いのです。
さらにもし初めてそのシステムでの自動化となった場合にはその特徴もわかりません。「わからない」ということは、その対処の方法も「まだわからない」のです。
また、ロボットをどんなにテストしても必ずエラーが発生するもの（いいわけではないですが…）。なぜならば外的な要因（端末やOFFICE製品、ネットワーク、インプットデータ、対するシステムのレスポンスなどなど）によってもエラーが起こり得ます。実際RPAのエラーはテスト中に発生しなかった外部環境に起因するエラーが8-9割を占めます。
こうした状況では稼働後に想定しないエラーが多発するケースがあります。これによって保守対応に追われてしまうことで時間を割かれてしまい、新しいロボットの作業に影響がでてしまう可能性があるのです。こうなるとお互いに良い結果とはなりません。そしてRPAが評価されなくなっていくひとつの要因となってしまいます。
つまり、最初の１歩を慎重に選ぶことが初期段階での成功への近道になるのです。
まとめ
RPAにおけるシナリオの重要性についてはご理解いただけたかと思います。シナリオを書くことによって、自分たちが行っている業務で様々な発見や整理ができ、その内容が分析によってRPAによる自動化に適しているかどうかを判断することができます。決して難しいものではないと思いますので、ぜひ実行してみてください。
弊社ではRPAの推進と活用をもう一度はじめたい方に参考になる資料「今こそ言える、RPA成功への近道 ～推進と活用の2軸から‘もう一度’はじめましょう！～」をご用意しております。本資料は、RPA導入や再活用に向けて必見の資料です。ぜひ以下URLよりダウンロードのうえ、ご覧ください。
「今こそ言える、RPA成功への近道 ～推進と活用の2軸から‘もう一度’はじめましょう！～」
https://inv.dentsusoken.com/lp/ebook/rpa_uipath_2